16:01:30 <adamw> #startmeeting F29-blocker-review
16:01:30 <zodbot> Meeting started Mon Sep 10 16:01:30 2018 UTC.
16:01:30 <zodbot> This meeting is logged and archived in a public location.
16:01:30 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:30 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:30 <adamw> #meetingname F29-blocker-review
16:01:30 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:30 <adamw> #topic Roll Call
16:01:39 <adamw> morning folks! who's here to review some blockers?
16:01:43 <lruzicka> .hello2
16:01:44 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:01:54 <bcotton> .hello2
16:01:55 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:01:59 <frantisekz> .hello2
16:02:01 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:03 <lbrabec> .hello2
16:02:04 <coremodule> .hello2
16:02:04 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com>
16:02:07 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:02:15 * coremodule ready for secretary duties!
16:02:35 <kalev> .hello2
16:02:36 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:02:54 * sgallagh is concurrently in the FESCo meeting as well as spraying water on two small fires.
16:02:59 <Southern_Gentlem> .hello
16:03:02 <zodbot> Southern_Gentlem: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:03:07 <Southern_Gentlem> .hello jbwillia
16:03:08 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:03:20 * pwhalen is here
16:03:40 <cmurf> .hello2
16:03:41 <zodbot> cmurf: Sorry, but you don't exist
16:03:44 <cmurf> haha
16:03:58 <cmurf> .hello chrismurphy
16:03:59 <adamw> .fire cmurf for unauthorized non-existence
16:03:59 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:04:01 <zodbot> adamw fires cmurf for unauthorized non-existence
16:04:19 <adamw> so, heads up: I'm gonna have to duck out after 45 mins to an hour to take my cat to the vet
16:04:30 <adamw> if someone can volunteer to be ready to take over then, that'd be great
16:05:43 <cmurf> good luck with that adamw!
16:06:00 * pwhalen hopes all is well with the furry one
16:06:13 <lruzicka> So let's jump into medias res to cover as much as possible
16:06:40 <adamw> #chair lruzicka coremodule
16:06:40 <zodbot> Current chairs: adamw coremodule lruzicka
16:07:18 <adamw> #topic Introduction
16:07:18 <adamw> Why are we here?
16:07:18 <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:07:18 <adamw> #info We'll be following the process outlined at:
16:07:20 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:21 <adamw> #info The bugs up for review today are available at:
16:07:23 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:24 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:26 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:28 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:07:30 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:07:32 <adamw> we have:
16:07:34 <adamw> #info 4 Proposed Blockers (Beta)
16:07:39 <adamw> #info 24 Proposed Freeze Exceptions (Beta)
16:07:47 <adamw> #info 5 Proposed Blockers (Final)
16:08:24 <adamw> i am gonna further suggest that, when we get there, we do a block vote on proposed FEs of a certain kind: packages that were FTBFS and have dependency issues that can affect upgrades, and don't seem to have any other complications
16:08:37 <adamw> but for now, let's start with the proposed Beta blockers...
16:08:42 <adamw> #info coremodule will secretarialize
16:09:26 <adamw> #info starting with proposed Beta blockers
16:09:27 <adamw> #topic (1626844) grub2-2.02-54.fc29 fails to boot, drops to grub shell
16:09:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626844
16:09:27 <adamw> #info Proposed Blocker, grub2, NEW
16:09:57 <frantisekz> +1 Blocker
16:10:16 <adamw> this is not the same bug as the previous grub blocker, note
16:10:26 <adamw> so, grub timeline: no-one seemed too hacked off with -51
16:10:38 <adamw> -52 broke x86_64 UEFI for just about everyone
16:10:48 <adamw> -54 seems to have fixed it for a lot of folks, but not all
16:10:50 <Southern_Gentlem> +1 blocker
16:11:08 <pwhalen> +1
16:11:10 <adamw> we have this bug, where 2 people with thinkpads report ongoing problems, and frantisekz's https://bugzilla.redhat.com/show_bug.cgi?id=1626862
16:11:28 <cmurf> interesting bug
16:11:34 <cmurf> not across the board?
16:11:41 <adamw> we do not currently have any idea what the problem is here, or what the fix might be. but i am inclined to say we should just back the hell off whatever -52 did and go back to what was in -51, plus whatever the actual blocker/FE fix was in -52
16:11:50 * sgallagh is running -54 successfully
16:11:58 <sgallagh> -52 broke me badly
16:12:14 <adamw> cmurf: no. see https://bugzilla.redhat.com/show_bug.cgi?id=1624532 and https://bugzilla.redhat.com/show_bug.cgi?id=1624525 where lots of folks indicate success with -54
16:12:21 <frantisekz> for my case (#1626862), -51 seems broken too
16:12:22 <adamw> but it seems like -52 introduced more than one bug...
16:12:28 <adamw> frantisekz: ah, ok. that's useful info
16:12:32 * lruzicka still uses -51. Did not update after frantisekz warning.
16:12:36 <pwhalen> -51 was broken on aarch64 iirc
16:12:38 <adamw> frantisekz: so only f28 grub works there?
16:12:42 <adamw> pwhalen: yeah, i think that's the blocker fix we need
16:12:48 <pwhalen> ok
16:12:50 <adamw> but all this change to x86_64 doesn't seem like it needs to come along for the ride
16:12:59 <pwhalen> right, noticed that
16:13:05 <frantisekz> adamw yeah, but it has to be together with fc28 shim
16:13:09 <cmurf> f28 grub is way back to -38
16:13:17 <frantisekz> fc28 grub with fc29 shim is broken too
16:13:18 <cmurf> there's a -43 in koji but I don't have that for whatever reason
16:13:21 <adamw> anyway, that bug isn't on the list, so let's forget about it and concentrate on this one
16:14:04 <adamw> so we only have two reports here, but given that they're both thinkpads and thinkpads are pretty common hw for fedora, i'm inclined to +1 too
16:14:06 <cmurf> i don't have enough info to say for sure +1 blocker
16:14:21 <adamw> hmm
16:14:24 <adamw> in fact we only have *one* report
16:14:26 <cmurf> i'm on the fence
16:14:28 <adamw> since frantisek's bug isn't the same
16:14:31 <adamw> so, yeah, tougher call
16:14:32 <cmurf> right
16:14:37 <sgallagh> adamw: What model thinkpads?
16:14:45 <adamw> the reporter of this bug has a t440p
16:14:49 <sgallagh> My P50 (which breaks if anyone sneezes in its vicinity) was fixed by -54
16:14:50 <adamw> anyone have anything like that they can test on?
16:15:12 * adamw makes note to avoid eating pepper around sgallagh
16:15:23 <adamw> oh, wait, no, we have two reports again :)
16:15:25 * Southern_Gentlem throws pepper at sgallagh
16:15:27 <adamw> vit ondruch's latest comment
16:15:33 <lruzicka> I have a T460s, still running the older 51 version. I could update now, but it might leave me with nothing.
16:15:35 <adamw> "I was testing this on Lenovo T440s. -53 and -54 dropped to the grub shell."
16:15:38 <kalev> I have t440s I think, but it's not set up for EFI
16:16:34 <adamw> lruzicka: do you know the procedure for recovering to -51? boot a live image or rescue image, mount the installed system root *ensuring you mount the ESP to /boot/efi*, then do dnf --installroot (location) downgrade , more or less...
16:16:40 <adamw> but maybe try it *after* the meeting :)
16:16:43 <adamw> kalev: :/
16:16:57 <adamw> kalev: i wonder if you could try latest rawhide live on it?
16:17:01 <adamw> latest rawhide should have the same grub
16:17:09 <adamw> booting in efi mode obvs
16:17:12 <kalev> adamw: ah, sure, I can give it a try
16:17:20 <kalev> after the meeting :)
16:17:43 <lruzicka> ok, I can do it after the meeting
16:17:56 <adamw> thanks guys
16:18:07 <cmurf> What about asking in the bug to cell phone photo the grub 'set' output?
16:18:13 <adamw> it is excessively annoying that pjones dumped this problematic grub on us then went off on vacation
16:18:22 <adamw> cmurf: you know more about grub debugging than i do, i think
16:18:30 <adamw> so can you please ask that and anything else that may help in the bug?
16:18:31 <cmurf> I'll add to the bug.
16:18:35 <adamw> thanks
16:18:50 <adamw> i guess i'll also ping hans and mjg59
16:19:05 <adamw> so, i guess i'm gonna say 'punt' for this one
16:19:41 <Southern_Gentlem> +1 punt for now
16:20:00 <frantisekz> ok, +1 punt then :)
16:20:06 <lruzicka> +1 punt, until we see more results? OK.
16:20:10 <Southern_Gentlem> do we have time to really punt this with go/nogo on thursday
16:20:17 <adamw> Southern_Gentlem: yeah, for a day or so
16:20:29 <adamw> i'm intending to try and figure out what's going on today if we possibly can
16:20:39 <adamw> it'll help a lot if frantisekz and/or kparal can reproduce of course
16:20:45 <adamw> er, lruzicka
16:20:46 <adamw> sigh
16:21:05 <Southern_Gentlem> ok next
16:21:08 <cmurf> haha my comment is hilarious(ly crazy) per usual
16:21:12 <cmurf> +1 punt
16:21:27 <adamw> proposed #agreed 1626844 - punt (delay decision) - this one looks worrying, but so far only one laptop model definitely seems to be affected and we're not sure what the problem is. we'll try and figure out what's going on here today so we can make a decision on it soon
16:21:33 <cmurf> ack
16:21:36 <kalev> ack
16:21:38 <frantisekz> ack
16:21:43 <pwhalen> ack
16:21:45 <lbrabec> ack
16:21:47 <lruzicka> I will update today, and see. If there is problem, I will be trying to get back into saddle tomorrow.
16:21:53 <lruzicka> ack
16:22:32 <adamw> #agreed 1626844 - punt (delay decision) - this one looks worrying, but so far only one laptop model definitely seems to be affected and we're not sure what the problem is. we'll try and figure out what's going on here today so we can make a decision on it soon
16:22:54 <adamw> cmurf: welp, apparently if you do this job long enough, you will witness someone ask for cellphone photos from a darkened bathroom on a bugzilla report. :P
16:23:05 <cmurf> :-D
16:23:09 <adamw> usually that request would have me calling the campus harassment hotline, but...
16:23:15 <cmurf> haha
16:23:28 <cmurf> hey i don't wanna add another comment later "too much glare retake photo!"
16:23:44 <adamw> #topic (1624972) No GUI desktop
16:23:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624972
16:23:45 <adamw> #info Proposed Blocker, lightdm, MODIFIED
16:23:45 <cmurf> bit motherhen though i admit
16:24:19 <adamw> i'm gonna say provisional +1 assuming this affects the arm xfce image...
16:24:22 <adamw> pwhalen, have you seen this?
16:25:03 <lruzicka> I have been using lightdm, and I am using it at home, and unfortunately never have seen something like that.
16:25:30 <pwhalen> adamw, I haven't. but dont have that hw
16:25:40 <adamw> pwhalen: hum, so could be hardware specific?
16:26:07 <cmurf> ruh roh
16:26:21 <pwhalen> it seemed to be, tested on a bunch of devices without seeing that
16:26:45 <adamw> ok
16:26:57 <adamw> so i'd say +1 FE, except...have you tested the *new* lightdm on the same bunch of devices?
16:27:10 <adamw> i'm reluctant to pull a new version that fixes one piece of hw but which we haven't tested on others, at this point
16:27:14 <cmurf> yep, i change my in bug vote to +1 FE
16:27:14 <pwhalen> I have, doing updates.. didnt see any regression
16:27:17 <adamw> ok
16:27:21 <cmurf> if it's tested
16:27:23 <cmurf> !
16:27:23 <adamw> then i guess i'll go +1 FE then
16:27:29 <pwhalen> i'd be ok with +1 FE
16:27:30 <Southern_Gentlem> +1 FE
16:27:32 <kalev> +1 FE
16:27:48 <frantisekz> +1 FE
16:28:05 <lruzicka> +1FE
16:28:34 <adamw> proposed #agreed 1624972 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - per pwhalen's testing this seems hardware-specific (he has not seen it, on multiple devices), so we decided it's not bad enough to constitute a blocker. however, we're accepting it as a freeze exception issue as obviously the impact on hardware that *is* affected is significant
16:28:50 <Southern_Gentlem> ack
16:28:56 <frantisekz> ack
16:28:59 <pwhalen> ack
16:29:03 <lruzicka> ack
16:29:20 <adamw> #agreed 1624972 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - per pwhalen's testing this seems hardware-specific (he has not seen it, on multiple devices), so we decided it's not bad enough to constitute a blocker. however, we're accepting it as a freeze exception issue as obviously the impact on hardware that *is* affected is significant
16:29:20 <kalev> ack
16:29:26 <adamw> #topic (1626413) Add dependency on librepo
16:29:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626413
16:29:26 <adamw> #info Proposed Blocker, lorax, NEW
16:29:46 <cmurf> adamw is your last comment still valid?
16:29:49 <adamw> yeah
16:29:50 <cmurf> if so +1 to that and -1 blocker
16:29:54 <adamw> this is sort of a problem-in-waiting
16:30:11 <adamw> if i'm reading it right, basically when we pull a new-enough dnf in, lorax will need this dep
16:30:34 <cmurf> gotcha
16:30:38 <Southern_Gentlem> +1 fe
16:30:49 <lruzicka> +1 FE
16:30:52 <kalev> +1 FE
16:31:33 <adamw> i mean, it doesn't technically make a lot of sense to call it an FE. if we have the problem, it's a blocker. if we don't have the problem, it's neither.
16:31:49 <adamw> i'm inclined to just kick it out of the blocker process and say 'we'll make sure we don't push an update with the problem'.
16:32:01 <frantisekz> we can't say it's blocker if it's not broken yet :D
16:32:03 <cmurf> right that's what I'm +1 ing, from the comment in the bug
16:33:01 <lruzicka> can we accept changes after freeze, when it is not in BB or FE?
16:33:28 <frantisekz> depends if we are going to pull the new dnf before beta release, are we?
16:33:37 <adamw> lruzicka: if we're pulling in a dnf update to fix some other blocker/FE, and for lorax to work with that dnf update it needs this dep added, yes, we can legitimately include the lorax change in the update
16:33:41 <adamw> it doesn't need its own blocker/fe bug
16:34:14 <Southern_Gentlem> -1 and move on
16:34:30 <lruzicka> how do we make sure we do not forget?
16:34:50 <cmurf> well we could punt if you want to use that as a reminder mechanism adamw
16:35:25 <cmurf> but the problem is gonna be obvious if/when it hits, yeah?
16:35:28 <adamw> lruzicka: with the power of braaaains
16:35:32 <cmurf> in which case just kick it
16:35:37 <adamw> cmurf: it wouldn't be until we *pushed the update stable*
16:35:40 <adamw> because composes use what's in stable
16:35:51 <adamw> i am workin on an openqa test that checks whether lorax works with the update, but it's not done yet.
16:35:58 <adamw> (and we wouldn't run it on every update anyhow.)
16:36:32 <adamw> if people are worried, it'd be fine to vote this +1 blocker with a note that it's sort of provisional
16:36:43 <adamw> we can clean things up at go/no-go based on what's happened by then
16:36:54 <cmurf> gets cleaned up either way
16:37:01 <lruzicka> WHAT
16:37:10 <lruzicka> sorry, whatever suits you then
16:37:20 <cmurf> i'd say -1 clear the board, you'll learn from your openqa test probably later today
16:37:46 <lruzicka> ok, so -1
16:38:09 <adamw> cmurf: it has an awkward bug i've not had time to look into for a week. so i probably won't. but, i intend to not forget about it. :P
16:38:11 <cmurf> (we have adamw for 7 minutes and counting)
16:38:43 <cmurf> +1 for whatever adamw wants to do with this bug :P
16:39:07 <adamw> proposed #agreed 1626413 - RejectedBlocker (Beta) - this may be a blocker if we pulled in a dnf update that drops the librepo dependency without adding the dependency to lorax. but for now, it is not. we will ensure that any dnf update we pull in comes with any necessary changes to lorax so this does not become a blocker.
16:39:08 <pwhalen> heh, +1 to that too
16:39:15 <frantisekz> ack
16:39:16 <cmurf> ack
16:39:18 <pwhalen> ack
16:39:23 <Southern_Gentlem> ack
16:39:24 <lruzicka> ackster
16:39:25 <adamw> #agreed 1626413 - RejectedBlocker (Beta) - this may be a blocker if we pulled in a dnf update that drops the librepo dependency without adding the dependency to lorax. but for now, it is not. we will ensure that any dnf update we pull in comes with any necessary changes to lorax so this does not become a blocker.
16:39:31 <cmurf> whew!
16:39:32 <adamw> #topic (1616269) [abrt] xorg-x11-server-Xwayland: OsLookupColor(): Display server crashed
16:39:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1616269
16:39:32 <adamw> #info Proposed Blocker, xorg-x11-server, MODIFIED
16:39:38 <adamw> so, this is the one where we wanted the call for testing
16:39:39 <cmurf> -1 blocker, +1 FE
16:39:42 <adamw> i sent it out, but only yesterday
16:40:01 <cmurf> right, hence i'm -1 on it for now
16:40:10 <cmurf> ^blocking
16:40:30 <cmurf> but FE seems sane and safe and tested (by 1)
16:41:05 <kalev> I'm -1 blocker, +1 FE as well
16:41:09 <adamw> yeah, i can go with that
16:41:22 <frantisekz> +1 FE
16:41:28 <lruzicka> -1 B +1 FE
16:41:50 <pwhalen> -1 blocker, +1 FE
16:42:06 <Southern_Gentlem> i was going to say i smell nvidia
16:42:09 <Southern_Gentlem> +1 FE
16:42:20 <adamw> proposed #agreed 1616269 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - we haven't received any indication that lots of people will run into these crashes often, so it doesn't seem the impact is serious enough for blocker status, but there are definitely real crasher bugs here it would be good to have fixed on the media, so it is accepted as an FE issue
16:42:25 <cmurf> ack
16:42:26 <coremodule> ack
16:42:28 <frantisekz> ack
16:42:29 <pwhalen> ack
16:42:31 <adamw> Southern_Gentlem: no nvidia involved. this is sgallagh, come on.
16:42:36 <lruzicka> ack
16:42:52 <sgallagh> hmm?
16:42:57 <adamw> ok, nvidia *hardware*, not the proprietary driver :)
16:43:02 <adamw> sgallagh: i was defending your good name :P
16:43:06 <adamw> #agreed 1616269 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - we haven't received any indication that lots of people will run into these crashes often, so it doesn't seem the impact is serious enough for blocker status, but there are definitely real crasher bugs here it would be good to have fixed on the media, so it is accepted as an FE issue
16:43:09 <sgallagh> Right, this is Nouveau
16:43:13 <cmurf> proposal: jump to the gnome 3.30 megaupdate FE before adamw has to leave?
16:43:17 <Southern_Gentlem> comment 11
16:43:28 <pwhalen> cmurf, +1
16:43:30 <Southern_Gentlem> next
16:43:41 <adamw> cmurf: good idea
16:43:46 <adamw> #info that's all the proposed blockers
16:43:50 <adamw> #info moving onto proposed FEs
16:43:55 <adamw> #topic (1627459) Include GNOME 3.30.0 in Fedora 29 Beta
16:43:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1627459
16:43:55 <adamw> #info Proposed Freeze Exceptions, distribution, NEW
16:43:59 <adamw> so uh
16:44:04 <adamw> is the fesco meeting still going on?
16:44:05 <adamw> cuz...:P
16:44:06 <sgallagh> I had a conversation with the Workstation folks today in their WG meeting
16:44:08 <pwhalen> yep
16:44:10 <cmurf> ROFL
16:44:20 <cmurf> I see they want the FE in their meeting notes
16:45:04 <maxamillion> o/
16:45:11 <cmurf> (my laugh is for adamw not for WG wanting this FE)
16:45:12 <sgallagh> I changed my perspective on this. I'm inclined to allow it through now.
16:45:17 <adamw> so i'm running this on my desktop, and it's been through openqa both in f29 update form and in rawhide, and it seems to work pretty well.
16:45:40 <adamw> it does suck that it's coming in so late, and that we have this schedule issue, but, i'm still gonna vote +1
16:45:40 <sgallagh> We've agreed that the process needs to be fixed up for F30 and have some ideas how to do that so we do not end up in this situation again
16:45:45 <frantisekz> I've tested it briefly yesterday, everything seems fine so far
16:45:54 <adamw> because it doesn't make any sense to me that we ship beta with random bits of 3.28 and 3.29, then go to final with 3.30
16:45:56 <Southern_Gentlem> +1 fe
16:45:59 <frantisekz> +1 FE
16:46:01 <adamw> i'd rather put 3.30 in the beta and slip if it breaks
16:46:02 <kalev> I fixed a few regressions today, not aware of anything blocking right now
16:46:05 <lruzicka> I am +1 FE here, they will eat us if we don't allow it
16:46:07 <coremodule> +1 FE
16:46:11 <pwhalen> +1 FE
16:46:12 <sgallagh> The proposal is that, starting with F30, GNOME will ask for *two* FEs.
16:46:14 <maxamillion> I'll defer to adamw on the topic ... FWIW, if this were to come to FESCo I'd vote however adamw does
16:46:16 <cmurf> OK +1 FE for me too why not?
16:46:30 <sgallagh> One for 3.31.92 which is released the same day we enter Freeze
16:46:41 <adamw> the only sane reason to not put the update in beta would be if we were going to say we'll not accept it for final either
16:46:54 <sgallagh> They'd land that immediately so as to get testing of the near-final bits while they prepare the final .0 release to also land within Freeze
16:46:55 <zbyszek> +1 then
16:46:58 <adamw> and that would be nuts, we'd either be shipping final with an eternally unsupported mix of pre-release bits or requesting a downgrade to 3.28.
16:47:30 <cmurf> gotcha
16:47:39 * kalev agrees.
16:48:07 <sgallagh> Anyway, I've changed my stance to +1 on this particular update
16:48:08 <lruzicka> People want leading edge
16:48:15 <sgallagh> (And may FSM have mercy on my soul)
16:48:21 <cmurf> i'm counting +9 or +10
16:48:22 <kalev> mattdm was also pro allowing it in
16:48:48 <sgallagh> Also, I've been running the u-t bits all day and only crashed sixteen or seventeen times! ;-)
16:48:57 <pwhalen> heh
16:48:58 <adamw> proposed #agreed 1627459 - AcceptedFreezeException (Beta) - it's obviously suboptimal to take such a major change so late, but the other choices are to ship Beta with a messy mixed-up GNOME but Final with 3.30+, or to kick 3.30 out of Final. neither of those choices makes much sense, so pulling 3.30 into Beta (even late) seems the least worst option
16:49:02 <cmurf> sgallagh: that's your o ther bug :P
16:49:02 <Southern_Gentlem> ack
16:49:04 <kalev> sgallagh: is that the xorg crash?
16:49:12 <frantisekz> ack
16:49:13 <coremodule> ack
16:49:13 <sgallagh> That was just a joke.
16:49:14 <cmurf> yes he's teasing
16:49:18 <kalev> ahh! :)
16:49:19 <kalev> ack
16:49:22 <cmurf> ack
16:49:27 <pwhalen> ack
16:49:29 <sgallagh> I'm running the scratch-build of the Xorg fixes and I haven't hit a crash since, actually
16:49:33 <sgallagh> It's been quite nice
16:49:36 <sgallagh> ack
16:49:44 <lruzicka> ack
16:49:48 <adamw> i do have the problem with boot being weirdly slow
16:50:02 <adamw> takes a long time to reach gdm, then longer than it should from gdm to deskto
16:50:03 <adamw> p
16:50:06 <adamw> that's not new in 3.30, though
16:50:10 <lruzicka> adamw, there is a bug for that problem already
16:50:12 * adamw needs to go bang on those bugs later
16:50:13 <adamw> yeah i know
16:50:20 <adamw> #agreed 1627459 - AcceptedFreezeException (Beta) - it's obviously suboptimal to take such a major change so late, but the other choices are to ship Beta with a messy mixed-up GNOME but Final with 3.30+, or to kick 3.30 out of Final. neither of those choices makes much sense, so pulling 3.30 into Beta (even late) seems the least worst option
16:50:24 <adamw> just had more urgent fires to fight...
16:50:26 <cmurf> kitty cat
16:50:29 <adamw> ok, so i'm gonna duck out here
16:50:33 <adamw> can someone please take over the chair?
16:50:37 <adamw> any volunteers?
16:50:56 <lruzicka> I'd rather see someone more experienced than me.
16:51:05 <adamw> i would suggest we vote on any non-FTBFS proposed FEs that are POST, MODIFIED or ON_QA, then do a block vote on simple upgrade-affecting FTBFSes as i proposed earlier
16:51:12 <adamw> lruzicka: there's only one way to get experience, you know ;)
16:51:31 * adamw distributes some chairs and lets God sort it out
16:51:37 <lruzicka> adamw, yeah, I know
16:51:38 <cmurf> i'm a pretty decent border collie
16:51:49 <cmurf> for whoever takes the chair
16:51:53 <adamw> #chair sgallagh cmurf pwhalen
16:51:53 <zodbot> Current chairs: adamw cmurf coremodule lruzicka pwhalen sgallagh
16:52:01 <adamw> go forth and figure something out. :P i'll be back
16:52:37 <sgallagh> I'm overcommitted right now and will not be sufficiently present to run the meeting, sorry
16:53:04 <Southern_Gentlem> and i do not know enough to run it
16:53:15 <lruzicka> So, how are we going to proceed? Skip all FTBFS FEs and go through the rest?
16:53:26 <cmurf> yes
16:53:37 <Southern_Gentlem> for info whar are FTBFS
16:53:43 <Southern_Gentlem> what
16:53:57 <lruzicka> Failed to build ...
16:54:00 <cmurf> if someone can secretarialize I can sorta plod us along for a bit then I have to go too
16:54:08 <cmurf> fail to build from source
16:54:27 <cmurf> we can skip those, adawm is gonna block approve the ones that are preventing dnf system upgrades
16:54:33 <lruzicka> ok, so we have #topic 1626076
16:54:37 <cmurf> (well and gnome software upgrades for that matter)
16:54:39 <coremodule> cmurf, I have secretarializing duties
16:55:13 <lruzicka> #topic (1626076) Raspberry Pi fixes and improvements for IoT
16:55:13 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626076
16:55:13 <lruzicka> #info Proposed Freeze Exceptions, bcm283x-firmware, ON_QA
16:55:28 <coremodule> +1 FE
16:55:35 <pwhalen> +1 FE
16:55:35 <cmurf> yeah I'm +1 FE
16:55:43 <Southern_Gentlem> +1 FE
16:55:47 <lruzicka> +1 FE
16:55:54 <kalev> +1 FE
16:56:24 <lruzicka> so, let me see, I'll try hard
16:57:57 <cmurf> looks safe and improves testing coverage
16:58:59 <lruzicka> proposed  #agreed 1626076 AcceptedFreezeException (Beta) - We believe that maximizing windows without crashes is an important feature of a desktop environment.
16:59:26 <Southern_Gentlem> nack
16:59:39 <lruzicka> Southern_Gentlem, So how would you say it?
17:00:12 <coremodule> proposed #agreed 1626076 - AcceptedFreezeException (Beta) - We agree that it is important to pull in these fixes for the RasPi as they improve the overall user experience.
17:00:21 <Southern_Gentlem> +1
17:00:22 <pwhalen> ack
17:00:23 <Southern_Gentlem> ack
17:00:25 <cmurf> ack
17:00:31 <lruzicka> coremodule, thanks
17:00:33 <lruzicka> ack
17:00:35 <kalev> ack
17:00:40 <coremodule> #agreed 1626076 - AcceptedFreezeException (Beta) - We agree that it is important to pull in these fixes for the RasPi as they improve the overall user experience.
17:01:08 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1603511
17:02:01 <coremodule> lruzicka, not trying to steal your thunder... anyone know where we keep the Blocker meeting template?
17:02:20 <lruzicka> coremodule, yeah, https://qa.fedoraproject.org/blockerbugs/milestone/29/beta/irc
17:02:53 <lruzicka> coremodule, we do not want to discuss FTBFS bugs, I think
17:03:04 <lruzicka> so, we could continue with:
17:03:09 <coremodule> lruzicka, ah right.
17:03:12 <lruzicka> #topic (1600444) Wrong conflicts between dnf and yum prevents upgrade
17:03:12 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1600444
17:03:12 <lruzicka> #info Proposed Freeze Exceptions, dnf, NEW
17:03:48 <cmurf> +1 FE
17:03:53 <Southern_Gentlem> +1 fe
17:04:05 <coremodule> +1 FE
17:04:11 <lruzicka> +1FE
17:04:16 <kalev> +1 FE
17:06:59 <cmurf> --allowerasing is not a safe recommendation, pulling this in is the correct way to fix this
17:07:19 <coremodule> proposed #agreed 1600444- AcceptedFreezeException (Beta) - --allowerasing is not a safe recommendation, pulling this in is the correct way to fix this
17:07:28 <lruzicka> ack
17:07:45 <kalev> ack
17:07:51 * lruzicka has a little problem with proper formulations :)
17:07:58 <Southern_Gentlem> ack
17:08:02 <coremodule> #agreed 1600444- AcceptedFreezeException (Beta) - --allowerasing is not a safe recommendation, pulling this in is the correct way to fix this
17:08:19 <lruzicka> #topic (1624474) Missing icons in leave dialog and leave menu of panel
17:08:19 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624474
17:08:19 <lruzicka> #info Proposed Freeze Exceptions, fedora-icon-theme, NEW
17:08:24 <coremodule> lruzicka, if you run the meeting, I'll figure those out :)
17:08:30 <lruzicka> coremodule, ok
17:09:05 <Southern_Gentlem> +1 FE
17:09:14 <coremodule> +1 FE
17:09:17 <cmurf> +1 FE
17:09:21 <lruzicka> +1 FE
17:09:27 <kalev> +1 FE
17:09:58 <cmurf> The risk is on the LXQt folks, so I'm inclined to just handwave it through, sounds like a better experience overall (unless it breaks something)
17:10:24 <coremodule> proposed #agreed 1624474 - AcceptedFreezeException (Beta) - Having these icons in the lxqt menu affects the overall user experience and we don't imagine pulling this fix in will cause any problems, so we are voting to accept this bug as an AcceptedFreezeException.
17:10:33 <cmurf> ack
17:10:35 <lruzicka> ack
17:10:36 <Southern_Gentlem> ack
17:10:43 <coremodule> #agreed 1624474 - AcceptedFreezeException (Beta) - Having these icons in the lxqt menu affects the overall user experience and we don't imagine pulling this fix in will cause any problems, so we are voting to accept this bug as an AcceptedFreezeException.
17:10:55 <lruzicka> so, we are moving to
17:11:02 <lruzicka> #topic (1624292) Icons in Xfce menu are absurdly big
17:11:03 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624292
17:11:03 <lruzicka> #info Proposed Freeze Exceptions, garcon, ON_QA
17:11:16 <lruzicka> which is now the XFce desktop problem
17:11:24 <pwhalen> +1 FE
17:11:26 <Southern_Gentlem> +1 FE
17:11:44 <cmurf> +1 FE
17:11:49 <lruzicka> +1 FE
17:12:00 <cmurf> sounds like they have a fix already in u-t
17:12:03 <kalev> +1 FE
17:12:11 <lruzicka> ok, this makes thinks easier
17:12:21 <coremodule> proposed #agreed 1624292 - AcceptedFreezeException (Beta) - Having these icons in xfce the correct size affects the overall user experience and we don't imagine pulling this fix in will cause any problems, so we are voting to accept this bug as an AcceptedFreezeException.
17:12:22 <lruzicka> s/thinks/things
17:12:25 <Southern_Gentlem> ack
17:12:29 <lruzicka> ack
17:12:30 <pwhalen> ack
17:12:44 <coremodule> #agreed 1624474 - AcceptedFreezeException (Beta) - Having these icons in the lxqt menu affects the overall user experience and we don't imagine pulling this fix in will cause any problems, so we are voting to accept this bug as an AcceptedFreezeException.
17:12:49 <coremodule> whoops
17:12:51 <coremodule> #undo
17:12:51 <zodbot> Removing item from minutes: AGREED by coremodule at 17:12:44 : 1624474 - AcceptedFreezeException (Beta) - Having these icons in the lxqt menu affects the overall user experience and we don't imagine pulling this fix in will cause any problems, so we are voting to accept this bug as an AcceptedFreezeException.
17:12:58 <cmurf> whoops yeah
17:13:00 <coremodule> #agreed 1624292 - AcceptedFreezeException (Beta) - Having these icons in xfce the correct size affects the overall user experience and we don't imagine pulling this fix in will cause any problems, so we are voting to accept this bug as an AcceptedFreezeException.
17:13:06 <cmurf> there we go
17:13:09 <cmurf> ack
17:13:17 <kalev> ack
17:13:20 <lruzicka> yes, already acked :)
17:13:32 <lruzicka> #topic (1624743) Adding input method dialog broken in gnome-control-center
17:13:32 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1624743
17:13:32 <lruzicka> #info Proposed Freeze Exceptions, gnome-desktop3, NEW
17:14:20 <cmurf> ok I don't even see the reason for the FE request
17:14:41 <lruzicka> There is not, in that bug, right?
17:14:44 <cmurf> added as a freeze exception but no explanation why
17:15:04 <cmurf> I can't parse this request so I'm -1 FE unless someone can explain it
17:15:31 <lruzicka> Yes, I think the process should be kept intact ... without reasoning we do not know why
17:15:33 <coremodule> I think the reason is this "These inscript input methods are all for various Indian languages, the language is even shown at the beginning of  each line (in Japanese translation). So these
17:15:34 <coremodule> should not be listed under その他 ("other") but under the respective language.
17:15:42 <coremodule> but it is still vague
17:16:13 <coremodule> -1 FE until submitting user can validate *why* he thinks this bug deserves an FE
17:16:13 <lruzicka> I have seen a similar issue in English, though
17:16:15 <cmurf> Gotcha
17:16:30 <cmurf> and also how risky the fix is
17:16:43 <Southern_Gentlem> -1
17:17:08 <Southern_Gentlem> it may be fixed in the new gnome anyways
17:17:17 <cmurf> right *shrug* no idea
17:17:18 <lruzicka> the functionality is not broken though, it is just an annoying thing
17:17:27 <lruzicka> Southern_Gentlem, it may.
17:17:40 <coremodule> proposed #agreed 1624743 - RejectedFreezeException (Beta) - We can't seem to find an easy to understand reason as to why this was suggested as an FE. We will reconsider this bug if the submitting user can validate why he proposed this bug as an FE.
17:17:44 <cmurf> well in that case for sure -1 FE some times there are annoying things in beta
17:17:52 <cmurf> better than than a fix accidentally breaking something
17:17:56 <lruzicka> cm
17:17:59 <lruzicka> cmurf, yes
17:18:01 <lruzicka> ack
17:18:01 <Southern_Gentlem> ack
17:18:05 <cmurf> ack
17:18:08 <coremodule> #agreed 1624743 - RejectedFreezeException (Beta) - We can't seem to find an easy to understand reason as to why this was suggested as an FE. We will reconsider this bug if the submitting user can validate why he proposed this bug as an FE.
17:18:42 <lruzicka> Thank you, let's continue with this one:
17:18:43 <lruzicka> #topic (1625572) Gnome initial setup runs twice when installing from a Live ISO
17:18:43 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625572
17:18:43 <lruzicka> #info Proposed Freeze Exceptions, gnome-initial-setup, MODIFIED
17:19:03 <Southern_Gentlem> +1
17:19:29 <cmurf> i can't tell
17:19:38 <pwhalen> +1
17:19:48 <cmurf> but it looks like this update is in the megaupdate
17:19:54 <lruzicka> +1
17:19:56 <cmurf> s/update/fix
17:20:02 <Southern_Gentlem> cmurf,  we hope
17:20:24 <Southern_Gentlem> cmurf, at the moment no users can be created on the first boot
17:20:43 <cmurf> well that sounds like a blocker
17:20:50 <cmurf> we have to be able to add users in beta don't we?
17:20:58 <Southern_Gentlem> they have a fix so +1fe
17:21:13 <lruzicka> I reported this bug and I was able to create users during the installation.
17:21:43 <lruzicka> Actually, not during the installation, but the first time after gdm login.
17:21:52 <Southern_Gentlem> ok i am thinking different bug then
17:22:00 <lruzicka> cmurf, I have not seen any impossibility to create users.
17:22:16 <cmurf> well I'm wondering if the request is moot
17:22:26 <cmurf> kalev any idea if this fix is pulled in with the megaupdate?
17:22:50 <halfline> it is
17:22:57 <kalev> cmurf: yep, it is
17:23:20 <Southern_Gentlem> -1 then
17:23:31 <lruzicka> so? shall we reject and hope that it will sneak in?
17:24:05 <lruzicka> -1 providing that the fix will sneak in with the megaupdate
17:24:07 <cmurf> gdm-3.30.0-3.fc29  is in the megaupdate and the bug says fixed in -2 so
17:24:08 <cmurf> it's fixed
17:24:19 <cmurf> the megaupdate renders this FE request moot
17:24:39 <coremodule> -1 FE in that case
17:24:44 <coremodule> proposed #agreed 1625572 - RejectedFreezeException (Beta) - The behavior exhibited by gdm in this case is annoying and unnecessary, however a fix has been pushed through so we vote this bug as a RejectedFreezeException.
17:24:55 <lruzicka> ack
17:25:00 <Southern_Gentlem> ack
17:25:10 <cmurf> yeah the request is rendered moot by the megaupdate, which has been granted FE
17:26:20 <coremodule> one more ack?
17:26:23 <lruzicka> we need three acks
17:26:30 <Southern_Gentlem> ack
17:26:34 <lruzicka> :D
17:26:44 <kalev> ack
17:26:47 <coremodule> #agreed 1625572 - RejectedFreezeException (Beta) - The behavior exhibited by gdm in this case is annoying and unnecessary, however a fix has been pushed through so we vote this bug as a RejectedFreezeException.
17:27:14 <lruzicka> Great, this one is next:
17:27:24 <lruzicka> #topic (1625142) In Gnome Wayland, forward-key-event does not work well, breaks space key completely
17:27:24 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625142
17:27:24 <lruzicka> #info Proposed Freeze Exceptions, gnome-shell, NEW
17:27:45 <Southern_Gentlem> +1 punt
17:28:05 <cmurf> fix is probably in 3.30 also
17:28:10 <cmurf> if so this is also moot
17:28:17 <kalev> no, I don't think this is fixed in 3.30.0
17:28:37 <kalev> the fix hasn't landed upstream yet
17:28:54 <Southern_Gentlem> but does the problem exist in 3.3
17:28:57 <Southern_Gentlem> 0
17:29:12 <lruzicka> the merge request is still opened
17:29:31 * kalev nods.
17:29:43 <Southern_Gentlem> so FE or not
17:29:58 <cmurf> it's super annoying it sounds like
17:30:16 <Southern_Gentlem> it beta
17:30:21 <cmurf> i'm inclined to +1 this if it's tested and doesn't break anything else
17:30:36 <cmurf> what's the risk of accepting this kalev?
17:32:02 <cmurf> again no justification in the bug
17:32:14 <kalev> cmurf: I guess the fix could possibly break something else input module related :)
17:32:29 <cmurf> ok so -1 FE
17:32:31 <kalev> it's still being reviewed upstream and I'd like to wait until it lands upstream before backporting to fedora
17:32:38 <kalev> otherwise I don't mind a FE
17:32:52 <cmurf> and a fix will be brought in soon after
17:33:00 * kalev nods.
17:33:07 <lruzicka> ok, so -1 FE because the fix has not been approved yet.
17:34:05 <cmurf> "still being reviewed upstream, we consider it too risky this close to go no go" something like that
17:34:08 <lruzicka> coremodule?
17:34:21 <coremodule> proposed #agreed 1625142 - RejectedFreezeException (Beta) – As this fix is still being reviewed upstream and there is potential that it might break something else input-module related, we vote against this as a FreezeException.
17:34:33 <lruzicka> thanks
17:34:36 <lruzicka> ack
17:34:50 <pwhalen> ack
17:35:02 <cmurf> ack
17:35:07 <coremodule> #agreed 1625142 - RejectedFreezeException (Beta) – As this fix is still being reviewed upstream and there is potential that it might break something else input-module related, we vote against this as a FreezeException.
17:35:18 <lruzicka> Cool.
17:35:20 <lruzicka> #topic (1622312) golang 1.11 breaks snapd compilation on s390x
17:35:20 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1622312
17:35:20 <lruzicka> #info Proposed Freeze Exceptions, golang, MODIFIED
17:35:37 <cmurf> ok this reads like it's actually FTBFS even though the title doesn't contain that
17:35:55 <coremodule> agreed, it does seem that way
17:36:11 <cmurf> but there's a justification that's clear and sounds like a fix is even tested so I'm +1 FE
17:36:15 <cmurf> if we want to take it
17:36:54 <lruzicka> I do not know what exactly a s390x and how frequently it is used, but if it helps the users, I am for +1 FE.
17:37:00 <pwhalen> +1 FE
17:37:42 <cmurf> s390x is an arch, (IBM Z I think)
17:37:59 <coremodule> proposed #agreed 1622312 - AcceptedFreezeException (Beta) – This fix will help users build packages on the s390x arch, so we vote AcceptedFreezeException.
17:38:21 <cmurf> ack
17:38:23 <lruzicka> ack
17:38:30 <pwhalen> ack
17:38:31 <coremodule> #agreed 1622312 - AcceptedFreezeException (Beta) – This fix will help users build packages on the s390x arch, so we vote AcceptedFreezeException.
17:39:03 <lruzicka> #topic (1622353) kf5-libkdcraw Fails to upgrade from F28 to F29
17:39:03 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1622353
17:39:03 <lruzicka> #info Proposed Freeze Exceptions, kf5-libkdcraw, ON_QA
17:39:18 <cmurf> +1 FE
17:39:44 <lruzicka> +1 FE, the fix is there and known to be working
17:40:05 <pwhalen> +1 FE
17:40:22 <coremodule> proposed #agreed 1622353 - AcceptedFreezeException (Beta) – As there is a fix in place that is known to be working, we vote AcceptedFreezeException on this bug.
17:40:27 <pwhalen> ack
17:40:31 <cmurf> ack
17:40:32 <lruzicka> ack
17:40:34 <coremodule> #agreed 1622353 - AcceptedFreezeException (Beta) – As there is a fix in place that is known to be working, we vote AcceptedFreezeException on this bug.
17:40:42 <lruzicka> The next one should be easy.
17:40:49 <lruzicka> #topic (1626002) f29: MATE-Compiz beta spin needs f29-background
17:40:50 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626002
17:40:50 <lruzicka> #info Proposed Freeze Exceptions, mate-desktop, ON_QA
17:41:02 <lruzicka> +1 FE
17:41:04 <pwhalen> +1 FE
17:41:10 <cmurf> +1 FE
17:41:22 <coremodule> proposed #agreed 1626002 - AcceptedFreezeException (Beta) – This fix will add the F29 backgrounds to the Fedora MATE spin, so we vote AcceptedFreezeException.
17:41:28 <cmurf> very safe, and better experience to differentiate from F28 visually
17:41:35 <cmurf> ack
17:41:46 <pwhalen> ack
17:41:51 <lruzicka> ack
17:41:53 <coremodule> #agreed 1626002 - AcceptedFreezeException (Beta) – This fix will add the F29 backgrounds to the Fedora MATE spin, so we vote AcceptedFreezeException.
17:42:08 <lruzicka> The next one is this one:
17:42:15 <lruzicka> #topic (1625218) Fedora Workstation 29 takes a long time to boot in enforcing mode.
17:42:15 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625218
17:42:15 <lruzicka> #info Proposed Freeze Exceptions, selinux-policy, MODIFIED
17:42:35 <cmurf> hmm
17:42:52 <cmurf> I wonder if this is the slow boot cause adamw was talking about
17:43:16 <pwhalen> +1 FE
17:43:34 <lruzicka> I think it is. I tested this one three times and there is a significant difference with enforcing and permissive.
17:43:43 <cmurf> I'm likely +1 FE
17:43:45 <lruzicka> +1 FE,
17:43:48 <cmurf> there is a blocker request in this was that...
17:43:52 <coremodule> proposed #agreed 1625218 - AcceptedFreezeException (Beta) – The times required to boot without a fix for this bug severely inhibit the use of F29 in this case. As such we vote that this bug warrants an AcceptedFreezeException status.
17:43:59 <cmurf> ahh i see it
17:44:02 <cmurf> yeah +1 FE
17:44:09 <pwhalen> ack
17:44:13 <cmurf> improves user experience with low risk
17:44:16 <cmurf> ack
17:44:17 <lruzicka> the blocker is for final, though
17:44:25 <cmurf> gotcha
17:44:48 <coremodule> one more ack
17:44:51 <lruzicka> ack
17:44:53 <coremodule> #agreed 1625218 - AcceptedFreezeException (Beta) – The times required to boot without a fix for this bug severely inhibit the use of F29 in this case. As such we vote that this bug warrants an AcceptedFreezeException status.
17:45:11 <lruzicka> #topic (1626839) No default editor in Fedora 29 LXQt LiveCD
17:45:11 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626839
17:45:11 <lruzicka> #info Proposed Freeze Exceptions, spin-kickstarts, NEW
17:45:28 <cmurf> I agree with this, although I'm not sure who are the LXQt owners.
17:45:31 <cmurf> Do they want it?
17:45:42 <lruzicka> Would they file a bug if they did not?
17:46:09 <Pharaoh_Atem> Zamir SUN is a member of the LXQt SIG
17:46:15 <cmurf> Could just be a user who filed the request - I don't know everybody
17:46:16 <lruzicka> I, personally, would support an idea that each spin should have some amount of default apps readcy
17:46:16 <cmurf> ahhh OK
17:46:18 <lruzicka> ready
17:46:19 <cmurf> +1 FE
17:46:28 <pwhalen> +1 as well
17:46:31 <lruzicka> +1 FE
17:47:04 <coremodule> proposed #agreed 1626839 - AcceptedFreezeException (Beta) – Having a default editor in the LXQt spin is essential for a good user experience and as such we vote AcceptedFreezeException.
17:47:11 <lruzicka> ack
17:47:45 <pwhalen> ack
17:48:11 <coremodule> ack/nack/patch?
17:48:14 <cmurf> ack
17:48:17 <cmurf> sorry
17:48:17 <coremodule> #agreed 1626839 - AcceptedFreezeException (Beta) – Having a default editor in the LXQt spin is essential for a good user experience and as such we vote AcceptedFreezeException.
17:48:20 <lruzicka> #info We have now covered all proposed freeze exceptions except those marked as FTBFS.
17:48:43 <cmurf> yep
17:48:47 <lruzicka> Shall we vote for the FTBFS bugs as a batch?
17:48:59 <cmurf> was going to leave that to adamw but we can
17:49:13 <cmurf> we can come up with a proposal and +1 it
17:49:26 <cmurf> that way it's got the votes and is legit
17:49:47 <coremodule> standby for proposal
17:50:01 <cmurf> I think he was going to go through them and FE only the ones that are blocking updates, so it's possible not all of them get FE, I'm not really sure
17:50:12 <coremodule> hmmm, should we wait then?
17:50:23 <cmurf> scrolling up to see what he said
17:51:45 <lruzicka> i am gonna further suggest that, when we get there, we do a block vote on proposed FEs of a certain kind: packages that were FTBFS and have dependency issues that can affect upgrades, and don't seem to have any other complications
17:51:57 <lruzicka> this is what he said
17:51:59 <cmurf> "block vote on simple upgrade-affecting FTBFSes"
17:52:55 <coremodule> how to qualify which are upgrade-affecting without looking individually at each bug?
17:53:03 <coremodule> *how do we qualify
17:53:05 <pwhalen> right
17:53:06 <cmurf> "We agree adamw can accept for freeze exception any simple upgrade-affecting FTBFSes as he determines." :P
17:53:22 <coremodule> hahaha he would love it
17:53:24 <pwhalen> heh
17:53:55 <cmurf> could add "per his benevolent review" for further amusement
17:53:57 <coremodule> or a blanket statement that we accept ALL FTBFS bugs?
17:53:58 <lruzicka> or we can just visit them quickly, they are like 102
17:53:59 <lruzicka> 10
17:54:23 <cmurf> no i'd rather do a quick review of the three approved blockers for status and if any need help or push
17:54:45 <coremodule> lruzicka, Am all for it, I have to go at 15 past the next hour so if we push that time, I will have to pass the proposal duty to someone else...
17:55:06 * cmurf wants blockers off the board, he's ready for U.S.S. Ship It to set sail
17:55:34 <coremodule> *makes hang loose sign with hand* ship it dude
17:56:37 <cmurf> ship it, it's a beta!
17:56:55 <lruzicka> ok, so we batch accept them then
17:57:29 <cmurf> I actually wasn't kidding with my earlier quote...
17:57:39 <cmurf> just propose that and I'll ack it
17:57:46 <lruzicka> lets do it
17:58:00 <cmurf> it's funny but i'm also serious
17:58:05 <coremodule> proposed #agreed “all FTBFS bugs” - AcceptedFreezeException (Beta) – As these bugs are all FTBFS bugs, we batch accept them all in favor of shipping the Beta on time.
17:58:15 <lruzicka> ack
17:58:21 <coremodule> cmurf, or the adamw one specifically/
17:58:21 <cmurf> ack
17:58:22 <coremodule> ?
17:58:33 <cmurf> the adamw one specifically
17:58:59 <cmurf> I will ack either one.
17:59:03 <coremodule> proposed #agreed “all FTBFS bugs” - AcceptedFreezeException (Beta) – As these bugs are all FTBFS bugs, we batch accept them all in favor of shipping the Beta on time. We also delegate proper authority to adamw to modify the status of any of these bugs as he sees fit.
17:59:14 <cmurf> ack
17:59:15 <lruzicka> seems reasonable, ack
17:59:31 <coremodule> ack/nack/patch - just one more...
17:59:34 <pwhalen> ack
18:00:06 <coremodule> changed one thing...
18:00:07 <coremodule> proposed #agreed “all FTBFS F29 Beta bugs” - AcceptedFreezeException (Beta) – As these bugs are all FTBFS bugs, we batch accept them all in favor of shipping the Beta on time. We also delegate proper authority to adamw to modify the status of any of these bugs as he sees fit.
18:00:16 <lruzicka> Ok, thank you very much.
18:00:18 <coremodule> just specified *which* FTBFS bugs
18:00:26 <coremodule> #agreed “all FTBFS F29 Beta bugs” - AcceptedFreezeException (Beta) – As these bugs are all FTBFS bugs, we batch accept them all in favor of shipping the Beta on time. We also delegate proper authority to adamw to modify the status of any of these bugs as he sees fit.
18:00:45 <cmurf> super
18:00:47 <lruzicka> #topic Accepted Blockers review
18:00:56 * adamw back
18:01:10 <cmurf> we can skip that, we've covered it
18:01:12 <coremodule> hows the kitty?
18:01:21 <adamw> oh, she's okay
18:01:29 <adamw> thanks
18:01:32 <coremodule> that's good
18:01:33 * pwhalen is happy to hear that
18:01:59 <lruzicka> nice to hear it
18:02:08 <lruzicka> #topic Open discussion
18:02:20 <lruzicka> Do you have anything you would like to add?
18:02:38 <lruzicka> Do you need quick info on the process, adamw
18:02:39 <lruzicka> ?
18:02:49 <adamw> nah, i'll read the logs.
18:02:53 <adamw> did you do accepted blocker review or no?
18:03:01 <cmurf> we just started that
18:03:20 <cmurf> not even on the first bug, which I think is 1596540
18:03:33 <lruzicka> yes
18:03:45 <cmurf> and it's a doozy, kinda long and I don't grok it at all
18:03:51 <lruzicka> we wanted to see, if some of them need a push or something
18:03:57 <cmurf> exactly
18:04:36 <coremodule> As secretary, I want to note that I have a home inspection scheduled in one hour (1900UTC), and as such I will be late by several hours posting the secretarializations to bugzilla.
18:04:56 <cmurf> let's change topic to 1596540?
18:05:20 <lruzicka> #topic (1596540) RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline
18:05:20 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1596540
18:05:20 <lruzicka> #info Accepted Blocker, dnf, ASSIGNED
18:05:49 <cmurf> is this the f29 dnf is puking on old f28 dnf history bug?
18:06:29 <cmurf> adamw?
18:07:20 <adamw> sorry
18:07:28 <adamw> it's one of those, yes
18:07:47 <adamw> coremodule: OK, i may do it then, as i need the statuses updates to do push requests
18:08:11 <adamw> so this is the one where dmach said it'd get fixed 'asap'
18:08:11 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1596540#c30
18:08:25 <adamw> ...two weeks ago
18:08:32 <cmurf> right
18:08:58 <adamw> #info there is a clear reproducer for this and dnf team committed to fixing it 'asap' two weeks ago, but there is no update on a fix since then
18:09:05 <lruzicka> Yeah, but the next comment does not look optimistic
18:09:15 <cmurf> it'd be a drag to block on this...
18:09:32 <cmurf> we have no idea what % of people run into it do we?
18:09:37 <adamw> well
18:09:49 <lruzicka> the fix is to delete and recreate the backing database, right?
18:09:50 <adamw> right around when dnf 3 landed, we had quite a lot of people report similar issues after updating, remember
18:10:02 <adamw> dnf would crash, and wiping/renaming the history db 'fixes' it
18:10:06 <adamw> i am not sure you get to 'recreate' it
18:10:18 <adamw> i think if you move it you just...lose your history
18:10:20 <lruzicka> adamw, sorry, I meant have it created anew
18:10:24 <adamw> but i'm not 100% sure on that
18:10:25 <cmurf> i don't want to block on something with that kind of work around for a beta
18:10:40 <adamw> i dunno, i don't think 'i upgraded and now dnf crashes when i do anything' is a great look
18:10:48 <cmurf> haha
18:11:02 <lruzicka> adamw, we could write it into known issues
18:11:03 <cmurf> i do like how you zero in
18:11:05 <adamw> for now...
18:11:17 <adamw> #action adamw to check with dnf team on status of this and dnf in general
18:11:34 <adamw> sgallagh: maxamillion: mattdm: any idea if fesco has concerns on this?
18:11:54 <sgallagh> Hasn't come to FESCo
18:11:55 <cmurf> ok so i propose an agressive what is the status of this bug and how do they feel about *not* blocking on it and potentially getting a lot of "i upgraded to beta and now dnf crashes when I do anything"
18:12:18 <lruzicka> adamw, the next dnf bug is also tough
18:12:25 <sgallagh> FWIW, I've been running on F29 with u-t on my primary system and haven't seen this
18:12:42 <lruzicka> adamw, maybe that one should go to FESCo
18:12:46 <cmurf> sgallagh: clean install or upgrade?
18:13:13 <sgallagh> upgrade from F28
18:13:40 <lruzicka> sgallagh, cmurf: when I upgraded, 2 weeks ago, I did not see it either
18:13:45 <sgallagh> (well, this machine started on F26, IIRC, but it's been upgraded through each in sequence)
18:14:03 <Southern_Gentlem> let me see what happens in a VM
18:14:33 <Southern_Gentlem> any DE preferences?
18:14:39 <cmurf> I'm a weak -1 blocker on 1596540
18:15:20 <cmurf> and even FE if they had a fix, it's like, what are the chances a fix breaks something? dnf is making me feel like walking on eggshells
18:15:31 <adamw> it's already voted as a blocker, we're not revoting at present unless someone wants to propose we do (i'm not right now)
18:15:40 <cmurf> ok
18:15:47 <adamw> we're reviewing the status..
18:16:01 <cmurf> ok so let's get an update and then move on
18:16:04 <adamw> ...and the status appears to be 'dnf team didn't get to it'. so, that's where we're at, and i action'ed myself to follow up on that
18:16:06 <adamw> yeah.
18:16:17 <adamw> not sure we can do a lot more. we always have the option to re-vote at go/no-go.
18:16:34 <adamw> i can also send out a test request mail around the topic, i guess.
18:16:36 <adamw> alright, so
18:16:51 <cmurf> 1616167?
18:16:53 <adamw> yeah
18:16:55 <lruzicka> #topic (1616167) dnf doesn't record modular metadata in a local database
18:16:55 <adamw> i'll go ahead and chair again
18:16:55 <lruzicka> #link https://bugzilla.redhat.com/show_bug.cgi?id=1616167
18:16:55 <lruzicka> #info Accepted Blocker, dnf, NEW
18:17:00 <adamw> or lruzicka's got it :P
18:17:04 <lruzicka> ok, it is yours now
18:17:04 <cmurf> based on c10, I'd like to revote
18:17:08 <adamw> so, we *should* kick this one off the list
18:17:23 <adamw> yup
18:17:28 <cmurf> +1 kick it off the list
18:17:32 <adamw> i don't think we have to revote, as fesco trumps us
18:17:37 <adamw> so we can go straight to proposed
18:17:39 <cmurf> gotcha
18:17:49 <lruzicka> +1 kick off
18:18:21 <cmurf> we need a proposal
18:18:31 <adamw> proposed #agreed 1616167 - RejectedBlocker (Beta) - per FESCo's decision in https://pagure.io/fesco/issue/1974 , this bug should no longer block Beta. it should be made a proposed blocker for Final for now.
18:18:36 <cmurf> ack
18:18:38 <lruzicka> ack
18:18:42 <sgallagh> ack
18:18:44 <mboddu> ack
18:19:20 * mboddu is kinda here now - after fixing the container release :)
18:19:25 <pwhalen> ack
18:19:39 <cmurf> 1615969?
18:19:59 <lruzicka> #agreed 1616167 - RejectedBlocker (Beta) - per FESCo's decision in https://pagure.io/fesco/issue/1974 , this bug should no longer block Beta. it should be made a proposed blocker for Final for now.
18:20:11 <lruzicka> #agreed 1616167 - RejectedBlocker (Beta) - per FESCo's decision in https://pagure.io/fesco/issue/1974 , this bug should no longer block Beta. it should be made a proposed blocker for Final for now.
18:20:22 * lruzicka passing chair to adamw
18:20:26 <adamw> #topic (1615969) AArch64 - Error when booting "error: out of memory."
18:20:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1615969
18:20:26 <adamw> #info Accepted Blocker, grub2, VERIFIED
18:20:37 <adamw> so, this one is basically hung up on the rest of the grub drama
18:20:48 <adamw> i guess we could technically close it for now, as we sent -54 stable, right?
18:20:55 <cmurf> right
18:21:05 <adamw> but i think it may be better to keep it open as a reminder that this is the blocker we need to fix compared to -51
18:21:22 <adamw> while we try to figure out what to do with the remaining x86_64 UEFI boot issue...
18:21:43 <cmurf> -54 has a -1 karma right now in testing
18:22:13 <cmurf> oh that's inheriting karma from previous sub versions or whatever they're called
18:22:21 <adamw> oh. uh. it's still not stable? man, i had lost track of where we were.
18:22:42 <pwhalen> yea, didnt think it made it to stable
18:22:49 <cmurf> bodhi comment "For me 2.02-54 still breaks the boot on my thinkpad x220"
18:23:29 <adamw> ok, so, this is useful data for the other bugs
18:23:33 <adamw> i will chew through it in a bit
18:23:54 <pwhalen> I have an x220 as well, so I can help test the fix (when we get it) on both aarch64 and x86
18:23:55 <adamw> sounds like pbrobinson has another system with the 'boots to grub menu' result, which could be useful for debugging...
18:24:09 <adamw> pwhalen: can you confirm the x220 is broken with -54?
18:24:10 <cmurf> yes
18:24:18 <cmurf> "fails on my Intel based UP² board"
18:24:21 <pwhalen> I can try that too, ues
18:24:25 <pwhalen> *yes
18:24:38 <adamw> pwhalen: does it look to be the same as https://bugzilla.redhat.com/show_bug.cgi?id=1626844 ? if so, can you comment there and provide the info cmurf asked for?
18:24:38 <cmurf> darn
18:25:20 <cmurf> i have a strong feeling that what I asked for won't actually help based on all these descriptions
18:25:29 <pwhalen> will need to get my x220 up, will comment in the bz
18:25:35 <adamw> #info this bug was fixed in grub2 -52, but we still have continuing fallout from the changes made it that build and its successors on x86_64 (especially #1626844). we are continuing to try and figure out a grub build that resolves this blocker while not regressing anything on x86_64 UEFI
18:25:40 <adamw> #undo
18:25:40 <zodbot> Removing item from minutes: INFO by adamw at 18:25:35 : this bug was fixed in grub2 -52, but we still have continuing fallout from the changes made it that build and its successors on x86_64 (especially #1626844). we are continuing to try and figure out a grub build that resolves this blocker while not regressing anything on x86_64 UEFI
18:25:47 <adamw> #info this bug was fixed in grub2 -52, but we still have continuing fallout from the changes made in that build and its successors on x86_64 (especially #1626844). we are continuing to try and figure out a grub build that resolves this blocker while not regressing anything on x86_64 UEFI
18:25:51 <adamw> pwhalen: thanks a lot
18:25:59 <adamw> cmurf: then ask for something else :P
18:26:00 <pwhalen> np :)
18:26:04 <adamw> ask for whatever you can think of! :P
18:26:07 <pwhalen> heh
18:26:14 <cmurf> i can't think of anything
18:26:27 <cmurf> normally getting to a grub prompt on UEFI means it can't find the grub.cfg
18:26:37 <cmurf> so maybe it's looking in the wrong place, like the grub root is wrong
18:26:49 <cmurf> 'set' would show us that but I have no idea how to fix it
18:27:32 <cmurf> it's not like it can't read the file system, the firmware is doing that, this is FAT in all cases
18:28:02 <cmurf> ¯\_(ツ)_/¯
18:29:02 * adamw is inclined to try a scratch build of -51 plus "Better allocation of kernel+initramfs" and *nothing else*
18:29:07 <adamw> grr
18:29:08 <adamw> not that one
18:29:22 <adamw> "Fix AArch64 machines with no RAM latched lower than 1GB"
18:29:31 <adamw> okay, so, that's where we are, basically
18:29:38 <adamw> #topic Open floor
18:29:44 <adamw> anything else, folks? thanks a lot for making it this far
18:29:51 <lruzicka> not from me
18:30:01 * pwhalen has nothing else
18:30:36 <coremodule> nothing here
18:30:46 <cmurf> super
18:30:49 <cmurf> good work
18:31:11 <lruzicka> thank you, everyone, for your patience
18:31:28 <lruzicka> and thank you, coremodule, for the language
18:32:06 <adamw> alrighty, time for lunch, drinking or lunchtime drinking
18:32:07 <coremodule> lruzicka, no problem! :) thanks for taking over lruzicka
18:32:11 <adamw> thanks again folks :P
18:32:13 <adamw> #endmeeting