16:00:03 <pschindl> #startmeeting F21-blocker-review
16:00:03 <zodbot> Meeting started Wed Aug 13 16:00:03 2014 UTC.  The chair is pschindl. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:03 <pschindl> #meetingname F21-blocker-review
16:00:03 <pschindl> #topic Roll Call
16:00:04 <zodbot> The meeting name has been set to 'f21-blocker-review'
16:00:16 <pschindl> #chair kparal mkrizek
16:00:16 <zodbot> Current chairs: kparal mkrizek pschindl
16:00:28 * kparal is here
16:00:31 <pschindl> So who's here for blocker bug meeting?
16:00:35 * garretraziel is here
16:00:41 * mkrizek is here
16:01:02 * tflink is here
16:01:21 * satellit_e listening
16:01:44 * jsmith is lurking, but will get pulled away
16:02:01 <pschindl> wow so many people. That will be loooong.
16:02:11 <pschindl> Ok, so let's start.
16:02:15 <pschindl> #topic Introduction
16:02:15 <pschindl> Why are we here?
16:02:15 <pschindl> #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:02:15 <pschindl> #info We'll be following the process outlined at:
16:02:15 <pschindl> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:02:16 <pschindl> #info The bugs up for review today are available at:
16:02:16 <pschindl> #link http://qa.fedoraproject.org/blockerbugs/current
16:02:17 <pschindl> #info The criteria for release blocking bugs can be found at:
16:02:17 <pschindl> #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
16:02:18 <pschindl> #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
16:02:18 <pschindl> #link https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria
16:02:42 <pschindl> Today we have to discuss 7 proposed blockers and 1 proposed FE
16:02:45 * kparal volunteers to do the secretary work
16:03:00 <pschindl> kparal: thank you!
16:03:04 * danofsatx-work isn't late after all
16:03:12 * nirik is lurking also
16:03:17 <pschindl> ok. So, first blocker
16:03:25 <pschindl> #info 7 Proposed Blockers
16:03:25 <pschindl> #info 6 Accepted Blockers
16:03:25 <pschindl> #info 1 Proposed Freeze Exceptions
16:03:25 <pschindl> #info 0 Accepted Freeze Exceptions
16:03:34 <pschindl> #topic (1127280) OSError: [Errno 2] No such file or directory
16:03:34 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1127280
16:03:34 <pschindl> #info Proposed Blocker, anaconda, NEW
16:03:50 <kparal> this is blocked on 1127103
16:04:08 <kparal> once we resolve that, we will know whether it is a blocker or not. hopefully it will be resolved as well
16:04:19 <kparal> so let's just punt?
16:04:39 <pschindl> +1 for this idea.
16:04:50 <danofsatx-work> +1 punt
16:05:25 <garretraziel> +1 punt
16:05:31 <tflink> yeah, punt sounds appropriate. hard to tell what's going on with inconsistent images
16:05:36 <pschindl> #info We will discuss bug 1127280 after bug 1127103 will be resolved.
16:05:37 <jsmith> +1 punt
16:06:13 <pschindl> so let's move to another one (I can't remember if I should write any other #agreed or what?)
16:06:40 <pschindl> #topic (1129507) Anaconda deletes default EFI boot entry
16:06:41 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1129507
16:06:41 <pschindl> #info Proposed Blocker, anaconda, NEW
16:06:57 * satellit I still see working soas lives today...so very inconsistent
16:06:57 <pschindl> #chair tflink
16:06:57 <zodbot> Current chairs: kparal mkrizek pschindl tflink
16:07:10 <danofsatx-work> this one is mine, and I'm a little disgruntled about it. my laptop is still effectivley dead.
16:07:54 <danofsatx-work> release criteria state "Disks not selected as installation targets must not be affected by the installation process in any way."
16:08:26 <kparal> danofsatx-work: was the original system called 'Fedora'?
16:08:29 <danofsatx-work> the UEFI pointers to disks not selected as installation targets were deleted, making my laptop unbootable without that USB drive attached.
16:08:31 <kparal> in UEFI
16:09:10 <danofsatx-work> kparal: that's a very good question....it was whatever Anaconda called it for F20, so it likely was.
16:09:22 <tflink> it was called Fedora
16:09:31 <kparal> the current approach is to remove item called 'Fedora' and create a new one
16:09:42 <kparal> the destination is not considered
16:09:55 <tflink> it looks like the bootloader configuration succeeded
16:09:56 <kparal> if the item was not removed, there would be two boot options called the same
16:10:01 <pschindl> how does it work if I want to have dual boot?
16:10:07 <tflink> from the viewpoint of the efibootmgr stuff inthe longs, anyways
16:10:10 * amita joining late
16:10:25 <kparal> this bug is a piece of a bigger story - UEFI Fedora multiboot handling
16:10:26 <tflink> pschindl: I rename my real "Fedora" to something that doesn't conflict
16:10:28 <danofsatx-work> pschindl: technically, grub is supposed to handle the dual booting
16:10:36 <kparal> currently you can't have two Fedora installations in UEFI easily
16:10:37 <pschindl> Hi, amita
16:10:50 <amita> hello pschindl
16:11:17 <amita> hello tflink and every one :)
16:11:40 <pschindl> Hmmm. Ok so it looks like it breaks older installations but it is expected. Am I right?
16:11:51 <danofsatx-work> Can we amend the efibootmgr command to say, maybe efibootmgr -L "Fedora 21"
16:12:37 <pschindl> danofsatx-work: That makes sense to me. Maybe even something like Fedora 21 Workstation.
16:12:53 <pschindl> But this is discussion for another meeting I thing.
16:13:08 <danofsatx-work> probably. but is it a blocker is the question...
16:13:09 <kparal> in this case it would have to be renamed during upgrade
16:13:14 <tflink> the only problem with doing something like that is NVRAM exhaustion
16:13:20 <kparal> so, back to the bug
16:13:35 <kparal> I think we should talk to anaconda and clarify whether they intend to support fedora multiboot in UEFI
16:13:38 <tflink> what does efibootmgr show now?
16:13:53 <kparal> because currently it's not a bug per-se, it's simply unimplemented feature
16:13:56 <tflink> did it really get deleted or just confused with looking at a removable disk?\
16:14:05 <tflink> "just deleted" rather
16:14:18 <danofsatx-work> after all my futzing around trying to fix it? I couldn't tell you off the top of my head. the machine is in my backpack.
16:14:28 <pschindl> I don't think it is blocker. It looks more like feature request to me too.
16:14:37 <danofsatx-work> according to the journal.log, it deleted the entry, then created a new one.
16:14:40 * pwhalen sneaks in quietly
16:14:55 <tflink> danofsatx-work: yeah, that's been how it's worked for a while
16:15:35 <pschindl> So. Any suggestions?
16:15:43 <danofsatx-work> pertinent part of log: http://ur1.ca/hyuar
16:16:12 <kparal> a simple fix would be if anaconda warned you the boot menu entry is going to get replaced
16:16:24 <tflink> yeah, I'm just wondering if installing to a usb disk had something to do with the problem
16:16:31 <kparal> that doesn't require implementing dual boot support, but at least it would warn the user
16:16:37 <tflink> the problem of not booting anymore, I mean
16:16:49 <tflink> that looks like currently expected behavior to me
16:17:58 * tflink is -1 blocker on this. it could be documented better and a warning might be nice but it's not a common enough use case (IMO) to block over at alpha
16:18:35 <kparal> I just asked bcl to come over here
16:18:39 <danofsatx-work> I'm abstaining.
16:19:23 <kparal> pjones: hi, talking about 1129507
16:19:54 * satellit no way to save UEFI boot record and replace if no USB mounted on next boot?
16:19:55 <kparal> pjones: I guess multi-Fedora boot is still not supported with UEFI using anaconda?
16:20:14 <kparal> just wondering if it is a bug or a not-implemented-feature
16:20:14 <pjones> Correct, it isn't.
16:20:36 <kparal> pjones: would it be possible to at least warn the user in advance (before runnning installation) that the boot entry is going to get replaced?
16:21:01 <kparal> that could save people some surprises
16:21:16 <pjones> It's certainly theoretically possible; I'm not working on that code so I can't speak to if it's reasonable in this release cycle.
16:21:17 <kparal> just an idea, maybe there are better ones
16:22:19 <pjones> It's somewhat difficult to tell the difference between a vestigial boot entry that points off into la-la land and one that's merely /also/ correct, though.
16:22:32 <pjones> bcl: thoughts?
16:22:44 <bcl> This is difficult, since the user expects to have the drive portable, but you really can't do that with UEFI.
16:23:04 <danofsatx-work> how difficult is it to tell if it's being installed to a currently existing boot entry?
16:23:13 <bcl> I'd lean towards not allowing it at all unless they don't have a non-removable drive.
16:23:20 <kparal> bcl: ah, so that's another complication. I was thinking more about the usual use case - two Fedoras installed together (19 and 20) to the same drive
16:23:55 <bcl> yeah, that's something else that we don't currently support.
16:24:12 <bcl> IIRC we talked about adding the release number to the entry at one point.
16:24:41 <kparal> anyway, since this is not a bug but a lacking feature, I'm definitely -1. it would be -1 even for Final, unless Anaconda say they want to support it, I guess. but still, some warning or such would be nice. something to help users avoid mistakes
16:24:43 <pjones> it's not just that; we'd have to generate a subdirectory on the ESP, we'd have to change fallback to descend into them, ...
16:24:56 <pjones> it's a fairly complex RFE
16:24:57 <kparal> let's not pretend the documentation is enough
16:25:13 <pschindl> proposed #agreed - 1129507 - RejectedBlocker - Anaconda doesn't support UEFI multiboot of Fedoras yet. This is expected behaviour.
16:25:26 <bcl> pjones: right, which is probably why it didn't go anywhere.
16:25:43 <kparal> not really expected (by the user) :-) , but more of a unfortunate consequence
16:26:37 <bcl> I'll try to ponder this a bit. We certainly don't want to blow away the entry on their working system. But I also don't like adding popups for every contingency.
16:27:24 <pschindl> so just:
16:27:24 <pschindl> proposed #agreed - 1129507 - RejectedBlocker - Anaconda doesn't support UEFI multiboot of Fedoras yet.
16:27:30 <kparal> ack
16:27:46 <kparal> bcl: pjones: ok, thanks for the feedback
16:28:12 <bcl> np
16:28:14 <pschindl> any other ack/nack?
16:28:22 <tflink> ack
16:28:30 <danofsatx-work> ack
16:28:43 * danofsatx-work grumbles some more
16:28:43 <pschindl> #agreed - 1129507 - RejectedBlocker - Anaconda doesn't support UEFI multiboot of Fedoras yet.
16:29:11 <pschindl> danofsatx-work: hopefully at least discussion with anaconda was helpful and promising.
16:29:25 <pschindl> #topic (1129629) Anaconda doesn't recognize insufficient size of /boot partition
16:29:25 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1129629
16:29:25 <pschindl> #info Proposed Blocker, anaconda, ASSIGNED
16:29:30 <danofsatx-work> well, laptop is still dead, but yeah ;)
16:29:32 <tflink> danofsatx-work: did reconstructing your old boot entry not work?
16:29:53 <danofsatx-work> no, it still went looking for the usb.  I have another method I'm going to try later....
16:31:16 <pschindl> as I'm thinking about this bug now. It is more beta blocker.
16:31:37 <garretraziel> Yeah, it seems to me like -1 alpha blocker, +1 beta blocker
16:31:40 <pschindl> Because it involves custom partitioning
16:31:54 <bcl> you aren't going to hit it unless you try. Plus we have experimental support for extlinux which I'm betting uses less space than grub2
16:32:07 <kparal> yeah, the Beta criterion is better for this
16:32:41 <pschindl> bcl: good to know. So it will probably change before Beta?
16:33:16 <bcl> well, we could change it, but that may generate complaints that it defaults to too big :)
16:33:29 <bcl> But yeah, bumping it up isn't hard.
16:33:54 <kparal> -1 Alpha; propose for Beta and we will deal with it in that time if it is not fixed yet
16:34:01 <pschindl> proposed #agreed - 1129629 - RejectedBlocker - Creating small /boot partition involves custom partitioning which is in beta criterion. Reproposing for beta blocker.
16:34:27 <tflink> -1 alpha blocker from me
16:34:30 <tflink> ack
16:34:47 <kparal> ack
16:34:59 <pschindl> garretraziel: ack/nack? :)
16:35:09 <garretraziel> ack
16:35:13 <pschindl> #agreed - 1129629 - RejectedBlocker - Creating small /boot partition involves custom partitioning which is in beta criterion. Reproposing for beta blocker.
16:35:22 <pschindl> that was quick :)
16:35:34 <pschindl> #topic (1129695) please provide minimal iso images for offline use
16:35:34 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1129695
16:35:34 <pschindl> #info Proposed Blocker, distribution, NEW
16:37:17 <pschindl> This doesn't seem like blocker to me.
16:37:42 <garretraziel> I am not sure what criterion this violates.
16:37:52 <pschindl> what about no criterion :)
16:37:53 <danofsatx-work> -1 blocker
16:38:15 <satellit> -1
16:38:23 * kparal still trying to understand
16:38:49 <tflink> I'm not even sure what he's asking for
16:38:51 * satellit looks like he wants minimal live?
16:39:09 <danofsatx-work> sounds like it.
16:40:38 <kparal> -1 at the moment, it seems as a feature request to me. I'll ask him to clarify
16:40:56 <garretraziel> ok, -1
16:41:03 <amita> I read the bug and to me to -1
16:41:06 <danofsatx-work> those are the words I was looking for - thanks kparal
16:41:27 <pschindl> proposed #agreed - 1129695 - RejectedBlocker - Demand for minimal isos doesn't violate any criterion. This is feature request which should be discussed elsewhere.
16:42:31 <kparal> actually we do have boot.iso so I'm not sure what he's asking for
16:42:35 <danofsatx-work> gotta run, sorry folks
16:42:37 <tflink> ack
16:42:44 <danofsatx-work> oh, and ack that last one
16:42:48 <kparal> ack, I'll phrase it properly in the bug report
16:42:49 * satellit he mentioned offline install
16:42:55 <pschindl> danofsatx-work: thanks for your time. Have a nice day.
16:43:10 <pschindl> #agreed - 1129695 - RejectedBlocker - Demand for minimal isos doesn't violate any criterion. This is feature request which should be discussed elsewhere.
16:43:15 <danofsatx-work> for reference, 1127450 appears to have been fixed. -1 blocker on that one when we get to it.
16:43:26 <pschindl> #topic (1127450) Black screen after userless installation of KDE live
16:43:27 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1127450
16:43:27 <pschindl> #info Proposed Blocker, initial-setup, ON_QA
16:43:52 <pschindl> danofsatx-work: it could be blocker even thou it is fixed.
16:43:52 * satellit I have not tested lately...
16:44:42 <pschindl> and this one looks like blocker to me (if KDE still blocks release)
16:45:19 <amita> if login screen is missing altogether then it should be considered as blocker
16:46:53 <pschindl> as I got it. It should start in graphic, but it fails somehow to start graphic so text mode is started but on non-existent console.
16:47:09 <tflink> "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system. "
16:47:19 <satellit_e> last KDE live: Fedora-Live-KDE-x86_64-21-20140810.iso hard to test
16:47:22 <tflink> alpha release criteria
16:47:32 <pschindl> tflink: yes, it violates this one.
16:47:37 <pschindl> so I'm +1
16:47:48 <tflink> +1 per criteria
16:47:50 <mkrizek> +1
16:48:17 <satellit> +1
16:48:24 <kparal> +1
16:48:34 <garretraziel> +1
16:48:45 <amita> +1
16:49:10 <pschindl> proposed #agreed - 1127450 - AcceptedBlocker - This bug clearly violates the alpha criterion: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
16:49:58 <pschindl> so many +1s and no ack? What am I doing wrong? :)
16:50:17 <tflink> ack
16:50:19 <amita> ack :)
16:50:19 <kparal> ack
16:50:20 <mkrizek> ack
16:50:24 <satellit> ack
16:50:26 <tflink> got distracted by moztrap
16:50:28 <garretraziel> ack
16:50:30 <kparal> pschindl: poking us too little
16:50:30 <pschindl> #agreed - 1127450 - AcceptedBlocker - This bug clearly violates the alpha criterion: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
16:50:42 <pschindl> #topic (1128675) missing crucial specfile changes
16:50:42 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1128675
16:50:42 <pschindl> #info Proposed Blocker, java-1.8.0-openjdk, ASSIGNED
16:51:52 <pschindl> I have to say I probably didn't get this one.
16:52:00 <tflink> if I'm understanding this correctly, he's claiming that the upgrade to java8 isn't being done quite right and alternatives needs to  be updated
16:52:42 <tflink> not sure it's a blocker but if he's right, that is a bug that should be fixed
16:53:06 <pschindl> so it looks more like FreezeException.
16:53:41 <tflink> why? it's not on the livecd, is it?
16:53:49 <pschindl> no?
16:54:00 <tflink> what would the FE be for?
16:54:41 <pschindl> Mea culpa. I will think twice next time. Ok. Than I'm just -1.
16:54:47 <tflink> either way, he doesn't need a blocker or FE to do this right now
16:55:10 <kparal> it's on Live
16:55:47 <amita> to me if the alternatives are there to fix the specfile, then it should not be a blocker.
16:56:59 <pschindl> any other thoughts?
16:57:22 <pschindl> mkrizek: what do you think? :)
16:58:14 <mkrizek> seems like not a blocker to me
16:58:55 <kparal> I think this should be moved to FE
16:59:01 <kparal> not a blocker
16:59:02 <tflink> -1 blocker since there is no criteria for features being done
16:59:33 <pschindl> ok. Will we discuss FE right now?
16:59:34 <tflink> I'd be open to a FE on this if it's not done before freeze
16:59:46 <tflink> let's cross that bridge if and when we get there
17:00:08 <pschindl> We can repropose it as FE and wait if they make it before freeze.
17:00:29 <tflink> tell him that he can propose as FE if it isn't done before freeze
17:00:42 <tflink> but before then, he can just follow normal major package upgrade policies
17:01:38 <pschindl> proposed #agreed - 1128675 - RejectedBlocker - Missing components in specfile isn't blocker. If needed this could be re-proposed as Freeze Exception
17:02:48 <tflink> patch: isn't a blocker by itself
17:03:21 <pschindl> proposed #agreed - 1128675 - RejectedBlocker - Missing components in specfile isn't blocker by itself. If needed this could be re-proposed as Freeze Exception
17:03:37 <pschindl> tflink: thanks. At least someone is reading it :)
17:03:48 <tflink> ack
17:04:31 <kparal> ack
17:04:56 <pschindl> #agreed - 1128675 - RejectedBlocker - Missing components in specfile isn't blocker by itself. If needed this could be re-proposed as Freeze Exception
17:05:12 <pschindl> ok. So the last proposed blocker for today:
17:05:18 <pschindl> #topic (1119251) [abrt] tracker: vasprintf(): tracker-store killed by SIGSEGV
17:05:18 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1119251
17:05:18 <pschindl> #info Proposed Blocker, tracker, ASSIGNED
17:06:45 * satellit is yum upgrade a blocker?
17:06:48 <pschindl> This seems to happen on upgraded systems
17:06:55 <tflink> I'm failing to see how this could be an alpha blocker
17:07:22 <kparal> -1 Alpha, upgrade issues are Beta
17:07:23 <pschindl> I don't think it is. It's about upgrading and that's beta or final.
17:07:26 <tflink> -1 since it's an upgrade issue and doesn't hit the alpha criterion
17:07:27 <pschindl> -1
17:07:30 <kparal> of course fedup should be used
17:07:31 <tflink> criteria
17:07:31 * danofsatx-work is back
17:07:46 <danofsatx-work> -1 blocker on alpha, maybe beta or final
17:08:43 <tflink> eh, I'm not a fan of people proposing blockers with no research
17:09:03 <tflink> if he really thinks it's a blocker, he can re-propose with some criteria violation :)
17:09:31 <pschindl> proposed #agreed - 1119251 - RejectedBlocker - This seems to happen only on upgraded systems which doesn't block alpha. Re-proposed for beta blocker.
17:09:32 * danofsatx-work rereads
17:09:55 <danofsatx-work> -1
17:09:57 <danofsatx-work> ack
17:10:12 <danofsatx-work> it doesn't prevent booting or use of the system
17:10:34 <tflink> patch: s/re-proposed for beta blocker/if this is still an issue at beta with fedup upgrades, please re-propose as a beta blocker if it violates any of those criteria/
17:10:48 <tflink> yeah, I don't think this could be a beta or final blocker
17:11:02 <tflink> unless the problem at startup is worse than it sounds
17:11:10 <tflink> not clear to me if it's causing problems @ login
17:11:27 <pschindl> proposed #agreed - 1119251 - RejectedBlocker - This seems to happen only on upgraded systems which doesn't block alpha. If this is still an issue at beta with fedup upgrades, please re-propose as a beta blocker if it violates any of those criteria
17:11:33 <amita> tflink, thanks for detailed info
17:11:44 <kparal> ack
17:11:47 <tflink> ack
17:11:48 <amita> ack
17:11:49 <danofsatx-work> only  clue is "Crashes in the background while I'm doing nothing" - that's not a blocker, that's an annoying bug.
17:11:59 <pschindl> #agreed - 1119251 - RejectedBlocker - This seems to happen only on upgraded systems which doesn't block alpha. If this is still an issue at beta with fedup upgrades, please re-propose as a beta blocker if it violates any of those criteria
17:12:04 <tflink> yeah, annoying but fix-able with an update
17:12:13 <pschindl> So that were all proposed blockers.
17:12:33 <tflink> IIRC, we don't consider yum-upgrade-only issues to be blockers anyways
17:12:34 <pschindl> I don't think that we have to go through FE.
17:13:09 <pschindl> Or do you want to look at the only proposed FE?
17:13:20 <pschindl> If not we can move to accepted blockers.
17:13:50 <kparal> nooo, accepted blockers, nooo
17:13:57 <tflink> they're discussion f21 schedule in fesco meeting ATM
17:14:17 <danofsatx-work> that FE hasn't been touched since 07/09
17:14:19 <pschindl> kparal: I thought they are your favorite one :)
17:14:31 <danofsatx-work> or 09/07 for y'all from outside the US ;)
17:15:25 <kparal> let's skip FE
17:15:39 <danofsatx-work> +1 skip
17:15:42 <pschindl> cool. So first accepted blocker:
17:15:57 <pschindl> #topic (1127103) Workstation image compose sometimes fails due to filesystem consistency issues (caused by sssd library being held open)
17:15:57 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1127103
17:15:57 <pschindl> #info Accepted Blocker, distribution, NEW
17:16:50 <tflink> IIRC, this is being worked on and doesn't need anythign from us
17:16:53 <danofsatx-work> is it still happening? We've had successful composes since we last addressed it - I haven't had a chance to see why the latest ones failed yet.
17:17:00 <tflink> er, as near as I can tell, not IIRC
17:17:50 * satellit failure due to resize on build?
17:18:02 <kparal> let's listen to tflink and move on
17:18:10 <pschindl> #info Releng team works hard on bug 1127103. No need for action from our side for now.
17:18:16 <kparal> (blame him if something goes wrong)
17:18:25 <pschindl> #topic (1109603) dracut unable to boot 3.16 most of the time
17:18:25 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1109603
17:18:26 <pschindl> #info Accepted Blocker, dracut, NEW
17:18:44 <danofsatx-work> we need a new .blame for zodbot......
17:18:48 <tflink> kparal: so that's how it works, is it?  :-P
17:19:13 <jsmith> We spoke with Harald Hoyer about this bug at Flock
17:19:15 <tflink> it sounds to me like they're waiting on logs and probinson is working to get them
17:19:31 <pschindl> so everything is fine :)
17:19:38 <jsmith> At first the blame as pointed at the filesystem growing, but that isn't the cause
17:19:55 <jsmith> So Peter Jones agreed to put some traces in and track down more information
17:20:31 <pschindl> #info it seems like bug 1109603 has needed attention and there is some work on it.
17:20:44 <pschindl> #topic (1123845) Server presets not applied in systemd scriptlets
17:20:44 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1123845
17:20:44 <pschindl> #info Accepted Blocker, fedora-release, NEW
17:21:17 <danofsatx-work> mitr patched it, but I haven't tested it yet.
17:21:58 <danofsatx-work> releng ticket is closed: https://fedorahosted.org/rel-eng/ticket/5955
17:22:01 <tflink> might be worth poking people to see if there was any progress
17:22:02 <kparal> it seems no progress since 08-01
17:22:21 <tflink> I don't think that server was as affected by compose issues but I could be mios-remembering
17:22:36 <danofsatx-work> server isn't being composed
17:22:43 <tflink> nvm, then
17:22:49 <tflink> is it even testable yet?
17:23:12 <danofsatx-work> I'm not sure, that's why I haven't tested it. I'm installing by selecting "server" from a boot.iso load....
17:24:25 <tflink> might be worth pestering them for an update
17:24:43 <pschindl> who is volunteer? :)
17:24:52 <danofsatx-work> I'll take it
17:25:59 <pschindl> #action danofsatx-work to pester right people for an update
17:26:25 <pschindl> #topic (1088933) update grubby to support device tree options for arm
17:26:25 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1088933
17:26:25 <pschindl> #info Accepted Blocker, grubby, POST
17:26:36 <pschindl> last three
17:28:14 <pschindl> hmm. There is one comment from last week and no answer.
17:29:37 <kparal> should we ask bcl for a status update?
17:29:53 <tflink> pwhalen: do you know anything about the status on 108893?
17:30:29 <pschindl> pwhalen: 1088933
17:32:27 <pwhalen> sorry, stepped away. I dont know of any change. in progress . dgilmore has been busy
17:32:37 <tflink> let\s just ask for another status update in the bug
17:32:50 <tflink> or not, awesome timing on my part
17:33:09 <dgilmore> ive started on updating things but ive not yet gotten it right
17:33:29 <dgilmore> it will be done when i can get time to finish it
17:34:24 <tflink> dgilmore: thanks for the update
17:34:42 <pschindl> #info dgilmore has this on his probably veeery full todo list. When there will be time he will finish it.
17:35:06 <pschindl> #topic (1110758) SELinux prevents cockpit from working on Fedora 21
17:35:07 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1110758
17:35:07 <pschindl> #info Accepted Blocker, selinux-policy-targeted, NEW
17:36:45 <danofsatx-work> this one is being actively worked. I haven't test it lately, though due to my "other" issues :(
17:37:53 * satellit afk
17:38:06 <pschindl> #info There is an active work on bug 1110758
17:38:24 <pschindl> and the last one to bother us.
17:38:30 <pschindl> #topic (1044778) wandboard uboot missing serial line speed in console environment variable
17:38:30 <pschindl> #link https://bugzilla.redhat.com/show_bug.cgi?id=1044778
17:38:30 <pschindl> #info Accepted Blocker, uboot-tools, NEW
17:39:09 <tflink> looks like another issue waiting for dgilmore to have free cycles
17:39:28 <pschindl> we should clone him
17:39:34 <dgilmore> I have started updating u-boot
17:39:40 <dgilmore> to a newer upstream build
17:39:54 <dgilmore> and im not sure this will actually be fixed, its not totally a bug
17:40:52 <tflink> dgilmore: thanks for the update
17:41:09 <pschindl> #info dgilmore works on this (bug 1044778).
17:41:38 <pwhalen> dgilmore, consistency between uboots then, others include the baudrate
17:41:41 <pschindl> ok. Do you have something else? If not we can end this great meeting. It was fun :)
17:42:00 <danofsatx-work> lunch has been calling for while now.....
17:42:04 <dgilmore> pwhalen: talk to upstream.
17:42:12 <dgilmore> many do not have it
17:42:16 <tflink> #info u-boot will be updated to a newer upstream build soon. this particular bug may not be fixed with the update
17:42:21 <pschindl> danofsatx-work: yep. My dinner is getting cold too :)
17:42:27 <dgilmore> and it works the speed that the kernel defaults to is slower
17:42:42 <dgilmore> tflink: i dont really see it as a bug
17:43:06 <tflink> I think we were under the impression that serial console didn't work at all without the speed change/specification
17:43:15 <pwhalen> it doesnt.
17:43:35 <dgilmore> tflink: it works just fine, the kernel defaults to 9600 or 38800 i cant remeber which
17:43:37 <tflink> I'm hearing different things from both of you
17:43:50 <dgilmore> you get some corruption due to speed missmatches
17:44:07 <tflink> if that's the case, I'm not sure it's even a blocker
17:44:13 <pwhalen> other boards include it, in the uboot we provide. ie - console=ttyO2,115200n8 , the wandboard breaks the console variable in two iirc, baudrate= and console=
17:44:45 <tflink> workaround: change the speed of your serial console
17:44:46 <pwhalen> i may have been premature with blocker, as its specific piece of hw
17:44:58 <pwhalen> but its also an easy fix.
17:45:09 <danofsatx-work> ok, I really do have to run. it's been fun....
17:45:18 <tflink> if the console actually works but at a slower speed, I'm -1 blocker on this
17:45:23 <pwhalen> and one of our primary pieces of hw
17:45:32 <pwhalen> it doesnt work
17:45:40 <tflink> pwhalen: dgilmore just said that it did
17:45:50 <tflink> just at a slower baud than expected
17:46:15 <tflink> you two are saying two different things
17:46:26 <dgilmore> there is a few workarounds
17:46:29 <pwhalen> seems so.
17:46:46 <dgilmore> its not really an area i want to diverge from upstream
17:47:04 <dgilmore> its probably simpler for people if we patch u-boot
17:47:13 <dgilmore> but it works just fine if we dont
17:47:21 <pwhalen> ..with a workaround
17:47:28 <tflink> at alpha
17:47:28 <pwhalen> adding in the baudrate manually
17:47:34 <pwhalen> a pain, imo
17:47:34 <dgilmore> you can add the console line with 115200 as the speed in extlinux.conf
17:47:40 <pwhalen> or that
17:47:44 <tflink> or changing the other end of your console to 9600?
17:47:46 <dgilmore> or you can use the slower speed when connecting to the serial port
17:48:01 <dgilmore> I really do not see it as an alpha blocker
17:48:17 <dgilmore> maybe beta, in my opinion its a nice to have fix
17:48:45 <pschindl> I don't thing it's alpha blocker too. So should we re-propose it or just discuss it next time?
17:48:52 <dgilmore> it is not necessarily consistent with other boards
17:49:01 <pwhalen> I'm ok with that, given its hw specific
17:49:10 <pwhalen> ...but an easy fix.
17:50:04 <tflink> dgilmore: just to be clear, are you saying that the fix to force the correct speed for wandboard is a bit too hacky?
17:50:09 <tflink> or am I misunderstanding?
17:50:43 <pwhalen> i see as being consistent with all other uboots we ship (that i know of anyways)
17:50:57 <dgilmore> tflink: its not hacky its a one line change, but its a divergance from upstream, and I do not know if they chose to do it as they did for a reason
17:51:09 <dgilmore> its something that needs discussed with the upstream maintainer
17:51:16 <dgilmore> I do not want to carry the patch forever
17:51:40 <tflink> ok, let's hold off on blocker status discussion here until that conversation has happened
17:52:29 <pschindl> ok. So if you don't have anything else I'd ended this meeting.
17:52:45 <tflink> #info the requested patch for wandboard console speed is a divergence from upstream and they need to be consulted before we start changing things. will discuss blocker status once that conversation has happened
17:52:52 <pschindl> tflink: thank you.
17:53:06 <pschindl> Nothing else?
17:53:44 <pschindl> No? Than thank you all for joining the party!
17:53:46 <tflink> I don't think so
17:53:50 <pschindl> #endmeeting