16:01:09 <adamw> #startmeeting F29-blocker-review
16:01:09 <zodbot> Meeting started Mon Jul 16 16:01:09 2018 UTC.
16:01:09 <zodbot> This meeting is logged and archived in a public location.
16:01:09 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:09 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:09 <adamw> #meetingname F29-blocker-review
16:01:09 <adamw> #topic Roll Call
16:01:09 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:15 * pwhalen is here
16:01:17 <adamw> morning folks, who's around for blocker review fun?
16:01:35 <bcotton> .hello2
16:01:36 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:01:56 <lruzicka> .hello2
16:01:57 <frantisekz> .hello2
16:01:57 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:02:01 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:02 <lbrabec> .hello2
16:02:04 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com>
16:02:07 <sgallagh> .hello2
16:02:08 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:05:03 <adamw> yay, funtimes
16:05:05 <adamw> thanks for coming, folks
16:05:14 <adamw> #chair sgallagh lruzicka
16:05:14 <zodbot> Current chairs: adamw lruzicka sgallagh
16:05:19 * kparal is here
16:05:22 <adamw> impending boilerplate alert!
16:05:23 <adamw> #topic Introduction
16:05:23 <adamw> Why are we here?
16:05:23 <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:23 <adamw> #info We'll be following the process outlined at:
16:05:26 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:26 <adamw> #info The bugs up for review today are available at:
16:05:28 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:30 <adamw> #info The criteria for release blocking bugs can be found at:
16:05:32 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:05:34 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:05:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:09:53 <adamw> sigh, sorry folks, i'm jumping around a bit here
16:09:54 <adamw> here we go
16:10:02 <adamw> #info 5 Proposed Blockers
16:10:02 <adamw> #info 4 Accepted Blockers
16:10:05 <adamw> #info 1 Accepted Freeze Exceptions
16:10:08 <adamw> (is what we have for Beta)
16:10:24 <adamw> does anyone want to secretarialize? our regular secretary, coremodule, is away today
16:10:29 <adamw> (he sent apologies)
16:11:35 <kparal> lruzicka: have you secretarialized yet? (I don't remember). want to try?
16:11:51 <kparal> if not, I'll do it
16:12:32 <lruzicka> kparal: I havent. What shall I do?
16:12:41 <kparal> lruzicka: I'll teach you on the fly
16:12:57 <lruzicka> kparal: Ok, lets do it
16:13:16 * pwhalen pays attention to the lesson
16:13:53 <adamw> woohoo
16:13:59 <adamw> #info lruzicka will secretarialize
16:14:00 <kparal> ah, I started giving instructions privately :)
16:14:11 <adamw> OK, so let's go with the proposed blockers
16:14:11 <adamw> #topic (1582524) dnf doesn't follow default profile for an enabled non-default stream
16:14:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1582524
16:14:12 <adamw> #info Proposed Blocker, dnf, NEW
16:14:15 <kparal> pwhalen: the SOP is here, in any case: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Secretary_Duty
16:14:37 <adamw> once upon a time sgallagh asked us to 'defer' this one, but i figure it's been long enough we should look at it
16:14:42 <adamw> sgallagh: do you know what's going on with this one
16:14:44 <adamw> ?
16:15:03 <sgallagh> Sorry, let me refresh my memory
16:15:08 <sgallagh> (just coming off vacation...)
16:15:54 <pwhalen> kparal, thanks!
16:16:22 <sgallagh> adamw: I haven't had a chance to dive any deeper than my initial report.
16:16:55 <adamw> ok, though karel seems to have followed up on your initial concern
16:16:56 <sgallagh> Though I think Merlin found a similar issue recently, so it may be a confirmation
16:17:07 <adamw> so should we vote on this now, or leave it with you to investigate a bit more first?
16:17:28 <sgallagh> I'm ok with assuming the initial report is true and calling it a blocker
16:17:40 <sgallagh> If I learn it's not, I will re-propose it
16:18:16 <adamw> ok
16:18:22 <sgallagh> But other information I got this morning suggests that the DNF code for handling profile defaults is broken in a few key ways, so likely this will get fixed alongside it
16:19:13 <adamw> so if we're voting on it, per the description, i'd be +1 as a violation of 'appropriate' in our existing criterion "The installed system must be able to download and install appropriate updates with the default console tool for the relevant update type (e.g. default console package manager)."
16:19:37 <adamw> #c1 makes it clear that dnf would not install 'appropriate' updates under the circumstances of this bug...
16:19:57 <adamw> ok, it's not just an 'out of the box' scenario, but it's pretty basic.
16:20:52 * sgallagh nods
16:21:16 <adamw> other votes?
16:22:11 <pwhalen> +1
16:22:17 <lruzicka> +1
16:22:34 <kparal> +1
16:22:47 <sgallagh> +1
16:23:02 <frantisekz> +1
16:23:03 <lbrabec> +1
16:23:56 <adamw> proposed #agreed 1582524 - AcceptedBlocker (Beta) - accepted as a violation of Basic criterion "The installed system must be able to download and install appropriate updates with the default console tool for the relevant update type (e.g. default console package manager)", in a fairly simple module stream configuration
16:24:09 <pwhalen> ack
16:24:16 <kparal> ack
16:24:18 <lruzicka> ack
16:24:27 <sgallagh> ack
16:24:43 <frantisekz> ack
16:25:22 <lbrabec> ack
16:26:16 <adamw> #agreed 1582524 - AcceptedBlocker (Beta) - accepted as a violation of Basic criterion "The installed system must be able to download and install appropriate updates with the default console tool for the relevant update type (e.g. default console package manager)", in a fairly simple module stream configuration
16:26:29 <adamw> #topic (1600823) NetworkManager sometimes fails to start due to 'ordering cycle' problem
16:26:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1600823
16:26:29 <adamw> #info Proposed Blocker, dnf, POST
16:27:02 <adamw> summary of this one: on just about any Fedora install with DNF 3+, one service that should get started on boot, will not. *which one it is* seems to be quasi-random, but there will always be one.
16:27:22 <sgallagh> Seems like a pretty obvious blocker. +1
16:27:40 <pwhalen> +1
16:27:43 <lruzicka> +1
16:28:30 <frantisekz> +1
16:28:31 <lbrabec> +1
16:28:33 <kparal> +1
16:31:03 <adamw> proposed #agreed 1600823 - AcceptedBlocker (Beta) - accepted as a violation of all network-dependent criteria (e.g. updates, browser...) in the case where this prevents NetworkManager from starting
16:31:38 <frantisekz> ack
16:31:39 <lbrabec> ack
16:31:39 <pwhalen> ack
16:31:49 <lruzicka> ack
16:31:51 <kparal> ack
16:33:37 <adamw> #agreed 1600823 - AcceptedBlocker (Beta) - accepted as a violation of all network-dependent criteria (e.g. updates, browser...) in the case where this prevents NetworkManager from starting
16:33:42 <adamw> #topic (1601479) gdbm-libs 1.16 fails to install on Rawhide/F29
16:33:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1601479
16:33:42 <adamw> #info Proposed Blocker, gdbm, NEW
16:34:26 <sgallagh> I proposed this one mostly because it's very likely to be installed on a large subset of systems.
16:34:52 <sgallagh> But upgrades are broken because of an incorrect packaging split.
16:35:13 <sgallagh> (It's also breaking the CI for a bunch of my projects, which is annoying)
16:35:45 <kparal> it's in a default package set?
16:35:51 <kparal> of server?
16:36:46 <sgallagh> I'm not certain, but it's a dependency of a goodly chunk of the distro
16:37:20 <sgallagh> kparal: It's a dep of python3-libs
16:37:28 <sgallagh> So yeah, it's in a default package set or two :)
16:38:07 <adamw> ah, so probably...all the package sets?
16:38:09 <adamw> then +1 i guess
16:38:22 <sgallagh> adamw: Likely everything but the minimal container image
16:38:28 <kparal> +1
16:38:29 <adamw> when did this break?
16:38:41 <sgallagh> adamw: Must have been in the last seven days
16:38:53 <adamw> well what i'm wondering is
16:38:58 <adamw> if it's that bad, how did *any* new installs work with it
16:39:01 <sgallagh> My CI runs on any commit or every Monday.
16:39:01 <kparal> I'm surprised composes work
16:39:10 <sgallagh> adamw: NEW installs are fine
16:39:11 <adamw> quite a lot of openqa tests on 20180713 passed
16:39:12 <sgallagh> Upgrades are broken
16:39:16 <adamw> oh, it's not needed by python3-libs any *more*?
16:39:20 <adamw> but it was in the past?
16:39:56 <sgallagh> I think python3-libs in F29 now requires *compat*-gdbm-libs
16:40:01 <sgallagh> Which is part of the problem, maybe?
16:40:35 <adamw> why is it trying to use the f28 gdbm package in your example at all?
16:41:09 <adamw> i mean, https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180714.n.0/compose/Everything/x86_64/os/Packages/g/gdbm-1.16-1.fc29.x86_64.rpm is right there
16:41:10 <sgallagh> adamw: Possibly the fedora/rawhide docker image is a little outdated?
16:41:13 <adamw> it smells like there's more to this somehow
16:41:53 <adamw> did you actually test that an upgrade doesn't work because of this?
16:42:21 <sgallagh> No, I did not do a full upgrade test.
16:42:53 <sgallagh> The package update fails, so I took that to the logical conclusion that upgrades would also fail
16:43:43 <adamw> lots of upgrade tests passed on the 20180714.n.0 compose
16:43:49 <sgallagh> hmm
16:43:50 <adamw> look down the bottom of https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=Rawhide&build=Fedora-Rawhide-20180714.n.0&groupid=1
16:44:00 <adamw> all upgrade tests passed except  upgrade_desktop_32bit
16:44:10 <adamw> (which looks like it just hit some blip)
16:44:33 <sgallagh> Hmm, that might mean that it works as long as some larger set of things are in the transaction, I suppose
16:45:00 <adamw> yeah
16:45:27 <adamw> can we ask you to poke into this a bit further? it doesn't seem like it's fully understood atm.
16:45:33 <sgallagh> Sure, will do
16:46:04 <kparal> lruzicka has debugged a similar issue (with a different package) that only has issues in the live session (when dbus is running), but not during offline updates/upgrades
16:46:26 <kparal> so, might be another thing to look at
16:46:35 <lruzicka> kparal: That was for F27 though
16:46:47 <kparal> right
16:47:02 <kparal> just pointing out that live/offline transaction can be different
16:47:24 <lruzicka> It was this one: https://bugzilla.redhat.com/show_bug.cgi?id=1599332
16:47:42 <adamw> proposed #agreed 1601479 - punt (delay decision) - from some preliminary investigation during the meeting this one doesn't seem clear cut and it does not actually seem to be breaking upgrade tests, so sgallagh will look into it further before we make any decision
16:48:02 <pwhalen> ack
16:48:11 <lruzicka> ack
16:48:28 <sgallagh> ack
16:48:51 <kparal> ack
16:50:37 <adamw> #agreed 1601479 - punt (delay decision) - from some preliminary investigation during the meeting this one doesn't seem clear cut and it does not actually seem to be breaking upgrade tests, so sgallagh will look into it further before we make any decision
16:50:46 <adamw> #topic (1600848) Build a new release with modularity support
16:50:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1600848
16:50:46 <adamw> #info Proposed Blocker, PackageKit, NEW
16:50:49 <adamw> brb, call of nature
16:51:30 <kparal> what do server criteria say regarding packagekit?
16:51:38 <kparal> and modularity?
16:51:57 * kparal should probably be able to find that out, shouldn't he
16:52:15 <kparal> (but it's easier to ask sgallagh)
16:52:56 <kparal> it seems that the solution they're trying to achieve is for packagekit to ignore anything modular
16:53:09 <sgallagh> This would be the "default gui package tool"
16:53:14 <sgallagh> Not to ignore it
16:53:21 <sgallagh> To honor whatever state was set by DNF
16:53:30 <kparal> are you saying PK must work with modules?
16:53:44 <sgallagh> We don't require that they be able to modify that state (enable/disable modules, etc.)
16:54:02 <sgallagh> Only that if modules were enabled/disabled/default, it must update them just as DNF would
16:54:27 <kparal> do you know what happens if the latest PK is not released in time? what does it do at the moment?
16:54:46 <sgallagh> It will pick whatever the highest NVR is from any stream and attempt to install that.
16:54:57 <kparal> overriding modules possibly
16:55:00 <kparal> with an rpm
16:55:06 <sgallagh> Almost certainly
16:55:24 <kparal> ok. that seems like a blocker then, right? do you have a criterion at hand?
16:56:32 <adamw> sure, we have a graphical update criterion at beta
16:56:50 <adamw> "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops (e.g. default graphical package manager)."
16:56:53 <adamw> note again 'appropriate'
16:56:55 <sgallagh> The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops (e.g. default graphical package manager).
16:57:03 <sgallagh> too slow
16:57:23 <adamw> though...i think we said this was ok for f28, right, so long as modules weren't enabled by default?
16:57:27 <adamw> so why is it not ok for f29
16:57:39 <sgallagh> adamw: Because modules will be enabled by default in F29
16:57:45 <adamw> that's a good reason!
16:57:47 <adamw> for Workstation?
16:57:52 <sgallagh> All of Fedora
16:57:56 <adamw> then okay. +1
16:58:13 <sgallagh> I haven't flipped the switch on that yet because this isn't working
16:58:15 <sgallagh> But it's coming
16:59:37 <adamw> is it an official Change or anything?
16:59:38 <sgallagh> +1, FTR
16:59:40 <sgallagh> Yes
16:59:47 <sgallagh> https://fedoraproject.org/wiki/Changes/ModulesForEveryone
16:59:59 <kparal> adamw: re "appropriate" - I bow to your foreseeing wisdom
17:01:21 <adamw> hah, i wish i could claim credit
17:01:30 <adamw> but in fact we added it in after we first ran into modularity issues
17:02:03 <adamw> ok, so i'm +1 with i guess the note that delaying the change to f30 would in theory also 'resolve' this
17:02:14 <adamw> any other votes?
17:02:42 <kparal> +1 atm. if the change gets canceled, we'll adjust
17:03:05 <lruzicka> +1, however I am a bit afraid
17:03:22 <pwhalen> +1
17:03:33 <sgallagh> FWIW, we expect this to be fixed this week.
17:03:34 <kparal> lruzicka: that's your age talking. I heard it only gets worse, though.
17:03:55 <lruzicka> kparal: Seems you are right. :)
17:04:26 <kparal> look at frantisekz. not afraid to ack anything
17:04:33 <kparal> go youth go :)
17:05:14 <lruzicka> kparal: I am not afraid to ack this, I am afraid that it will make PackageKit even more fragile.
17:05:22 <adamw> proposed #agreed 1600848 - AcceptedBlocker (Beta) - as https://fedoraproject.org/wiki/Changes/ModulesForEveryone is an accepted Change for F29 and requires enabling modules for all Fedora installs, this is accepted as a Beta blocker as a violation of Beta criterion "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops (e.g. default
17:05:22 <adamw> graphical package manager)"
17:05:37 <adamw> proposed #agreed 1600848 - AcceptedBlocker (Beta) - as https://fedoraproject.org/wiki/Changes/ModulesForEveryone is accepted for F29 and requires enabling modules for all Fedora installs, this is accepted as a Beta blocker as a violation of Beta criterion "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops (e.g. default graphical
17:05:38 <adamw> package manager)"
17:05:40 <adamw> grr
17:06:01 <adamw> proposed #agreed 1600848 - AcceptedBlocker (Beta) - as https://fedoraproject.org/wiki/Changes/ModulesForEveryone is accepted for F29 and means modules will be enabled for all installs, this is accepted as a Beta blocker as a violation of Beta criterion "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops (e.g. default graphical package
17:06:01 <adamw> manager)"
17:06:03 <kparal> I heard matrix network is the new hotness
17:06:05 <adamw> i hate life.
17:06:10 <adamw> .fire IRC
17:06:10 <zodbot> adamw fires IRC
17:06:13 <lruzicka> :)
17:06:17 <adamw> proposed #agreed 1600848 - AcceptedBlocker (Beta) - as https://fedoraproject.org/wiki/Changes/ModulesForEveryone is accepted for F29 and means modules will be enabled for all installs, this is accepted as a Beta blocker as a violation of Beta criterion "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops"
17:06:19 <sgallagh> life--
17:06:30 <lruzicka> ack
17:06:32 <adamw> i pity da fool- wait, maybe not.
17:06:37 <kparal> ack
17:06:40 <pwhalen> ack
17:06:48 <kparal> adamw++ for this reference
17:06:53 <sgallagh> ack
17:06:59 <lruzicka> adamw: heh, I have seen that already :)
17:07:17 <adamw> #agreed 1600848 - AcceptedBlocker (Beta) - as https://fedoraproject.org/wiki/Changes/ModulesForEveryone is accepted for F29 and means modules will be enabled for all installs, this is accepted as a Beta blocker as a violation of Beta criterion "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops"
17:07:30 <adamw> #topic (1600690) selinux-policy denies all(?) iptables operations with iptables 1.8.0 (breaks firewalld)
17:07:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1600690
17:07:31 <adamw> #info Proposed Blocker, selinux-policy-targeted, POST
17:08:26 <kparal> +1 per all services must work criterion
17:08:34 <sgallagh> So, *technically* this probably doesn’t violate the criteria, since it only applies to default config, yes?
17:08:49 <sgallagh> But realistically, that has to be an oversight.
17:08:53 <pwhalen> +1
17:09:05 <adamw> sgallagh: sorry, i don't get it?
17:09:33 <sgallagh> adamw: our criteria only specifies post install state, not ongoing changes for firewall I thought
17:10:00 <adamw> you don't get any firewall
17:10:13 <adamw> the criterion says the default firewall config must be in place after install
17:10:18 <adamw> if firewalld doesn't start up it clearly isn't
17:10:28 <sgallagh> adamw: oh, I misunderstood that part.
17:10:29 <adamw> either there's no firewall or everything is blocked, i haven't checked which is the state yet, but neither is correct
17:10:37 <sgallagh> Clear +1, then
17:11:07 <lruzicka> +1
17:11:23 <sgallagh> (I thought the bug meant that subsequent changes failed, not that firewalld didn’t even apply the default config)
17:12:30 <adamw> oh, k. no, it says "This prevents the firewalld service from starting correctly."
17:14:34 <adamw> proposed #agreed 1600690 - AcceptedBlocker (Beta) - this is accepted as a violation of the Basic criterion "After system installation without explicit firewall configuration, the system firewall must be active on all non-loopback interfaces"
17:14:49 <pwhalen> ack
17:14:53 <lruzicka> ack
17:15:48 <kparal> ack
17:16:33 <frantisekz> ack
17:17:13 <adamw> #agreed 1600690 - AcceptedBlocker (Beta) - this is accepted as a violation of the Basic criterion "After system installation without explicit firewall configuration, the system firewall must be active on all non-loopback interfaces"
17:17:27 <adamw> and that's all the proposed blockers and FEs we have
17:18:05 <adamw> i don't see anything we really need to dig into in the accepted blockers, i think they're all pretty much known/understood and being worked on
17:18:22 <adamw> #info no other proposed blockers or FEs and no accepted Beta blockers really need review
17:18:25 <adamw> #topic Open floo
17:18:26 <sgallagh> FTR, I think the one I’m investigating may be unique to the docker image.
17:18:26 <adamw> #topic Open floor
17:18:40 <adamw> great, that got in under the misnamed topic :P
17:18:42 <sgallagh> I’ll update the ticket in a bit
17:18:46 <kparal> nothing here
17:18:46 <adamw> thanks
17:18:51 <adamw> any other business related to f29 releaseiness?
17:19:04 <lruzicka> not yet
17:19:42 <kparal> lruzicka is now a secretary master
17:19:48 <kparal> lruzicka++
17:20:01 <lruzicka> I am trying to do my best :)
17:20:05 <kparal> where's the bot when you need it
17:21:51 <adamw> woohoo
17:21:57 <adamw> don't think the bot's ever been in here
17:22:03 <adamw> the karma bot anyway
17:22:11 <adamw> or wait is zodbot the one that does karma? i'm so confused
17:23:06 * kparal shrugs
17:23:12 <kparal> I thought it was zodbot
17:25:09 <pwhalen> me too
17:25:37 <lruzicka> Maybe, the bot is busy recording something else :D
17:29:05 <kparal> adamw: close?
17:35:14 <kparal> lruzicka: type #endmeeting
17:35:28 <lruzicka> #endmeeting