16:00:15 <adamw> #startmeeting F25-blocker-review
16:00:15 <zodbot> Meeting started Mon Aug 15 16:00:15 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:15 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:15 <adamw> #meetingname F25-blocker-review
16:00:15 <adamw> #topic Roll Call
16:00:15 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:26 <adamw> ahoy hoy, who's here for some blocker review fun?
16:00:46 * kparal is here
16:01:36 * kparal pokes pschindl
16:01:45 * pschindl is here
16:01:51 <pschindl> kparal: thanks :)
16:02:10 <kparal> you're welcome, I enjoy poking people
16:02:36 <adamw> brunowolff: dgilmore: nirik: danofsatx: pwhalen: rdieter_work: satellit: sgallagh: tflink: BLOCKER REVIEW PING
16:02:42 * coremodule is here.
16:02:54 * pwhalen is here
16:04:45 <adamw> alrighty, that's five of us at least
16:05:02 <adamw> #chair coremodule pwhalen
16:05:02 <zodbot> Current chairs: adamw coremodule pwhalen
16:05:12 <adamw> #topic Introduction
16:05:12 <adamw> Why are we here?
16:05:12 <adamw> #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:05:12 <adamw> #info We'll be following the process outlined at:
16:05:15 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:16 <adamw> #info The bugs up for review today are available at:
16:05:18 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:20 <adamw> #info The criteria for release blocking bugs can be found at:
16:05:22 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
16:05:24 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
16:05:26 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
16:05:28 <adamw> Alpha bug counts:
16:05:30 <adamw> #info 1 Proposed Blockers
16:05:32 <adamw> #info 4 Accepted Blockers
16:05:34 <adamw> #info 3 Proposed Freeze Exceptions
16:05:36 <adamw> #info 3 Accepted Freeze Exceptions
16:05:47 <adamw> we also have 2 Proposed (Beta) and 1 Proposed (Final)
16:05:52 <adamw> #info we also have 2 Proposed (Beta) and 1 Proposed (Final)
16:06:49 <jkurik> .hello jkurik
16:06:50 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
16:06:59 <adamw> ahoy jkurik
16:07:05 <jkurik> ahoj
16:07:34 <coremodule> Glad to act as secretary if needed.
16:08:28 <adamw> #info coremodule to secretarialize
16:08:43 <adamw> coremodule: thanks - did you get my note from last week about making sure bugs block the right trackers as well as changing the whiteboard?
16:09:00 <coremodule> No, I didn't, was it an email?
16:09:05 <adamw> bug comment
16:09:21 <adamw> in a few cases we e.g. accepted a bug as a blocker for a different milestone or made a bug an FE which wasn't nominated as one
16:09:36 <adamw> you have to make sure the bug is blocking the right tracker, as well as adding the right whiteboard field, in those cases
16:10:12 <coremodule> Ah, I did see something now that you mention it. Alright, I understand. The tracker being the drop-down box with the release version number in it, right?
16:11:01 <adamw> no, 'tracker bug'
16:11:09 <adamw> as in, AlphaBlocker, BetaBlocker, AlphaFreezeException etc
16:11:14 <adamw> in the Blocks: field
16:11:36 <adamw> if we accepted a bug as an Alpha freeze exception, as well as having AcceptedFreezeException in the whiteboard, make sure it Blocks: AlphaFreezeException
16:11:56 <coremodule> Gotcha, I can do that. Sorry about that last week.
16:12:09 <adamw> npnp
16:12:45 <adamw> alrighty, let's get rolling
16:12:55 <adamw> #info starting with the Alpha proposed blocker
16:12:58 <adamw> #topic (1366403) [abrt] sssd-common: ipa_dyndns_update_send(): sssd_be killed by SIGSEGV
16:12:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366403
16:12:59 <adamw> #info Proposed Blocker, sssd, NEW
16:14:11 <adamw> so this is basically a breakage in one of the possible ways you can enrol a system as a freeipa client'
16:14:50 <adamw> doing it post-install works OK. doing it during install with a kickstart seems to work OK, but then sssd_be crashes on first boot of the installed system and seems to break domain user auth.
16:15:14 <adamw> i haven't checked yet whether it works on a second boot, since this is an openQA test (makes it a bit trickier to try out different variations)
16:15:35 <jsmith> Seems like a straightforward blocker to me
16:16:14 * jsmith just got pulled into another meeting -- will return as quickly as he can
16:17:29 <adamw> the criterion, for the record, is "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain. "
16:17:49 <adamw> jsmith: the 'does it work on second boot?' question is one i only just thought of, but i'd quite like to have the answer to that...
16:18:04 <adamw> if it happens every boot, yeah, i'd be +1. if it's a one-off i might be OK with a commonbugs note
16:18:04 <pwhalen> right
16:18:32 <jkurik> according to the maintainer it is already fixed in upstream
16:18:44 <coremodule> So in this case, it join the domain, but then causes other things to crash?
16:18:49 <adamw> i can recreate this manually (sigh...i hate doing that) after the meeting and see
16:19:07 <adamw> coremodule: well, sorta. the thing that crashes is a part of the whole domain client stuff
16:19:11 <adamw> so it's not some random, unrelated thing
16:19:47 <adamw> the domain join during install works fine, on boot a process which is a key part of the way remote auth works crashes, so although the system is demonstrably joined to the domain, auth doesn't work right.
16:20:19 <adamw> jkurik: yeah, he says it's 'only a band-aid' but i'm fine with a band-aid at this point
16:20:32 <coremodule> Gotcha. In that case I'd be +1 since the failure causes issues with the join.
16:21:48 <jkurik> I would be +1 to block on this (and hope it is fixed before go/no-go :-) )
16:22:06 <pschindl> +1 from me too
16:22:13 <adamw> ok, how about this - we can accept it provisionally for now, and i'll try and test it locally after the meeting to check i can reproduce it and see if it persists across boots
16:22:33 <pwhalen> adamw, wfm, +1
16:22:54 <adamw> proposed #agreed 1366403 - AcceptedBlocker (Alpha) - this appears to violate "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain." adamw will test this in a bit more detail after the meeting to see if it's only a transient failure
16:23:10 <kparal> ack
16:23:19 <coremodule> ack
16:23:20 <jkurik> ack
16:23:25 <adamw> #agreed 1366403 - AcceptedBlocker (Alpha) - this appears to violate "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain." adamw will test this in a bit more detail after the meeting to see if it's only a transient failure
16:23:28 <pwhalen> ack
16:23:45 <adamw> #info moving onto proposed Beta blockers
16:23:53 <adamw> #topic (1366793) Nothing obsoletes retired dnf-langpacks packages, breaks upgrade from Fedora 23 to 25+
16:23:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366793
16:23:53 <adamw> #info Proposed Blocker, dnf, ASSIGNED
16:23:56 <adamw> brb, call of nature
16:24:29 <jkurik> :)
16:25:07 <kparal> +1, breaks upgrade criterion
16:25:22 <pschindl> +1
16:25:26 <jsmith> +1
16:25:38 <kparal> I'm not sure we want to rely on allowerasing
16:26:03 <kparal> is that something we want to advise people to use even for unmodified default installs?
16:26:07 <pwhalen> +1
16:26:17 <jsmith> kparal: I agree with you -- that seems.... dangerous?
16:26:35 <jsmith> kparal: I wouldn't suggest advising people to use that in general
16:27:10 <kparal> without any third-party repos in the system, ideally there should be no need for allowerasing, the way I see it
16:27:48 <kparal> well, it's true that some packages get retired and nothing obsoletes them
16:28:32 <kparal> so unless there's some solution to that, there might be a need for allowerasing from time to time
16:29:19 <adamw> yeah, that's my main concern, sometimes it's actually a bit difficult to obsolete things properly
16:29:26 <jkurik> kparal: why do you think we should not rely on it (allowerasing) ?
16:29:27 <kparal> hmm, I'm no longer so sure of the +1
16:29:53 <adamw> i actually now am kinda curious to look at the packaging policies again and see exactly what they say about retirement...
16:29:58 <kparal> jkurik: it can potentially remove important parts of the system and some users will not be able to spot it beforehand
16:30:05 * jkurik has no experience with allowerasing, so he needs a bit of education
16:30:10 <adamw> kparal: one question is, what does the graphical upgrade process do here?
16:30:42 <kparal> adamw: they have a similar mechanism to allowerasing. but uses different libraries. we would need to test both tools
16:30:46 <jkurik> kparal: thanks
16:31:11 <kparal> s/they/it
16:31:35 <adamw> kparal: k, thanks
16:31:42 <adamw> the guidelines are pretty useless here
16:31:52 <adamw> i'm actually inclined to file a ticket with fpc and request some clarification here...thoughts?
16:32:19 <kparal> I guess this depends whether dnf-langpacks is something that makes sense to merge into some other existing package, or whether it stopped to exist without any replacement
16:33:04 <kparal> it would be nice if dnf or something else obsoleted it, but I'm no longer sure this is a +1 blocker, if the allowerasing option (and gnome-software) allows to perform the upgrade anyway
16:33:07 <adamw> there is a replacement mechanism, but not a really obvious candidate for a replacement package
16:33:51 <adamw> i can make the openqa tests detect this kind of error and try a --allowerasing run and softfail if that works...
16:35:18 <jsmith> adamw: I'm fine with an FPC ticket -- clarification is always good :-)
16:35:22 <kparal> yeah, but I'm no longer sure we want to block on obsolete issues (as long as they work with allowerasing), because there seems to be no official way in fedora how to obsolete packages without a replacement
16:35:45 <kparal> a clarification could help, sure
16:35:51 <adamw> that's kinda why i want to go to FPC
16:36:00 <kparal> what is the question going to be?
16:36:06 <adamw> ask them to draft procedures for this, including considering the question of whether all retired packages must be obsoleted somehow...
16:36:25 <kparal> or at least in the default install/critpath set
16:36:46 <kparal> but I'm not sure it's wise to make a difference here
16:37:34 * kparal is +1 to ask FPC for clarification
16:37:48 <adamw> this is a proposed beta blocker, as a reminder, so we do have time
16:38:00 <kparal> so punt for the moment
16:38:37 <jkurik> kparal: imo we should make a difference here as retirement of some packages without replacement can make a problem, on the other side retirement of other packages breaks nothing
16:38:58 <adamw> jkurik: well, there's always a potential problem for anyone who has the package installed
16:39:14 <adamw> it's just that some packages are more *likely* to be installed than others, but that's not a great justification
16:39:26 <adamw> we don't have to decide it, though :)
16:39:33 <jkurik> hmm..probably a topic for FPC to consider
16:40:26 <adamw> proposed #agreed 1366793 - punt (delay decision) - we are not sure whether 'workarounding' this with allowerasing (or equivalent) is acceptable, and can't really decide in the absence of any packaging policy covering what to do with retired packages if Obsoletes + Provides is not appropriate. will refer to FPC for consideration
16:41:01 <jkurik> ack
16:41:08 <kparal> ack
16:42:23 <pwhalen> ack
16:42:35 <pschindl> ack
16:42:44 <jsmith> ack
16:42:57 <adamw> #agreed 1366793 - punt (delay decision) - we are not sure whether 'workarounding' this with allowerasing (or equivalent) is acceptable, and can't really decide in the absence of any packaging policy covering what to do with retired packages if Obsoletes + Provides is not appropriate. will refer to FPC for consideration
16:43:06 <adamw> #topic (1362165) doesn't connect to wifi after resume
16:43:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1362165
16:43:06 <adamw> #info Proposed Blocker, NetworkManager, ON_QA
16:43:33 <adamw> ah, we delayed this one so people could consider criteria changes
16:43:40 <adamw> i don't see any criteria change proposals, so probably nothing much to discuss
16:44:54 <jsmith> Yeah, I don't see a reason to discuss
16:46:19 <adamw> #info this is in 'punt' status expecting some criteria revision proposals, but we haven't had any yet, so nothing much to discuss
16:46:26 <adamw> moving on to final blockers...
16:46:38 <adamw> #info moving to final blocker
16:46:39 <adamw> #topic (1363914) [abrt] qupzilla: base::debug::BreakDebugger(): qupzilla killed by SIGABRT
16:46:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1363914
16:46:39 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
16:47:15 <adamw> +1, definitely a final blocker so long as the browser is on the KDE image
16:47:17 * lupinix filed this one
16:47:36 <cmurf> yes +1 blocker, but also FE pretty much whenever
16:47:41 <kparal> the vote for the default browser in KDE haven't been concluded yet, IIRC
16:47:57 <kparal> until then, what is the default browser? isn't it firefox?
16:48:07 <lupinix> yes, no final results. but qtwebengine is also used by other components
16:48:23 <kparal> such as?
16:48:24 <lupinix> firefox is default right now
16:48:39 <adamw> yeah, so this isn'
16:48:42 <adamw> t an alpha blocker.
16:48:57 <adamw> but there's a final criterion that all apps included should basically work.
16:49:05 <lupinix> yes, it is only final
16:49:14 <kparal> yeah, I'm just interested to know which apps are broken by this
16:49:21 <kparal> is qupzilla installed by default?
16:49:24 <lupinix> yes
16:49:28 <kparal> ok
16:49:30 <pwhalen> is Konqueror no longer the browser for kde?
16:49:46 <adamw> hadn't been for a while, it was replaced by firefox as the default web browser several cycles back
16:49:58 <kparal> if qupzilla is on the Live image, then +1 Final
16:50:03 <pschindl> +1
16:50:06 <pwhalen> ah, good choice
16:50:30 <pwhalen> +1
16:50:37 <jkurik> +1
16:50:51 <lupinix> is chromium on any image by default? because the selinux bug also breaks chromium
16:51:19 <adamw> not so far as i know.
16:52:06 <adamw> proposed #agreed 1363914 - AcceptedBlocker (Final) - violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:52:19 <jkurik> ack
16:52:49 <kparal> ack
16:52:51 <coremodule> ack
16:53:05 <pwhalen> ack
16:53:35 <adamw> #agreed 1363914 - AcceptedBlocker (Final) - violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."
16:54:15 <adamw> alright, let's go back and review alpha accepted blocker
16:54:23 <adamw> #info moving to Alpha accepted blockers
16:54:30 <adamw> #undo
16:54:30 <zodbot> Removing item from minutes: INFO by adamw at 16:54:23 : moving to Alpha accepted blockers
16:54:35 <adamw> actually - proposed freeze exceptions first
16:54:41 <adamw> #info moving to Alpha proposed freeze exceptions
16:54:47 <adamw> #topic (1365686) kernel BUG at mm/rmap.c:1288!
16:54:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1365686
16:54:47 <adamw> #info Proposed Freeze Exceptions, kernel, ON_QA
16:55:25 <adamw> i'm +1 for this, if the kernel team wants it. seems fine.
16:55:39 <adamw> we need karma on this and other blocker/FE bugs, though...i'll send out an email about that later
16:55:57 <cmurf> +1 FE
16:56:45 <jkurik> +1 FE
16:56:51 <pwhalen> +1 FE
16:57:39 <pschindl> +1 FE
16:57:41 <kparal> +1 FE
16:57:42 <adamw> proposed #agreed 1365686 - AcceptedFreezeException (Alpha) - seems significant enough to ensure it's fixed on the live images, kernel team requested.
16:58:10 <kparal> ack
16:58:16 <pwhalen> ack
16:59:27 <jkurik> ack
16:59:33 <adamw> #agreed 1365686 - AcceptedFreezeException (Alpha) - seems significant enough to ensure it's fixed on the live images, kernel team requested.
16:59:42 <adamw> #topic (1366554) template fixes for alternative arches
16:59:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366554
16:59:42 <adamw> #info Proposed Freeze Exceptions, lorax, MODIFIED
17:00:05 <cmurf> +1 FE, it's required to get a successful compose on ppc64le
17:00:10 <adamw> yeah, per github...+1
17:00:58 <pwhalen> +1
17:01:39 <adamw> proposed #agreed 1366554 - AcceptedFreezeException (Alpha) - this is needed to fix compose of secondary arch (ppc64le), by convention we accept these as FEs so the freeze doesn't prevent work on secondary arches
17:01:56 <jkurik> ack
17:02:01 <cmurf> ack
17:02:01 <kparal> ack
17:02:27 <adamw> #agreed 1366554 - AcceptedFreezeException (Alpha) - this is needed to fix compose of secondary arch (ppc64le), by convention we accept these as FEs so the freeze doesn't prevent work on secondary arches
17:02:37 <adamw> #topic (1364781) QtWebEngine 5.7.0 breaks when built against glibc 2.24 (2.23.90) which defines MADV_FREE
17:02:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1364781
17:02:37 <adamw> #info Proposed Freeze Exceptions, qt5-qtwebengine, MODIFIED
17:02:51 * lupinix also filed this one
17:03:14 <adamw> is this different from the final blocker?
17:03:18 <lupinix> yes
17:03:31 <adamw> so would we need to fix both that and this in order to have qupzilla actually work?
17:03:47 <lupinix> there was an issue with qtwebengine and glibc 2.24, but the glibc one is fixed
17:04:05 <lupinix> fix is waiting to be pushed to updates-testing
17:04:12 <cmurf> is there a potential downside to accepting it?
17:04:33 <lupinix> i don't know any
17:04:46 <cmurf> +1 FE
17:05:55 <adamw> i guess i'm +1 FE for both this and the other one
17:06:41 <jkurik> lupinix: what is waiting to be pushed to updates-testing ? qt5-qtwebengine fix or the glibc fix ?
17:07:03 <lupinix> qt5-qtwebengine fix to work with glibc 2.24
17:07:13 <lupinix> glibc itself was not ouched
17:07:15 <lupinix> *touched
17:07:20 <pwhalen> +1 FE
17:07:46 <jkurik> +1 FE
17:08:10 <adamw> proposed #agreed 1364781 - AcceptedFreezeException (Alpha) - bug affects a prominent app on the KDE live image, so cannot be fully fixed with an update, fix does not touch glibc so possible negative impact should be restricted
17:08:35 <cmurf> ack
17:08:59 <jkurik> ack
17:09:08 <jsmith> ack
17:09:12 <adamw> #agreed 1364781 - AcceptedFreezeException (Alpha) - bug affects a prominent app on the KDE live image, so cannot be fully fixed with an update, fix does not touch glibc so possible negative impact should be restricted
17:09:23 <lupinix> thanks :)
17:09:27 <cmurf> next FE for beta should be for alpha per comment 3
17:09:30 <adamw> does anyone mind if we go back to the other bug and vote FE on that one?
17:09:40 <cmurf> no
17:09:49 * jsmith has no problem with that
17:09:54 <jkurik> no problem
17:09:55 <adamw> #topic (1363914) [abrt] qupzilla: base::debug::BreakDebugger(): qupzilla killed by SIGABRT
17:09:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1363914
17:09:55 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
17:10:00 <adamw> #info re-visiting this bug to consider Alpha FE
17:10:04 <adamw> +1 Alpha FE for me
17:10:08 <cmurf> +1 FE
17:10:11 <jsmith> +1 FE from me
17:10:12 <pschindl> +1 FE
17:10:13 <pwhalen> +1 FE
17:10:23 <adamw> proposed #agreed 1363914 - AcceptedFreezeException (Alpha) - bug affects a prominent app on the KDE live image, so cannot be fully fixed with an update, fix does not touch glibc so possible negative impact should be restricted
17:10:28 <cmurf> ackchoo
17:10:38 <adamw> coremodule: so this is one where you'll have to add AlphaFreezeException to the Blocks: field as well as adding the whiteboard string
17:10:52 <jkurik> ack
17:11:16 <pwhalen> ack
17:11:21 <adamw> #agreed 1363914 - AcceptedFreezeException (Alpha) - bug affects a prominent app on the KDE live image, so cannot be fully fixed with an update, fix does not touch glibc so possible negative impact should be restricted
17:11:55 <adamw> #topic (1366023) digikam has broken dependencies
17:11:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366023
17:11:55 <adamw> #info Proposed Freeze Exceptions, digikam, MODIFIED
17:12:08 <adamw> #info this was accidentally proposed as a Beta FE but was meant to be proposed for Alpha, will fix
17:13:05 <cmurf> seems constrained to this one thing so I'm +1 FE
17:13:06 <adamw> hum, wouldn't this actually prevent the KDE live composing at all?
17:13:18 <coremodule> adamw, Alright, I understand.
17:14:11 <rdieter_work> adamw: I thought it would, though I haven't verified the package list getting installed... maybe the affected bits aren't getting installed (as expected)
17:14:11 <cmurf> but there are live composes happening
17:14:22 <adamw> yeah
17:14:44 <rdieter_work> I suspect that means that Recommends: soft deps (still) aren't getting pulled in by default
17:15:11 <adamw> fedora-live-kde.ks:-digikam			# digikam has duplicate functionality with gwenview (~28 megs)
17:15:14 <rdieter_work> (separate issue I'll try to look closer at later)
17:15:30 <adamw> rdieter_work: that would be my understanding. from other discussion, those deps are dropped in the compose process.
17:15:33 <adamw> but check with dgilmore.
17:15:57 <rdieter_work> ok, though last I'd heard that was supposed to get fixed for f25 (definitely did not work in f24)
17:16:04 <adamw> so digikam is explicitly excluded from the KDE live
17:16:21 <rdieter_work> ok, confirmed ^^, digikam is not included on spin and is the only affected component
17:16:27 <rdieter_work> sorry, my bad
17:16:45 <adamw> i could still go for an FE just to fix up the deps in stable, i guess
17:16:46 <rdieter_work> (I thought kipi-plugins, generated from same src.rpm used this dependency too)
17:17:38 <jkurik> adamw: I am fine with FE as well, just to have "clean table"
17:18:12 <cmurf> i'm still +1
17:19:27 <adamw> proposed #agreed 1366023 - AcceptedFreezeException (Alpha) - we confirmed this does not actually affect the KDE live image, but we're still OK granting a freeze exception to fix the broken dependencies in the 'stable' repository
17:19:39 <jkurik> ack
17:20:35 <jsmith> ACK
17:22:39 <adamw> #agreed 1366023 - AcceptedFreezeException (Alpha) - we confirmed this does not actually affect the KDE live image, but we're still OK granting a freeze exception to fix the broken dependencies in the 'stable' repository
17:22:58 <adamw> alrighty, so now we really can move on to accepted blocker review
17:23:06 <adamw> #moving to the Alpha accepted blockers
17:23:12 <adamw> #topic (1365661) Cloud images fail to compose from 20160809.n.0
17:23:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1365661
17:23:12 <adamw> #info Accepted Blocker, distribution, NEW
17:23:47 <adamw> so we just don't have much info on this one
17:23:55 <adamw> i know releng has been looking at it, but apparently not updating the bug
17:24:10 <cmurf> hmm i'm getting an error from fedfind today about metadata
17:24:25 <adamw> pastebin?
17:24:29 <adamw> oh
17:24:56 <cmurf> I don't think it's a fedfind problem I think it's a pungi issue (?)
17:25:01 <adamw> huh, it shouldn't be trying to do 20160815.n.0, dunno why it is.
17:25:03 <cmurf> Might be temporary
17:25:09 <adamw> i'll look at it later.
17:25:41 <cmurf> Yeah was just looking to see if any cloud images were being made
17:25:52 <adamw> anyhow, basically we haven't had a successful f25 or rawhide compose for several days
17:26:13 <adamw> dgilmore: nirik: any word on the status of f25/rawhide composes?
17:26:35 <nirik> there's ones running now we have hopes for.
17:27:23 <adamw> okay. did we ever find out what was stopping the cloud images specifically from building? or does that still need fixing once the overall compose is working again?
17:28:07 <dgilmore> its a kernel/dracut issue maybe
17:28:15 <nirik> not that I know of
17:28:15 <dgilmore> no idea what teh probelem is
17:28:19 <dgilmore> the logs have no infor
17:28:25 <nirik> last I looked it was that it timed out.
17:28:39 <dgilmore> last I looked there was a traceback
17:29:00 <dgilmore> but i have only been looking at rawhide
17:29:53 <adamw> okay...well, i guess first we try to get any f25 compose, then we go from there
17:30:23 <adamw> #info the whole Rawhide and F25 compose process has been failing for the last few days, so we have little concrete info here; first we will try to get an F25 compose completed at all, then move on from there
17:30:46 <adamw> #topic (1352680) efibootmgr calls in anaconda crashing since efivar-0.24-1.fc25 landed
17:30:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1352680
17:30:47 <adamw> #info Accepted Blocker, efibootmgr, NEW
17:31:49 <adamw> so pjones did new efivar and efibootmgr builds last friday which do fix this bug, but there were some other issues and packages not rebuilt that still need cleaning up
17:31:58 <adamw> i cleaned up rawhide but left f25 for pjones to do, at least until tomorrow
17:32:09 <adamw> he's around today so i expect he'll be tidying things up and submitting an update
17:34:39 <adamw> #info pjones is in the middle of working on this, update should be coming soon
17:35:15 <adamw> #topic (1324623) glibc: split libcrypt into separate package and package libcrypt-nss with NSS-based implementation
17:35:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1324623
17:35:16 <adamw> #info Accepted Blocker, glibc, ASSIGNED
17:35:23 <adamw> so i'm kinda out of the loop on this one...
17:35:32 <adamw> dgilmore / nirik are you guys more closely following it?
17:35:34 <dgilmore> it breaks arm images
17:35:46 <dgilmore> because yum tries to install both packages
17:35:54 <nirik> because we build them with appliance tools...
17:35:55 <dgilmore> and they conflict
17:36:09 <nirik> which uses livecd-tools and thus yum... yeah
17:36:20 <dgilmore> it does not use livecd-tools
17:36:48 <nirik> it has a requires on it?
17:36:52 <dgilmore> livecd-tolols and appliance-tools are seperate
17:37:02 <dgilmore> but they have a shared library they use
17:37:06 <dgilmore> nope
17:37:16 <adamw> so what is the bug waiting on? i saw some discussion of something being referred to fesco
17:37:17 <dgilmore> sorry my network is not great
17:37:21 <nirik> % rpm -q appliance-tools --requires | grep livecd
17:37:21 <nirik> livecd-tools >= 020
17:37:33 <dgilmore> glibc refuse to revert the change
17:37:49 <nirik> so, pbrobinson had some thoughts on the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EO4LOQLSSNL3NYIKDKXDCJNZ5EUSMH7E/
17:37:58 <nirik> but I have no idea how feasable that all is before alpha
17:37:58 <dgilmore> they ran to fesco to somoehow have it forced in
17:38:08 <dgilmore> nirik: its not viable for f25
17:38:20 <dgilmore> its a massive amount of work
17:38:29 <dgilmore> something we plan to work on in f26
17:38:35 <dgilmore> its already on our list for it
17:38:55 * adamw looks up fesco meeting times
17:39:01 <nirik> friday. :)
17:39:07 <dgilmore> friday
17:39:38 <dgilmore> we maybe can work around it by pulling in libcrypt-nss
17:39:41 <nirik> but a 'don't use weak deps' is kind of closing the barn door long after the animals have all wandered off
17:40:08 <adamw> so fesco considered it in the light of 'oh dear what do we do about weak deps' but didn't really get the urgency of figuring out what to do about *this* bug *right now*?
17:40:44 <nirik> right
17:40:46 <adamw> (i'm guessing just from the minutes here)
17:41:31 * dgilmore has not read the minutes yet
17:42:30 <dgilmore> adamw: to me its not really clear how they thought it would all work
17:42:30 <nirik> If we can't move from appliance-tools, then the options left are workaround it somehow, or change glibc.... which they don't want to do
17:43:35 <dgilmore> only wayy to move off of appliance-tools is to get quite a bit of koji work done, as well as some pungi work
17:44:09 <adamw> why exactly does yum/dnf try to pull in both packages?
17:46:15 <nirik> they both provide the same things that glibc needs.
17:46:28 <nirik> libcrypt.so.1 and such
17:46:44 <brunowolff> Can we add something to the kickstart files to exclude one of the packages or possibly exclude it in the repo definition?
17:46:54 <nirik> but there's a recommends: libcrypt-nss
17:47:21 <nirik> so dnf pulls that. yum fails and tries to install both
17:47:33 <adamw> that still seems like bizarre behaviour on yum's part
17:47:40 <adamw> wouldn't it usually just pick one?
17:47:57 <adamw> this isn't the only place we have multiple packages providing the same thing, after all, and i'm sure yum doesn't always choke on it.
17:48:15 <sgallagh> adamw: In yum, "Recommends:" is just short-cutted to be treated as "Requires:"
17:48:23 <sgallagh> So it ends up thinking it Requires: both packages.
17:48:29 <dgilmore> nothe logs provide no detail as to why its trying to get both
17:48:35 <sgallagh> And those two packages conflict
17:48:50 <adamw> sgallagh: unless there's also an explicit Requires: libcrypt somewhere, it could still just be happy with just libcrypt-nss ...
17:49:07 <sgallagh> adamw: Yeah, there's definitely a backtracking bug somewhere
17:49:18 <sgallagh> But it's probably not worth the engineering time to figure it out in yum
17:49:31 <adamw> i dunno, do we have a better option?
17:50:32 <dgilmore> not sure
17:50:39 <dgilmore> I was planning to look at it more this week
17:50:49 <brunowolff> When you define a repo you used to be ableto exclude packages so they couldn't be pulled in. This used to be done to get the correct kernel packages and correct alternatives for some other packages.
17:51:10 <dgilmore> brunowolff: ??
17:52:07 <dgilmore> we lost the ability a long time ago to add excludes on the repo lines
17:52:09 <brunowolff> We used to do that for live images a while back. The repo ks command had an exclude option.
17:52:24 <dgilmore> when we switched everything to being in koji
17:52:29 * kparal needs to go. see you
17:52:49 <brunowolff> Oh, I didn't know it didn't work anymore. I thought we just didn't need it.
17:53:07 <dgilmore> nope, it stopped being an option
17:53:16 <adamw> you know, the error you posted is slightly odd
17:53:24 <adamw> the versions of libcrypt and libcrypt-nss are different
17:53:41 <adamw> it's almost as if libcrypt is being pulled in because it provides a different soname and some other package hasn't been rebuilt
17:53:58 <dgilmore> adamw: possible
17:54:09 * adamw goes looking for an f25 compose log
17:54:19 <dgilmore> but that would be weird as they come from the same rpm
17:54:23 <dgilmore> well srpm
17:54:37 <nirik> https://kojipkgs.fedoraproject.org//work/tasks/6208/15226208/root.log is the one I was looking at.
17:54:40 <dgilmore> minimal is working
17:54:50 <dgilmore> so something in every other image is pulling the extra one in
17:55:24 <adamw> hmm, yeah, https://kojipkgs.fedoraproject.org//work/tasks/9953/15199953/root.log shows the same conflict with equal versions
17:56:23 <dgilmore> adamw: it needs more investigation
17:57:03 <adamw> yeah...
17:57:08 <adamw> i guess we don't need to do it live
17:57:41 <adamw> #info we are still investigating this and deciding on the best fix. there are open questions about yum's behaviour and what dependency is triggering this. various folks are looking into it
17:57:54 <adamw> #topic (1353054) FreeIPA server deployment fails due to pki-core dangling symlinks (one from non-installed 'scannotation' package, one formerly in resteasy-jaxrs-api but now lost)
17:57:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1353054
17:57:54 <adamw> #info Accepted Blocker, pki-core, ON_QA
17:59:10 <adamw> this one is fixed, and we can push it stable now, so nothing much to say
17:59:18 <adamw> #info this is fixed and fix has been tested by adamw, will be pushed stable soon
17:59:21 <adamw> #topic Open floor
17:59:33 <adamw> that's all we had on the lists - any other f25-related topics for discussion, or missed bugs?
18:00:14 <coremodule> Nothing here!
18:00:27 * cmurf has nothing
18:00:45 <dgilmore> nada
18:01:11 * adamw sets fuse
18:01:31 * jkurik has nothing
18:01:56 <adamw> alrighty, thanks for coming, folks
18:02:07 <adamw> #endmeeting