16:01:12 <adamw> #startmeeting F29-blocker-review
16:01:12 <zodbot> Meeting started Tue Sep  4 16:01:12 2018 UTC.
16:01:12 <zodbot> This meeting is logged and archived in a public location.
16:01:12 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:12 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:12 <adamw> #meetingname F29-blocker-review
16:01:12 <adamw> #topic Roll Call
16:01:12 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:57 * pwhalen is here
16:02:07 <adamw> who else is around, folks?
16:02:14 <adamw> if you hello'ed before i started the meeting, go ahead and hello again
16:02:25 * coremodule is here, ready to secretarialize!!
16:02:31 <coremodule> .hello2
16:02:32 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:02:35 <bcotton> .hello2
16:02:38 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:39 <lruzicka> .hello2
16:02:40 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:03:26 <sgallagh> I'm more or less here
16:03:35 <sgallagh> Juggling a few other things at the same time
16:03:50 <Southern_Gentlem> .hello
16:03:50 <zodbot> Southern_Gentlem: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:03:58 <Southern_Gentlem> .hello jbwillia
16:03:59 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:04:03 <mattdm> .hello2
16:04:04 <zodbot> mattdm: mattdm 'Matthew Miller' <mattdm@mattdm.org>
16:04:05 * lbrabec is here
16:04:10 <mattdm> (half attention)
16:04:19 * adamw does some complex math
16:04:33 <adamw> through the wonders of compounding, it appears that we have 2.798 Matt Gallaghers
16:05:04 * sgallagh absconds with one
16:05:09 <adamw> (but sadly, only 0.37 Stephen Millers)
16:05:12 <sgallagh> (Now I can sleep!)
16:05:33 <sgallagh> adamw: The world could use fewer Stephen Millers...
16:05:35 <adamw> alrighty, thanks for coming out, folks
16:05:37 <adamw> haha
16:05:47 <adamw> i did not even notice that
16:06:12 <adamw> #chair coremodule bcotton
16:06:12 <zodbot> Current chairs: adamw bcotton coremodule
16:06:22 <adamw> #topic Introduction
16:06:22 <adamw> Why are we here?
16:06:22 <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:06:22 <adamw> #info We'll be following the process outlined at:
16:06:22 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:24 <adamw> #info The bugs up for review today are available at:
16:06:26 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:28 <adamw> #info The criteria for release blocking bugs can be found at:
16:06:30 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:06:32 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:06:34 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:06:39 <adamw> we have:
16:06:41 <adamw> #info 9 Proposed Blockers
16:06:42 <adamw> #info 6 Accepted Blockers
16:06:46 <adamw> #info 24 Proposed Freeze Exceptions
16:06:48 <adamw> #info 3 Accepted Freeze Exceptions
16:06:50 <adamw> (all for Beta)
16:06:56 <adamw> given the numbers, let's focus on Beta this week, that's more than enough bugs to deal with
16:07:07 <adamw> sorry we missed the meeting last week, the numbers have kinda exploded since then
16:07:14 <adamw> #info coremodule will secretarialize
16:07:18 <adamw> so, let's get into it!
16:07:26 <adamw> #info starting with the proposed blockers
16:07:33 <adamw> #topic (1596540) RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline
16:07:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1596540
16:07:33 <adamw> #info Proposed Blocker, dnf, ASSIGNED
16:09:39 <adamw> so last time we talked about this, we concluded:
16:09:50 <adamw> "we are worried about this and similar bugs that seem to affect some but not other users on upgrade to DNF 3, but do not have sufficient information yet to make a good decision on whether they should be blockers. We will directly request evaluation of this by the dnf team and discuss it again after that."
16:10:14 <adamw> since then...dmach has provided a clean reproducer that still involves ansible
16:10:27 <adamw> we've established that wiping history helps
16:11:19 <adamw> has anyone got more on this? at least in the bug, dmach didn't provide an opinion on whether this should be a blocker, or any info on links to *other* reported dnf bugs that seem to involve the history db
16:12:28 <Southern_Gentlem> reading thought the bugzilla it appears to be a bug, others are seeing the samething without ansible
16:12:46 <Southern_Gentlem> through
16:12:53 <Southern_Gentlem> +1 blocker
16:14:18 <cmurf> dnf specific, it's not affecting PackageKit?
16:15:37 <cmurf> anyway, I'm +1 blocker since there is a reproducer
16:16:09 <adamw> given that it involves the dnf history database i'm not 100% surprised it doesn't affect PK
16:16:14 <adamw> I can go with +1 blocker
16:16:16 <adamw> other votes?
16:16:21 <lruzicka> yeah, it seems like it can break things, so +1 blocker
16:16:25 <frantisekz> +1
16:16:31 <pwhalen> +1 blocker
16:16:36 <lbrabec> +1 blocker
16:16:45 <sgallagh> Yeah, I suppose +1 blocker
16:16:58 <sgallagh> Mostly because it seems like it's non-trivial to get back to a working state once this happens
16:18:22 <lruzicka> true
16:20:25 <adamw> proposed #agreed 1596540 - AcceptedBlocker (Beta) - accepted as a blocker as a violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated."
16:20:58 <lruzicka> ack
16:21:37 <Southern_Gentlem> ack
16:22:05 <lbrabec> ack
16:22:10 <adamw> #agreed 1596540 - AcceptedBlocker (Beta) - accepted as a blocker as a violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated."
16:22:16 <adamw> #topic (1625259) RuntimeError: TransactionItem not found for key
16:22:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625259
16:22:16 <adamw> #info Proposed Blocker, dnf, NEW
16:23:30 <adamw> so, another DNF thing, looks like one kparal only just found
16:23:44 <Southern_Gentlem> +1
16:24:18 <adamw> i...feel like someone was telling me about a bug a lot like this, just the other day...
16:25:03 <adamw> oh, it was puiterwijk, but it was a bit different
16:25:09 <adamw> still involved TransactionItems
16:25:40 <adamw> kparal: so this doesn't happen if the package is from stable?
16:26:24 <puiterwijk> What did I do now?
16:26:44 <puiterwijk> Ah, yeah. DNF reinstalling was broken, I've heard. But not tested it myself yet
16:27:13 <puiterwijk> (for groups and modules)
16:27:16 <adamw> puiterwijk: yours was the install/uninstall/reinstall a package group one
16:27:20 <puiterwijk> Yeah
16:27:23 <puiterwijk> adamw: groups and module
16:27:33 <adamw> we need to get that one filed too...
16:27:47 <puiterwijk> First I should see if I can reproduce it. I just got that report from someone else
16:27:51 <adamw> ah k
16:28:10 <Southern_Gentlem> +1 blocker
16:28:26 <adamw> can anyone cite a criterion for this?
16:28:33 <adamw> i don't really see a +1 for this at least yet
16:28:44 * pwhalen was also wondering that
16:28:50 <pwhalen> about criteria
16:28:55 <adamw> it's a failed operation, okay, it doesn't look like it corrupted or permanently broke anything, and 'history undo' is not really in the criteria
16:29:53 <lruzicka> maybe we could FreezeException this?
16:30:20 <lruzicka> if they would have the change to correct such behaviour, the better
16:31:26 <Southern_Gentlem> my +1 was because we already have a blocker for dnf  so might as fix both
16:32:43 <lruzicka> Dan told me last week, that they were going to release a new version of DNF soon, anyway. So that will perhaps solve all of them.
16:32:54 <frantisekz> if we don't agree on beta blocker, i'd like to see it as final blocker/beta FE at least
16:32:54 * lruzicka tries to see the glass half full.
16:33:03 <adamw> Southern_Gentlem: that's not a reason for something to be a blocker
16:33:17 <cmurf> if the bug does not affect stable packages, but does affect updates or updates-testing, the criterion is that the bug unacceptably limits the scope of testing
16:33:39 <cmurf> the catch all one that you (sometimes) hate :P
16:33:46 <adamw> i don't see how this significantly limits the scope of testing.
16:34:11 <cmurf> ok so it doesn't hit every package in updates or u-t?
16:34:21 <adamw> even if it did, it's not about installing the package.
16:34:27 <adamw> it's about doing 'dnf history undo' after installing the package.
16:34:34 <adamw> that's not something we really need to be able to do in order to test anything else.
16:34:46 <cmurf> i agree with that
16:35:11 <cmurf> it just simply fails, and doesn't put you in a worse position that you can't back out of like the previous dnf bug
16:35:21 <cmurf> so yeah, freeze exception is reasonable
16:35:21 <adamw> on current info i'm -1 blocker, i would not want to vote on FE without more info on the bug/fix
16:35:50 <adamw> frankly, given that DNF 'fixes' often seem to break more than they fix, i am inherently conservative on DNF FEs
16:36:09 <Southern_Gentlem> in that case lets punt
16:36:12 <cmurf> haha yeah that's a good look before leap
16:36:23 <adamw> but those are just my votes :P
16:36:50 <adamw> so...other votes?
16:37:25 <Southern_Gentlem> -1 blocker
16:37:31 <pwhalen> -1 blocker, +1 FE (but ok to punt on that decision)
16:37:31 <lruzicka> Let's punt and see next time, if we get more info, and perhaps let the DNF guys know about this explicitely.
16:38:18 <Southern_Gentlem> +1 punt
16:38:29 <cmurf> i think given so little time before beta gonogo
16:38:33 <cmurf> commit to -1 blocker
16:38:45 <cmurf> and also ask for more info to see if FE is doable without blowing up more stuff
16:39:26 <pwhalen> +1 what cmurf said
16:39:28 <adamw> right, that's basically what i want to know, what's broken, what's the fix
16:39:41 <adamw> note, we can always revote on blocker if this turns out to be worse than it first appeared
16:40:25 <adamw> proposed #agreed 1625259 - RejectedBlocker (Beta) - while DNF tracebacks are always bad, this doesn't seem to cause permanent problems and the functionality that fails is not in the criteria (and not hugely important). we are open to considering FE status once the bug and fix are more clearly understood
16:40:37 <frantisekz> ack
16:40:44 <cmurf> ackbar
16:40:50 <pwhalen> ack
16:40:55 <Southern_Gentlem> ack
16:41:10 <adamw> #agreed 1625259 - RejectedBlocker (Beta) - while DNF tracebacks are always bad, this doesn't seem to cause permanent problems and the functionality that fails is not in the criteria (and not hugely important). we are open to considering FE status once the bug and fix are more clearly understood
16:41:30 <adamw> #topic (1623868) default libvirt/container networking (NAT based AFIACT) broken in F-29
16:41:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1623868
16:41:30 <adamw> #info Proposed Blocker, firewalld, ON_QA
16:41:40 <lbrabec> +1 blocker, but it's already fixed in firewalld-0.6.1-2.fc29
16:41:43 <adamw> i'm +1 on this, to me the virt criterion clearly implies working networking
16:41:52 <lruzicka> +1
16:41:54 <adamw> yes, but we can't push that unless it fixes a blocker or FE bug :)
16:41:54 <frantisekz> +1 blocker
16:41:55 <pwhalen> +1
16:42:11 <cmurf> +1 blocker
16:42:37 <Southern_Gentlem> +1 blocker
16:43:11 <adamw> proposed #agreed 1623868 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release" and its footnote
16:43:20 <lbrabec> ack
16:43:21 <frantisekz> ack
16:43:24 <lruzicka> ack
16:43:24 <Southern_Gentlem> ack
16:43:31 <pwhalen> ack
16:44:52 <adamw> #agreed 1623868 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release" and its footnote
16:45:01 <adamw> #topic (1624534) Transition from g-i-s to desktop fails in current Rawhide and F29
16:45:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624534
16:45:01 <adamw> #info Proposed Blocker, gdm, NEW
16:45:45 <cmurf> well if it fails before user creation...
16:45:51 <adamw> no, it doesn't
16:46:07 <halfline> i fixed that upstream
16:46:12 <adamw> so, for those who don't install Workstation a lot: the way it currently works, you boot the Workstation live and run the installer, there is no option to create a user or set a root password during install, the installed system boots to a wizard (gnome-initial-setup) where you must create a user account (which always has admin privileges)
16:46:35 <adamw> after that happens, next you're *supposed* to see either the login screen, or a logged-in desktop as the user you just created
16:46:36 <Southern_Gentlem> +1 blocker
16:46:40 <lbrabec> i ran into that, no user in wheel, no root, no fun... +1 blocker
16:46:43 <adamw> at present, however, you just get an apparently-broken console
16:47:00 <adamw> lbrabec: currently you do get to create a user, but you don't get to log in as that user, at least not till you reboot
16:47:04 <adamw> at least in my testing
16:47:15 <cmurf> ok but still a blocker
16:47:19 <adamw> it's not actually that terrible practically speaking as you only really need to reboot, but it looks bad, and does violate the criteria
16:47:19 <lruzicka> Agree
16:47:36 <pwhalen> +1 blocker, just hit it
16:47:37 <Southern_Gentlem> adamw, if the moon is right and your finger and toes are in the correct posiiton
16:47:39 <lruzicka> so, not much to talk about then, right? +1 blocker
16:47:58 <adamw> yeah, as the criteria stand it's a fairly clear violation.
16:48:12 <adamw> i mean, i can imagine us getting into criteria judo if this is the last blocker, but...
16:48:26 <Southern_Gentlem> seeing it in f28 as well and i am hoping to push get backported quickly
16:48:37 <adamw> Southern_Gentlem: sorry for all these bugs hitting the respins lately :/
16:48:48 <Southern_Gentlem> such as life
16:48:54 <cmurf> "
16:48:56 <cmurf> oops
16:48:57 <adamw> hey, at least we have automated testing to catch it :P
16:49:16 <cmurf> "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional. "
16:49:19 <Southern_Gentlem> well and respins testing is helping the upstream as well
16:49:20 <cmurf> is that what applies here?
16:49:21 <adamw> proposed #agreed 1624534 - AcceptedBlocker (Beta) - accepted as a violation of "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."
16:49:25 <adamw> cmurf: i went with ^^^
16:49:37 <Southern_Gentlem> ack
16:49:40 <lbrabec> ack
16:49:51 <lruzicka> ack
16:49:51 <adamw> that one could also be argued to apply, for sure
16:50:00 <Southern_Gentlem> gold f28 installs have 1G of updates
16:50:15 <adamw> #agreed 1624534 - AcceptedBlocker (Beta) - accepted as a violation of "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."
16:50:23 <cmurf> huh i can't find that criterion
16:50:29 <adamw> #topic (1625269) The Region and Languages section displays in a very small window and therefore is difficult to use.
16:50:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625269
16:50:29 <adamw> #info Proposed Blocker, gnome-control-center, NEW
16:50:32 <adamw> cmurf: it's in Basic
16:50:49 <adamw> cmurf: https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior
16:51:02 <cmurf> gotit
16:51:45 <cmurf> (it's becoming like "choose your own adventure" with the criteria, :-D )
16:52:07 <adamw> so, the criterion cited in this case is a Final criterion
16:52:13 <adamw> https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria#Default_application_functionality
16:52:37 <adamw> lruzicka: unless you were thinking of a different one?
16:52:39 <cmurf> difficult to use, or not possible to read without a magnifying glass?
16:53:29 <lruzicka> Well, I did not know whether to make it a final blocker or beta freeze exception
16:53:34 <adamw> it can be both
16:53:36 <adamw> they're not exclusive
16:53:42 <adamw> in fact, i'd probably vote +1 for both of those
16:54:07 <lruzicka> yeah, I would say, make it a FE for Beta and blocker for final, if not fixed
16:55:23 <adamw> so, yeah: i vote +1 Final blocker, +1 Beta FE. other votes?
16:55:35 <lruzicka> +1 Final, +1 Beta FE
16:55:54 <Southern_Gentlem> +1FB +1 beta fe
16:55:58 <frantisekz> +1 beta FE, +1 final blocker then :)
16:56:10 <pwhalen> +1 Final, +1 Beta FE
16:58:03 <adamw> proposed #agreed 1625269 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - this is accepted as a Final (not Beta) blocker as a violation of "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." it is also accepted as a Beta FE as an obvious deficiency in GNOME that we
16:58:03 <adamw> would like fixed in the live images
16:58:04 <adamw> grr
16:58:33 <adamw> proposed #agreed 1625269 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - accepted as a Final (not Beta) blocker, violation of "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." it is also accepted as a Beta FE as a significant bug in GNOME that we would like fixed in
16:58:34 <adamw> the live images
16:58:39 <adamw> ....i hate you irc
16:59:03 <adamw> proposed #agreed 1625269 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - accepted as a Final (not Beta) blocker, violation of "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." also accepted as Beta FE as a major bug in GNOME that should be fixed in the live images
16:59:12 * adamw needs to hire an editor
17:00:12 <lruzicka> ack
17:00:15 <pwhalen> ack
17:00:21 <Southern_Gentlem> ack
17:00:35 <adamw> #agreed 1625269 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - accepted as a Final (not Beta) blocker, violation of "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." also accepted as Beta FE as a major bug in GNOME that should be fixed in the live images
17:00:51 <adamw> #topic (1625253) gnome-shell on wayland might crash when moving bookmark in nautilus
17:00:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625253
17:00:51 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:02:16 <lruzicka> +1 blocker, I would say -> basic applications should work
17:02:27 <adamw> that's a final criterion.
17:02:35 <adamw> there really is no basic or beta criterion that covers this, that i can see
17:02:51 <adamw> this is an obvious +1 FE of course
17:02:58 <frantisekz> yep, that's final, but if it takes down whole session... I think we can discuss about being a blocker
17:03:02 <adamw> but we can't really make it a beta blocker without a criteria change, AFAICS.
17:03:02 <Southern_Gentlem> are we sure that is gnome-shell and not wayland
17:03:11 <adamw> Southern_Gentlem: doesn't matter for blocker review purposes, really.
17:03:19 <Southern_Gentlem> ok
17:03:26 <adamw> (it's also a fine distinction, as gnome-shell is the Wayland compositor for GNOME...)
17:03:36 <Southern_Gentlem> +1 Beta FE and +1 final blocker
17:03:45 <lbrabec> then +1 beta fe, +1 final blocker
17:03:54 <adamw> i mean, we can always discuss criteria changes
17:04:08 <adamw> it's true that when the criteria were written, this whole thing (crashes in GNOME Shell take down the entire session) wasn't the case
17:04:14 <cmurf> i thought mutter was the wayland compositer
17:04:17 <adamw> but as written, there's no criterion that makes that a beta blocker
17:04:20 <adamw> cmurf: ...details!
17:04:43 <cmurf> i am like a pinball machine you know
17:06:57 <adamw> lruzicka: frantisekz: so do you think we should change the criteria? or go with it for now?
17:07:34 <frantisekz> id go with it... being too lazy to write some criteria and hoping GNOME guys gonna fix it soon :D
17:07:57 <pwhalen> +1 FE
17:08:10 <adamw> =)
17:08:49 <lruzicka> +1 FE, +1 Final
17:09:09 <adamw> heh, same agreed text as last time, i think
17:09:10 <adamw> proposed #agreed 1625269 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - accepted as a Final (not Beta) blocker, violation of "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." also accepted as Beta FE as a major bug in GNOME that should be fixed in the live images
17:09:19 <lruzicka> ack
17:09:23 <frantisekz> ack
17:09:32 <lbrabec> ack
17:09:32 <pwhalen> ack
17:09:58 <lruzicka> adamw, As far as criteria are concerned, we can change them, but that would take some time to discuss, I believe.
17:10:53 <cmurf> yes and the relevant party needs to buy off on the criterion
17:11:16 <adamw> lruzicka: sure.
17:11:23 <adamw> you all fail
17:11:25 <cmurf> well unless adamw says so benevolent ruler style
17:11:25 <adamw> i didn't change the bug number
17:11:26 <adamw> :P
17:11:45 <cmurf> you're right!
17:11:51 <cmurf> so much for proofreading!
17:11:53 <adamw> cmurf: haha. i'm not the benevolent ruler of anything, srsly. we couldn't reasonably adopt a criterion that relevant devs fundamentally oppose
17:12:09 <adamw> proposed #agreed 1625253 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - accepted as a Final (not Beta) blocker, violation of "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." also accepted as Beta FE as a major bug in GNOME that should be fixed in the live images
17:12:37 * adamw is, however, the malevolent ruler of Adamonia
17:13:05 <cmurf> evil mirror universe?
17:13:06 <adamw> the imaginary country in my head where all developers who release packages with world-breaking bugs are permanently exiled
17:13:11 <adamw> it is a harsh and unforgiving place
17:13:42 <cmurf> oh so lots of muzak, Friends reruns only, and transient unexplained internet outages?
17:14:12 <Southern_Gentlem> ack
17:14:30 <cmurf> ack (yes bug # is changed)
17:14:40 <adamw> cmurf: also everyone is required to own as many IoT gadgets as possible, protected only by a cable company's stock router
17:14:51 <adamw> #agreed 1625253 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - accepted as a Final (not Beta) blocker, violation of "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." also accepted as Beta FE as a major bug in GNOME that should be fixed in the live images
17:15:03 <cmurf> haha, brutal
17:15:37 <lruzicka> ack again
17:15:37 <cmurf> wait until ISPs say "oh you wanna run a VPN? pay more"
17:15:56 <adamw> cmurf: there *is* another TV channel, though. that one plays Two And a Half Men reruns.
17:16:03 <adamw> ...Ashton Kutcher era only.
17:16:11 <cmurf> oh god
17:16:17 <adamw> muahahahahah
17:16:30 <adamw> #topic (1619389) mod_ssl does not work with TLS 1.3-enabled openssl
17:16:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1619389
17:16:30 <adamw> #info Proposed Blocker, httpd, ON_QA
17:17:47 <adamw> so, we're still not clear on exactly when this breaks
17:18:21 <cmurf> that's unfortunate
17:18:27 <adamw> given that freeipa does seem to work on a fresh install
17:18:49 <adamw> (in https://openqa.fedoraproject.org/tests/273817 you can see the FreeIPA web UI working just fine on latest 29 compose)
17:19:04 <adamw> it's already accepted as an FE
17:19:18 <cmurf> freeipa uses gnutls and there's no way it's doing a fallback?
17:19:43 <adamw> this is about openssl, not gnutls
17:19:52 <cmurf> doh
17:19:54 <adamw> it's about the httpd mod_ssl module
17:20:05 <adamw> freeipa is involved as freeipa is a thing we have in the release criteria that involves httpd
17:20:17 <cmurf> right
17:20:57 <adamw> so, i don't see that i can vote on blocker status ATM, we'd need confirmation that there's some criteria-related scenario in which it fails
17:21:14 <adamw> so i'm probably punt on this one
17:21:18 <cmurf> so there's more than one place the TLS 1.3 change is happening?
17:21:51 <adamw> well, yeah, it would be odd for all SSL/TLS libs not to support the new protocol, really.
17:21:55 <adamw> i'm sure NSS is supporting it too.
17:22:23 <cmurf> i only see gnutls listing that change
17:22:35 <cmurf> so if the scope is broader than gnutls
17:22:48 <cmurf> that might explain my confusion
17:24:17 <adamw> yeah, i don't think other libs made it a Change.
17:25:28 <adamw> proposed #agreed 1619389 - punt (delay decision) - it's still not clear if there's a criteria violation here, and it's already accepted as an FE issue. we will try to clarify if there's a criteria violation here in time for next week
17:25:53 <pwhalen> ack
17:25:55 <lruzicka> ack
17:26:06 <Southern_Gentlem> ack
17:26:25 <cmurf> ok i'm seeing openssl dev versions have tls 1.3 enabled by default... not sure if that's what's going on
17:27:29 <adamw> #agreed 1619389 - punt (delay decision) - it's still not clear if there's a criteria violation here, and it's already accepted as an FE issue. we will try to clarify if there's a criteria violation here in time for next week
17:27:35 <adamw> #topic (1616269) [abrt] xorg-x11-server-Xwayland: OsLookupColor(): Display server crashed
17:27:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1616269
17:27:36 <adamw> #info Proposed Blocker, xorg-x11-server, NEW
17:28:00 <cmurf> crash, that's suspicious
17:29:35 <cmurf> ick
17:29:43 <cmurf> if i were hitting that bug I would definitely be annoyed
17:29:54 <cmurf> for sure qualifies as a regression
17:30:19 <cmurf> we don't have a multiple displays criteria though do we?
17:30:30 <cmurf> or even a criterion
17:30:35 <adamw> well, it's not as simple as 'multiple displays'
17:30:46 <adamw> i'm typing this on a system with multiple displays, running F29
17:31:05 <cmurf> sure, on the system it's happening on it doesn't happen on that system unless it has an external display
17:31:18 <adamw> sgallagh does have an apparently-reliable reproducer on his hardware, though, which helps...
17:31:25 <adamw> i guess we should send out that call for testing and see what happens
17:31:34 <cmurf> yeah and dual GPUs
17:31:50 <sgallagh> Yeah, it's trivial for me to reproduce it on Chrome/Chromium
17:32:01 <sgallagh> And it happens about 50/50 when I unplug the external monitor
17:32:40 <cmurf> pretty sure Chrome does some GPU offloading out of the box
17:33:05 <sgallagh> cmurf: Happen to know if there's a setting to disable that?
17:33:12 <sgallagh> It would help to narrow down the cause
17:33:16 <cmurf> right
17:33:32 <cmurf> not off hand i'd have to google it
17:34:02 <cmurf> "use hardware acceleration" in settings
17:34:05 <cmurf> uncheck
17:34:55 <sgallagh> OK, definitely GPU-related
17:35:03 <sgallagh> I just reproduced it with glxgears
17:35:11 <cmurf> i was gonna suggest that next
17:35:21 <adamw> what's the GPU on that machine?
17:35:32 <sgallagh> nVidia Quadro M1000M
17:35:49 <sgallagh> aka GM107GLM
17:35:52 <cmurf> and i915
17:36:00 <cmurf> so the thing is though, which is actually being used for this
17:36:11 <sgallagh> Right, also Intel Corporation HD Graphics 530
17:36:42 <cmurf> one of the f27 or f28 changes was to always use integrated GPU if available and not the discrete GPU
17:36:54 <cmurf> keeps things cooler and better battery life
17:37:12 <cmurf> but i'm not sure if it's possible for something to ask for the discrete gpu and the bug might be in switching GPUs
17:37:28 <sgallagh> cmurf: Prtetty certain it's the nVidia that's the culprit
17:37:47 <sgallagh> The external monitor is only physically connected to the nVidia card in the Lenovo P50
17:37:51 <cmurf> can't tell from the backtrace i'm looking at
17:37:59 <cmurf> ahhh
17:38:11 <cmurf> so in the case of external, some hardware forces only discrete GPU usage
17:38:34 <sgallagh> Ah, and you're thinking that the software may be choking on that forced behavior?
17:38:46 <cmurf> dunno
17:38:58 <sgallagh> OK, well we don't have to solve the problem here.
17:39:06 <sgallagh> Just decide if it's blocker-worthy
17:39:08 <adamw> right.
17:39:12 <cmurf> it could just be a nouveau multiple displays bug interacting with mutter
17:39:16 <adamw> i'd say punt for the 'request for testing'
17:39:21 <cmurf> does t his happen if you login with X instead of wayland session?
17:39:24 <sgallagh> Obviously, this is really painful for me
17:39:32 <sgallagh> But I don't know how widespread it is
17:39:38 <cmurf> oh yeah it would make me crazy, i depend on dual displays
17:39:54 <cmurf> and data loss on top of it
17:40:00 <sgallagh> If it's basically "machines with stupid P50-like design"...
17:40:52 <sgallagh> cmurf: I haven't tried using X in a while. At least last month I couldn't log in under X at all for some reason
17:41:00 * sgallagh gives it a go
17:41:08 <adamw> i think i'd be willing to vote +1 FE already, if it's this bad for one trusted tester
17:41:16 <adamw> so, my vote is punt on blocker, +1 Fe
17:41:18 <adamw> other votes?
17:41:26 <cmurf> +1 beta FE
17:41:33 <cmurf> and on the fence for +1 final blocker
17:41:37 <sgallagh> +1 FE
17:41:39 <cmurf> we'll need more victims
17:41:42 <lruzicka> +1 FE, I cannot reproduce it, as I am not an nvidia owner.
17:43:06 <adamw> proposed #agreed 1616269 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - we're still worried about this bug, but still don't know how widespread the impact may be. We accept it as a Beta FE issue, and will send out a call for testing before voting on blocker status
17:43:52 <lruzicka> ack
17:44:03 <sgallagh> cmurf: Logging in on X doesn’t display anything on the external monitor
17:44:15 <cmurf> sad
17:44:46 <cmurf> off hand I'd say that's a bug too
17:44:53 <sgallagh> But the bug does not seem to happen there
17:46:00 * sgallagh loves repeatedly crashing his main system during blocker bug meetings...
17:46:26 <cmurf> maybe ping ajax or hans and see if they have any ideas at least how to gather more information
17:46:29 <cmurf> clearly it's a regression
17:46:44 <cmurf> what happens if you install an f28 kernel?
17:47:23 <sgallagh> cmurf: Let's take this to #fedora-qa
17:47:26 <cmurf> ok
17:47:29 <adamw> any other acks/nacks/patches?
17:47:59 <cmurf> nope
17:48:02 <sgallagh> ack
17:48:10 <cmurf> oh wait ack
17:48:54 <adamw> #agreed 1616269 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - we're still worried about this bug, but still don't know how widespread the impact may be. We accept it as a Beta FE issue, and will send out a call for testing before voting on blocker status
17:48:56 <lruzicka> ack
17:49:01 <frantisekz> ack
17:49:02 <adamw> #topic (1620584) XWayland crashes on start up and causes the terminal to be unresponsive.
17:49:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1620584
17:49:02 <adamw> #info Proposed Blocker, xorg-x11-server, NEW
17:49:48 <adamw> is this still happening, lruzicka? seen it on any other systems?
17:51:50 <lruzicka> adamw, well, I have not, because I have switched my pc to lightdm
17:51:56 <adamw> heh
17:52:06 <lruzicka> but I did not see it today when installing in virtual machine
17:52:48 <adamw> well, yeah, we'd likely have more reports if it wasn't hardware specific in some way
17:52:54 <adamw> can you at least add info on the hardware in the affected system?
17:53:36 <lruzicka> yes, I can, it was on my Lenovo T460s
17:54:00 <lruzicka> I can try it now.
17:54:56 <lruzicka> I have now rebooted, will see in no time
17:55:23 <adamw> OK, thanks.
17:55:56 <lruzicka> no problems this time, I have updated since then, so maybe the flaw has silently gone
17:56:25 <adamw> ok. well, one test is probably not enough for conclusions, but keep trying it and see...
17:56:41 <adamw> i think for now i'd be -1 blocker on the basis that we don't have a clear reproducer and no indication it's affecting anyone else, yet
17:56:44 <adamw> we can always revote later
17:56:54 <adamw> (if we get competing info)
17:56:56 <lruzicka> I agree. -1 blocker
17:57:24 <pwhalen> -1 blocker
17:58:07 <frantisekz> -1 blocker
17:59:05 <adamw> proposed #agreed 1620584 - RejectedBlocker (Beta) - crashes like this are obviously bad, but so far it does not seem to affect anyone else, and lruzicka could not reproduce it on the initially affected system during the meeting. we will reconsider if more information emerges
18:00:47 <lruzicka> ack
18:02:16 <frantisekz> ack
18:03:10 <adamw> #agreed 1620584 - RejectedBlocker (Beta) - crashes like this are obviously bad, but so far it does not seem to affect anyone else, and lruzicka could not reproduce it on the initially affected system during the meeting. we will reconsider if more information emerges
18:03:22 <Southern_Gentlem> ack
18:03:38 <adamw> ok, that's all the proposed blockers
18:03:46 <adamw> we have a huge number of proposed FEs, so i'm gonna try and prioritize on the fly
18:04:01 <adamw> preferring MODIFIED / ON_QA, and probably deprioritizing FTBFS bugs in non-critical packages
18:04:11 <adamw> #info moving onto proposed FEs, with some on-the-fly prioritization
18:04:18 <adamw> #topic (1622545) Extremely slow launching of apps on F29
18:04:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1622545
18:04:18 <adamw> #info Proposed Freeze Exceptions, at-spi2-core, ON_QA
18:04:39 <adamw> definite +1 FE here.
18:04:53 <frantisekz> +1 FE
18:05:04 <lruzicka> +1FE
18:07:07 <adamw> proposed #agreed 1622545 - AcceptedFreezeException (Beta) - this is obviously undesirable for the Workstation live and could not be fixed with an update for that case
18:07:41 <sgallagh> +1 FE
18:08:33 <frantisekz> ack
18:09:14 <lruzicka> ack
18:09:35 <pwhalen> +1 FE /ack
18:09:40 <adamw> #agreed 1622545 - AcceptedFreezeException (Beta) - this is obviously undesirable for the Workstation live and could not be fixed with an update for that case
18:09:50 <adamw> #topic (1598523) Make BootLoaderSpec-style configuration files the default
18:09:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1598523
18:09:50 <adamw> #info Proposed Freeze Exceptions, Changes Tracking, ON_QA
18:09:53 <adamw> ooh, here's one for cmurf
18:10:09 <cmurf> hmm
18:10:24 <cmurf> that's what i thought, default, but where's the change?
18:10:35 <adamw> it's not in the ChangeSet page for some reason
18:10:41 <adamw> the Change page exists and is in the 'approved' category
18:10:45 <adamw> but it's not been put in the ChangeSet page...
18:10:55 <cmurf> haha
18:11:00 <cmurf> so there might be others
18:11:15 <cmurf> might be nice to know
18:11:17 <adamw> this...hmm. i am kinda inclined to reject this, quite honestly.
18:11:33 <adamw> the change was supposed to be 'testable' by 08-14
18:11:42 <adamw> and we get an FE request to land it now, nearly three weeks later?
18:12:00 <cmurf> right
18:12:04 <cmurf> i'm gonna say no and no
18:12:16 <cmurf> get your ducks, then put them in a row
18:12:17 <adamw> frankly i am minded to propose a refinement of the Change rules
18:12:28 <cmurf> not your first day at the rodeo
18:12:38 <adamw> for any Change that involves changing a default, "testable" means "the modification of the default is actually implemented"
18:12:52 <adamw> not "all the bits are there somehow and you can turn them on manually"
18:13:03 <cmurf> seriously
18:13:07 <frantisekz> +1 to that idea
18:13:15 <adamw> sgallagh: mattdm: thoughts?
18:13:32 <sgallagh> I think FESCo ruled on this; let me find it
18:13:45 * adamw goes looking for these 'anaconda changes'
18:14:07 <adamw> https://github.com/rhinstaller/anaconda/pull/1545 , i think
18:14:19 <cmurf> I can vouch for the manual change working as designed, but there are some changes to the design that were discussed on devel@ that I  haven't personally tested
18:14:42 <cmurf> the anaconda changes ought to be trivial
18:14:45 <sgallagh> No, it skipped FESCo because pjones moved it to ON_QA
18:14:56 <sgallagh> Which appears to have been incorrect
18:15:14 <adamw> "To test this properly you need a system without grubby."
18:15:15 <adamw> ?!
18:15:16 <cmurf> i think so because i definitely have a failure due to the fact the change hasn't happened (in Silverblue)
18:15:17 <adamw> that scares me quite a lot.
18:15:25 <cmurf> haha
18:15:43 <cmurf> it's joy to my ears, although I'm not sure why grubby needs to be missing
18:15:50 <sgallagh> adamw: This shouldn't even be on this list, they tried to end-run the Change process.
18:15:54 <sgallagh> Kick it up to FESCo
18:16:00 <cmurf> yeah good idea
18:16:08 <cmurf> i mean, i'm in favor of the change, just not this way
18:16:11 <bcotton> +1 to kicking it to FESCo
18:16:12 <adamw> i am minded to just vote a straight -1 and say "you want to land this in f29, *you* escalate it to fesco"
18:16:20 <cmurf> that's sane too
18:16:33 <sgallagh> Yeah, that's  probably better
18:16:41 <sgallagh> It's definitely not within the FE guidelines
18:16:55 <sgallagh> The only way this is landing is with a FESCo-blocker... and I'm against that
18:16:56 <Southern_Gentlem> -1 take it to fesca
18:16:56 <cmurf> one of the unintended consquences of no alpha, is that more things aren't getting early warnings that they are missing ducks
18:17:00 <Southern_Gentlem> fesco
18:17:02 <adamw> cmurf: that's a fair point
18:17:23 <adamw> i'd suggest we look into ways we can propose bolstering the Change process to compensate for that
18:17:34 * sgallagh nods
18:17:41 <cmurf> but hey, less bureaucracy and people just aren't tracking their changes are actually  landing when they should
18:18:08 <cmurf> ^aren't landing
18:18:28 <adamw> proposed #agreed 1598523 - RejectedFreezeException (Beta) - this is a major functional change (and Change) which should have landed much earlier, it is not appropriate and potentially highly destabilizing for it to go in as a freeze exception now. note we are also opposed to it landing post-Beta for F29, it should be pushed to F30.
18:18:56 <adamw> cmurf: as noted above, this was set to ON_QA - indicating it was testable - when I'd argue it clearly wasn't
18:18:57 <Southern_Gentlem> ack
18:19:06 <cmurf> adamw: agreed
18:19:24 <adamw> please note that final bit of text, if you all sign off on that, i am going to use it as justification for a note on the anaconda PR requesting it not be merged to f29.
18:19:37 <cmurf> ack
18:19:47 <lruzicka> ack
18:19:53 <sgallagh> adamw: nack
18:20:02 <adamw> sgallagh: nack to the additional text?
18:20:17 <sgallagh> Please make that a recommendation, but FESCo should make that assertion (and deal with the associated fallout)
18:20:26 <sgallagh> Doesn't belong on your head
18:20:36 <cmurf> i personally would rather see changes like this land in Rawhide before the branch but I'm betting there's some reason why so many changes happen after branch and don't get applied to Rawhide until much later than I'd expect
18:20:38 <adamw> okay. i guess i'll escalate it to fesco somehow. but the PR is *currently approved*, so if we're going to stomp on it, we'd better do it soon
18:20:49 * sgallagh goes to weigh in
18:20:52 <adamw> cmurf: i think the reason is as simple as 'no-one plans properly'.
18:20:59 <cmurf> lol
18:21:23 <adamw> proposed #agreed 1598523 - RejectedFreezeException (Beta) - this is a major functional change (and Change) which should have landed much earlier, it is not appropriate and potentially highly destabilizing for it to go in as a freeze exception now.
18:21:31 <adamw> (same proposal, additioanl text removed)
18:21:31 <cmurf> sgallagh: wrestling?
18:22:24 <sgallagh> adamw: Ack
18:22:28 <cmurf> anyway... i support the push back, on the potential for blowups and failures, it's probably low; however it's significantly different bootloading
18:22:30 <sgallagh> I'll raise the FESCo ticket immediately.
18:22:41 <Southern_Gentlem> ack
18:22:50 <sgallagh> We have an expedited process now, I'll try to get a decision by tomorrow
18:22:55 <adamw> thanks
18:23:03 <adamw> can you add a note to the PR asking to wait for the fesco process?
18:23:08 <sgallagh> Already done
18:23:11 <adamw> awesome
18:23:13 <cmurf> super
18:23:37 <adamw> #agreed 1598523 - RejectedFreezeException (Beta) - this is a major functional change (and Change) which should have landed much earlier, it is not appropriate and potentially highly destabilizing for it to go in as a freeze exception now.
18:24:12 <adamw> #topic (1624838) package python3-behave-1.2.6-1.fc29.noarch conflicts with python2-behave < 1.2.6 provided by python2-behave-1.2.5-23.fc28.noarch
18:24:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624838
18:24:12 <adamw> #info Proposed Freeze Exceptions, fedora-obsolete-packages, ON_QA
18:24:26 <adamw> this looks like a pretty typical upgrade bug
18:24:33 <adamw> i'm fine with +1
18:24:56 <adamw> (note upgrades run with the repo set of the system being upgraded, so typically they run without updates-testing; this is the value of FEs to fix upgrade bugs)
18:25:40 <Southern_Gentlem> +1 fe
18:26:04 <lruzicka> +1 fe
18:26:12 <frantisekz> +1 FE
18:27:17 <adamw> proposed #agreed 1624838 - AcceptedFreezeException (Beta) - this prevents upgrades without --allowerasing which can be destructive; it merits an FE to allow upgrades with this package and without updates-testing or --allowerasing to proceed
18:27:56 <frantisekz> ack
18:30:22 <adamw> any more acks?
18:30:31 <adamw> class, nobody is going home till i get some acks
18:30:33 <adamw> we can all sit here all day
18:30:37 <frantisekz> :D
18:30:49 <coremodule> ack
18:31:03 <adamw> #agreed 1624838 - AcceptedFreezeException (Beta) - this prevents upgrades without --allowerasing which can be destructive; it merits an FE to allow upgrades with this package and without updates-testing or --allowerasing to proceed
18:31:22 <adamw> #topic (1623471) Spurious connection errors: "Server did not return a valid TLS certificate"
18:31:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1623471
18:31:23 <adamw> #info Proposed Freeze Exceptions, gnutls, ON_QA
18:31:53 <adamw> +1 FE, this basically breaks Evo
18:32:01 <adamw> (which is on the live)
18:32:48 <Southern_Gentlem> +1
18:33:15 <lruzicka> +1, seems annoying
18:35:33 <frantisekz> +1 FE
18:36:04 <sgallagh> +1 FE
18:36:52 <adamw> proposed #agreed 1623471 - AcceptedFreezeException (Beta) - this breaks major functionality of Evolution and other apps which are included in the Workstation live, thus cannot be fully fixed with an update
18:37:01 <frantisekz> ack
18:37:14 <Southern_Gentlem> ack
18:37:52 <adamw> #agreed 1623471 - AcceptedFreezeException (Beta) - this breaks major functionality of Evolution and other apps which are included in the Workstation live, thus cannot be fully fixed with an update
18:38:02 <adamw> #topic (1623132) krita is outdated in F29 and depends on libraw.so.16
18:38:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1623132
18:38:02 <adamw> #info Proposed Freeze Exceptions, krita, VERIFIED
18:38:14 <lruzicka> +1 fe
18:38:23 <adamw> thanks to good ol' https://bugzilla.redhat.com/show_bug.cgi?id=1427365 , the consequence of this is that the affected packages are just silently left out of the KDE live
18:38:25 <frantisekz> +1 FE
18:38:29 <adamw> obviously we want them to be on there
18:38:30 <adamw> so, +1
18:40:18 <adamw> proposed #agreed 1623132 - AcceptedFreezeException (Beta) - this results in packages being silently left off the KDE live images, which obviously we want to fix
18:40:33 <Southern_Gentlem> ack
18:40:41 <lruzicka> ack
18:40:53 <adamw> #agreed 1623132 - AcceptedFreezeException (Beta) - this results in packages being silently left off the KDE live images, which obviously we want to fix
18:40:54 <adamw> #topic (1625053) Icons missing for LXQt application menu
18:40:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625053
18:40:54 <adamw> #info Proposed Freeze Exceptions, lxqt-panel, MODIFIED
18:41:19 <adamw> +1, fix is restricted to lxqt, we ship an lxqt live so obviously can't fix that with an update
18:41:29 <frantisekz> +1 FE
18:41:42 <Southern_Gentlem> +1
18:43:37 <adamw> proposed #agreed 1625053 - AcceptedFreezeException (Beta) - this issue affects one of our live images and cannot be resolved with an update, fix is clearly limited to lxqt only, cannot break anythong else
18:43:40 <adamw> proposed #agreed 1625053 - AcceptedFreezeException (Beta) - this issue affects one of our live images and cannot be resolved with an update, fix is clearly limited to lxqt only, cannot break anything else
18:43:46 <adamw> (typo)
18:44:15 <frantisekz> ack
18:44:18 <lruzicka> ack
18:44:38 <adamw> #agreed 1625053 - AcceptedFreezeException (Beta) - this issue affects one of our live images and cannot be resolved with an update, fix is clearly limited to lxqt only, cannot break anything else
18:44:48 <adamw> #topic (1624739) Upgrade from F28 fails due to different names of subpackage
18:44:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624739
18:44:48 <adamw> #info Proposed Freeze Exceptions, lxqt-themes, ON_QA
18:44:54 <adamw> another upgrade case, +1, same reason as the first
18:44:59 <frantisekz> +1 FE
18:47:59 <lruzicka> +1 fe
18:48:34 <adamw> proposed #agreed 1624739 - AcceptedFreezeException (Beta) - this prevents upgrades without --allowerasing which can be destructive; it merits an FE to allow upgrades with this package and without updates-testing or --allowerasing to proceed
18:48:39 <frantisekz> ack
18:49:57 <adamw> lruzicka: ?
18:50:28 <lruzicka> ack
18:51:23 <adamw> #agreed 1624739 - AcceptedFreezeException (Beta) - this prevents upgrades without --allowerasing which can be destructive; it merits an FE to allow upgrades with this package and without updates-testing or --allowerasing to proceed
18:51:26 <adamw> #topic (1575328) Xorg crashes after latest mesa update
18:51:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1575328
18:51:26 <adamw> #info Proposed Freeze Exceptions, mesa, ON_QA
18:51:34 <frantisekz> +1 FE
18:52:12 <adamw> hrm
18:52:17 <adamw> in principle i like fixing crashes, but:
18:52:28 <adamw> "The fix is rebasing mesa to a newer rc which contains a handful of fixes carefully cherry-picked by upstream, as such we are using the upstream fix here and not rolling our own. .. Note that this also involves adding a newer llvm build"
18:52:41 <adamw> that's...quite a lot of change. i think i'm probably still OK given where we are in the cycle, but wanted to note it
18:52:44 <adamw> so, tentative +1 for me
18:52:48 <frantisekz> yeah, might seem like a pretty big FE.. but we're going to ship that code anyway in a few weeks
18:53:07 <lruzicka> +1 FE, if there is a chance on improving the stability
18:54:22 <adamw> let's just make sure we test it...
18:55:00 <frantisekz> yep, I'll focus a little bit more on this
18:55:12 <adamw> proposed #agreed 1575328 - AcceptedFreezeException (Beta) - this fixes failure of X to start on some hardware, which is important and cannot be fixed with an update. We do note this fix involves significant change to critical components and should be carefully tested
18:55:24 <frantisekz> ack
18:55:31 <lruzicka> ack
18:55:54 <adamw> #agreed 1575328 - AcceptedFreezeException (Beta) - this fixes failure of X to start on some hardware, which is important and cannot be fixed with an update. We do note this fix involves significant change to critical components and should be carefully tested
18:56:06 <adamw> #topic (1624353) Xfce: Sorry, your Window Manager does not support compositing
18:56:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624353
18:56:06 <adamw> #info Proposed Freeze Exceptions, xfwm4, MODIFIED
18:58:46 <frantisekz> +1 FE, seems limited to xfce spin?
18:58:53 <adamw> this seems reasonable to me and is limited in impact to xfwm
18:59:01 <adamw> frantisekz: yes, but note Xfce-on-32-bit-ARM is actually release blocking
18:59:16 <adamw> however, it looks like they're putting this together carefully, and it'll be easy enough to revert again if it turns out to be necessary
18:59:19 <adamw> so, +1
18:59:42 <lruzicka> +1 FE, I think. The bug looks like there is a solution provided
18:59:44 <frantisekz> yeah... I always forget hat the Workstation is not the only Blocking desktop....
18:59:47 <frantisekz> *that
19:01:41 <adamw> proposed #agreed 1624353 - this bug affects live and ARM disk image media and thus cannot be fixed fully with an update. The change here seems well planned and in accordance with upstream's intentions, and can be reverted if it turns out to cause problems
19:01:44 <adamw> guh
19:01:51 <adamw> proposed #agreed 1624353 - AcceptedFreezeException (Beta) - this bug affects live and ARM disk image media and thus cannot be fixed fully with an update. The change here seems well planned and in accordance with upstream's intentions, and can be reverted if it turns out to cause problems
19:01:57 <frantisekz> ackity ack
19:02:01 <lruzicka> ack
19:02:33 <adamw> #agreed 1624353 - AcceptedFreezeException (Beta) - this bug affects live and ARM disk image media and thus cannot be fixed fully with an update. The change here seems well planned and in accordance with upstream's intentions, and can be reverted if it turns out to cause problems
19:02:38 <adamw> OK, so we're now at time
19:02:49 <adamw> and that's all the most important FEs per my quick look
19:02:54 <lruzicka> how many are still left?
19:02:57 <adamw> we can vote on the others in-bug or at another meeting
19:03:07 <adamw> quite a lot, but a lot of them are FTBFS bugs
19:03:25 <frantisekz> can't we mass-accept FTBS bugs?
19:03:30 <cmurf> seems a bit late in process for FTBFS bugs
19:03:32 <adamw> i would mass accept them for *final*
19:03:37 <frantisekz> ok
19:03:41 <adamw> for beta, i don't see a lot of benefit in granting FEs for ftbfs
19:03:45 <adamw> they can just as well go through bodhi
19:03:59 <adamw> unless there's some further consequence to the package being ftbfs
19:04:11 <adamw> i'll try and look through them all and flag up any significant ones for voting, or something
19:04:21 <adamw> #topic Open floor
19:04:23 <lruzicka> ok
19:04:44 <frantisekz> I don't think we have something significant there FTBS, went through some of them
19:04:47 <adamw> #info there are many remaining proposed FEs, but we are at time; many seem to be FTBFS bugs, and there's no obvious reason to grant Beta FE purely because a package is FTBFS
19:05:05 <adamw> any other vital pressing business, or can we all go get lunch/beer now? :)
19:05:46 <frantisekz> I already started drinking :D ... few hours when meeting started... will happily continue with that
19:06:34 <adamw> hear that, folks? that's Fedora's outstanding professionalism coming to the fore
19:06:36 <adamw> :P
19:06:56 <frantisekz> ... :D :D :D
19:06:57 <adamw> thanks a lot for sticking it out to the end, you two
19:07:07 <frantisekz> thank you too adam
19:07:47 <lruzicka> thank you, adam
19:08:08 <lruzicka> I will check the bugs you suggest and vote for them in BZ
19:09:42 <adamw> thanks
19:09:49 <adamw> ok, go continue drinking :P
19:09:50 <adamw> #endmeeting