16:00:11 <adamw> #startmeeting F29-blocker-review
16:00:11 <zodbot> Meeting started Mon Oct 15 16:00:11 2018 UTC.
16:00:11 <zodbot> This meeting is logged and archived in a public location.
16:00:11 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:11 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:00:12 <adamw> #meetingname F29-blocker-review
16:00:12 <adamw> #topic Roll Call
16:00:12 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:00:22 <adamw> ahoyhoy folks, who's around for f29 final blocker review times?
16:00:43 * kparal is here for the party
16:00:46 <frantisekz> .helloě
16:00:53 <frantisekz> .hello2
16:00:54 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:00:58 * kparal looks around. no balloons?
16:00:59 * jlanda is on a train trip as usual :D
16:01:26 <sgallagh> .hello2
16:01:27 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:35 * coremodule is back, ready to secretarialize!
16:01:53 * coremodule hopes kparal brought drinks for the party... :)
16:02:17 * kparal hands out NA beer to everyone
16:02:33 <adamw> .fire kparal
16:02:33 <zodbot> adamw fires kparal
16:02:45 <bcotton> .hello2
16:02:46 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:50 * kparal drinks up
16:03:11 <contyk> o hai
16:03:17 <sgallagh> I am certain this will be an entirely uneventful meeting!
16:03:17 <contyk> .hello psabata
16:03:18 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
16:03:22 * mboddu will be here in few
16:04:05 <Southern_Gentlem> .hello jbwillia
16:04:08 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:04:57 * pwhalen is here
16:05:07 <kparal> adamw: it might be a good idea to talk about your PTO and the arrangements as the first thing, before people fall asleep during the meeting
16:05:07 * zbyszek is here
16:05:23 <adamw> sure, probably worth mentioning
16:05:28 <adamw> i'm gonna be on vacation the next two weeks
16:05:37 <zbyszek> noooooo
16:05:39 <kparal> starting tomorrow?
16:05:45 <adamw> starting in about three hours
16:05:53 <pwhalen> yikes
16:06:15 <kparal> ok, who's going to handle all the usual requests?
16:06:30 <adamw> uh, hadn't someone already volunteered for that?
16:06:36 * pwhalen points at kparal
16:06:44 <kparal> adamw: you tell me
16:06:55 <adamw> well i kinda thought they had, but now i don't have a record of it
16:07:05 <kparal> alright. then...
16:07:14 * kparal looks at frantisekz and coremodule
16:07:28 <adamw> who's done it before?
16:07:30 <frantisekz> kparal volunteers?
16:07:32 <kparal> pschindl
16:07:33 <frantisekz> :)
16:07:39 <adamw> ah.
16:07:42 <adamw> thought someone else had?
16:07:43 <kparal> and me, of course :)
16:08:06 <coremodule> What, for secretary duty? I'm all in!
16:08:25 <adamw> blocker bug herding, compose requests, stable push requests
16:08:27 <kparal> coremodule: nope, all the release process stuff. requesting RCs, updates going stable, etc
16:08:32 <adamw> sorry, i really thought we'd already done this. sigh
16:08:37 <adamw> been a bit messy around here lately
16:09:09 <coremodule> If someone could give a bit of direction, I'll do what I can to take over that stuff in the meantime...
16:09:25 <adamw> let's put you and frantisekz in the line of fire for now
16:09:32 <adamw> i'll send you a quick mail with instructions in a bit
16:09:36 <kparal> I can advise you with what I know
16:09:37 <frantisekz> okay
16:09:45 <coremodule> adamw, sounds good to me!
16:09:52 <adamw> sorry we didn't sort this out earlier...
16:09:54 <adamw> alrighty
16:09:58 <adamw> moving on with the meeting
16:10:38 <adamw> #chair coremodule bcotton
16:10:38 <zodbot> Current chairs: adamw bcotton coremodule
16:10:45 <adamw> #topic Introduction
16:10:45 <adamw> Why are we here?
16:10:45 <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:10:45 <adamw> #info We'll be following the process outlined at:
16:10:47 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:10:47 <adamw> #info The bugs up for review today are available at:
16:10:50 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:10:51 <adamw> #info The criteria for release blocking bugs can be found at:
16:10:53 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:10:57 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:10:59 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:11:01 <adamw> we have:
16:11:03 <adamw> #info 7 Proposed Blockers
16:11:05 <adamw> #info 5 Accepted Blockers
16:11:07 <adamw> #info 4 Proposed Freeze Exceptions
16:11:09 <adamw> #info 7 Accepted Freeze Exceptions
16:11:11 <adamw> and
16:11:13 <adamw> #info coremodule will secretarializie
16:11:15 <adamw> whoops, spelled my own made-up word wrong
16:11:44 <sgallagh> heh
16:12:34 <adamw> #info starting with proposed blockers
16:12:41 <adamw> #topic (1637927) iSCSI Reverse CHAP authentication not working
16:12:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637927
16:12:41 <adamw> #info Proposed Blocker, iscsi-initiator-utils, NEW
16:12:49 <adamw> we're doing this one first at vtrefny's request
16:12:51 <adamw> ahoy, vtrefny
16:12:55 <vtrefny> hi
16:13:04 * kparal finally learned that it's a made-up word and now feels no shame in spelling it wrong every time
16:13:15 <coremodule> lol
16:14:19 <adamw> kparal: be aware that anyone else spelling it wrong is a firable offense
16:14:22 <adamw> and the spelling changes daily
16:14:44 <adamw> vtrefny: so, you have any thoughts on this one? i guess the question is just how many affected configs are there now
16:14:52 <adamw> what's the difference between the config we have that works and the one that breaks?
16:14:58 <vtrefny> so basically we had an accepted blocker for this for anaconda/blivet, there actually was a bug in blivet -- we were calling the iscsi tools completely wrong and mutual authentication didn't work at all, that is now fixed, but it still doesn't work with some configuration -- I was able to reproduce it manually with iscsiadm so this time the bug is not in the installer
16:15:41 <zbyszek> The same considerations apply to the clone as to the original bug
16:16:46 <vtrefny> there are some differences in the config, but it's mostly some advanced configuration I don't understand, the authentication configuration looks the same to me
16:17:02 <adamw> hmm
16:17:14 <adamw> it's a bit hard to judge without knowing how many configs it's going to affect :/
16:17:36 <adamw> i suspect it'd fail the 'last blocker' test at this point though, if the initial installer side bug is fixed
16:18:15 <vtrefny> btw. the mutual chap auth was broken for at least 2 years and no one noticed
16:19:17 <sgallagh> Yeah, unless we can demonstrate it's likely to hit a large subset of iSCSI users (already a very small percentage of folks in Fedora-land), I'm -1 blocker here
16:19:31 <sgallagh> But I'd be willing to look at it for FE if a solution is found.
16:19:45 <adamw> vtrefny: see? we're getting better :P
16:20:06 <adamw> vtrefny: the openQA test only does discovery auth, iirc. i've made a note to look at improving it
16:20:22 <coremodule> based on the above and sgallagh's sound reasoning, I'm partial to a -1 blocker, +1 FE as well
16:20:24 <Southern_Gentlem> +1 fe -1 blocker
16:20:37 <frantisekz> -1 blocker, +1 FE
16:20:56 <lruzicka> .hello lruzicka
16:20:57 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:21:22 <pwhalen> -1 blocker, +1 FE
16:21:28 <bcotton> -1 blocker, +1 FE
16:21:38 <zbyszek> -1 bl, +1 fe too
16:21:44 <adamw> proposed #agreed 1637927 - RejectedBlocker AcceptedFreezeException (Final) - we believe enough iSCSI configs now work that this remaining problematic one should not be considered a blocker, but it would be great to fix it for the release if we can
16:21:52 <bcotton> ack
16:21:52 <coremodule> ack
16:21:54 <contyk> ack
16:21:57 <sgallagh> ack
16:22:02 <frantisekz> ack
16:22:06 <kparal> ack
16:22:08 <Southern_Gentlem> ack
16:22:39 <kparal> coremodule: I think this would make sense to mark as a commonbug instead
16:22:54 <Southern_Gentlem> as well
16:23:09 <coremodule> can do
16:23:09 <pwhalen> ack
16:23:14 <adamw> #agreed 1637927 - RejectedBlocker AcceptedFreezeException (Final) - we believe enough iSCSI configs now work that this remaining problematic one should not be considered a blocker, but it would be great to fix it for the release if we can
16:23:22 <adamw> #topic (1636743) dnf update --refresh fails for repo_gpgcheck=1
16:23:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1636743
16:23:22 <adamw> #info Proposed Blocker, dnf, MODIFIED
16:23:41 <adamw> if this doesn't affect any out-of-the-box config it probably doesn't need to be a blocker...
16:25:01 <kparal> the title is confusing
16:25:06 <kparal> I'll update it
16:25:32 <frantisekz> but looks like there's a patch, so -1 blocker, +1 FE ?
16:25:33 <kparal> this is about mirrorlist content (not url) not being able to use $releasever and $arch values
16:25:46 <kparal> yeah, I'd go +1 FE
16:25:50 <lruzicka> I do not know what unitedrpms repo is.
16:26:03 <kparal> lruzicka: doesn't really matter. something like rpmfusion I think
16:26:10 <kparal> but it broke their setup
16:26:20 <adamw> uh
16:26:25 <adamw> don't we have a different bug for that?
16:26:33 <adamw> 1637148 ?
16:26:36 <adamw> are they dupes?
16:26:39 <cmurf> sorry late, got spacy trying to figure out datetime stamps in files (what a mess)
16:26:40 <lruzicka> yes, but isn't that their problem to fix the gpgs?
16:27:02 <frantisekz> also, dmach talked today with me and said we shouldn't be scared from dnf 4 , as it's basically dnf 3.7
16:27:06 <sgallagh> I'm definitely -1 blocker on this.
16:27:31 <kparal> ouch, I just noticed this bug isn't the one I thought
16:27:39 <lruzicka> -1 blocker, seems to me
16:27:46 <sgallagh> I'm actually not sure I'd want to go FE here, since every new DNF release introduces at least as many issues as it solves :-/
16:27:47 <kparal> ok, I'll need to read this one better
16:27:52 <zbyszek> Yeah, 1636743 and 1637148 are different things
16:28:03 <adamw> frantisekz: yeah, i've read the commit log, i'm not 100% convinced. but anyway
16:28:07 <frantisekz> :D
16:28:08 <sgallagh> I guess I'd be +1 FE if-and-only-if this came in as a backported patch and not a rebase.
16:28:08 <adamw> i'm planning to bring that up in open floor
16:28:26 <zbyszek> sgallagh: it's a one line (one word really) patch
16:28:29 <adamw> sgallagh: they already want us to take a rebase
16:28:38 * sgallagh sighs
16:28:38 <jlanda> for f29?
16:28:42 <jlanda> now?
16:28:44 <adamw> sgallagh: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
16:28:47 <adamw> i'm planning to discuss that later
16:28:49 <jlanda> omg
16:28:55 <jlanda> oh, ok, sorry
16:29:15 <adamw> if the fix for this is simple, i guess fe is ok
16:29:17 <adamw> so i'm -1 blocker +1 fe
16:29:24 <sgallagh> yeah, pk -1 blocker +1 fe
16:29:25 <lruzicka> -1 blocker, +1 fe
16:29:45 <bcotton> -1 blocker, +1 fe
16:29:50 <frantisekz> -1 blocker, +1 fe
16:29:51 <zbyszek> -1 bl, +1 fe
16:30:28 <pwhalen> -1 blocker, +1 fe
16:31:12 <Southern_Gentlem> +fe
16:31:45 <adamw> proposed #agreed 1636743 - RejectedBlocker AcceptedFreezeException (Final) - this is not believed to affect any official / out-of-the-box repositories and thus does not break any release criteria. As the fix is said to be simple and could benefit some folks on first boot, it is accepted as a freeze exception
16:31:50 <kparal> hmm, this actually looks like a bigger problem than the other unitedrpms bug
16:31:53 <frantisekz> ack
16:31:59 <contyk> ack
16:32:06 <sgallagh> ack
16:32:06 <jlanda> ack
16:32:13 <kparal> ack I guess
16:32:15 <lruzicka> ack
16:32:15 <bcotton> ack
16:32:32 <Southern_Gentlem> ack
16:32:48 <frantisekz> no place for guessing kparal, you must feel it...in your heart :)
16:32:49 <kparal> coremodule: also good to commonbug this
16:33:01 <adamw> #agreed 1636743 - RejectedBlocker AcceptedFreezeException (Final) - this is not believed to affect any official / out-of-the-box repositories and thus does not break any release criteria. As the fix is said to be simple and could benefit some folks on first boot, it is accepted as a freeze exception
16:33:11 <coremodule> kparal, roger!
16:33:12 <kparal> frantisekz: my heart "blocks", you know that
16:33:13 <adamw> #topic (1637148) dnf doesn't resolve variables in mirrorlists
16:33:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637148
16:33:14 <adamw> #info Proposed Blocker, dnf, ASSIGNED
16:33:17 <adamw> this is the one kparal was thinking of
16:33:24 <kparal> yep
16:33:27 <kparal> sorry for confusion
16:33:39 <adamw> this seems to be a case where some repos were relying on a behaviour in dnf that probably wasn't necessarily intended or known about...
16:34:12 <kparal> not sure if this was a documented behavior or not. again doesn't affect official repos, though
16:34:14 <sgallagh> I'm -1 blocker on this as well. It doesn't affect any of the Fedora repos
16:34:39 <kparal> probably should get the same treatment as the previous bug
16:34:50 <cmurf> -1 blocker
16:34:57 <frantisekz> -1 blocker, +1 FE (although the fix is not merged and released yet....)
16:35:01 <jlanda> yep, -1 bl +1 fe
16:35:10 <cmurf> well and what is the fix?
16:35:11 <pwhalen> -1 blocker
16:35:13 <lruzicka> I agree with sgallagh. If it does not affect our repos, then we should not block on that.
16:35:14 <contyk> -1 blocker, +1 fe
16:35:22 <lruzicka> -1 blocker, +1 fe
16:35:24 <adamw> yup, samr vote for me too
16:35:33 <frantisekz> cmurf, https://github.com/rpm-software-management/dnf/pull/1244 seems like
16:35:51 <Southern_Gentlem> +1fe -1 b
16:36:24 <adamw> proposed #agreed 1637148 - RejectedBlocker AcceptedFreezeException (Final) - this is not believed to affect any official / out-of-the-box repositories and thus does not break any release criteria. As this could benefit some folks on first boot, it is accepted as a freeze exception if the fix is simple and testable
16:36:28 <cmurf> ack
16:36:34 <coremodule> ack
16:36:35 <jlanda> ack
16:36:36 <contyk> ack
16:36:39 <lruzicka> ack
16:36:40 <Southern_Gentlem> ack
16:36:52 <kparal> ack
16:37:05 <sgallagh> ackity ack
16:37:24 <pwhalen> ack
16:37:30 <frantisekz> ack
16:37:48 <adamw> #agreed 1637148 - RejectedBlocker AcceptedFreezeException (Final) - this is not believed to affect any official / out-of-the-box repositories and thus does not break any release criteria. As this could benefit some folks on first boot, it is accepted as a freeze exception if the fix is simple and testable
16:37:55 <adamw> #topic (1637418) Switching keyboard layouts is not working without relogin/reboot
16:37:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637418
16:37:55 <adamw> #info Proposed Blocker, gnome-control-center, NEW
16:38:09 <adamw> this doesn't really violate any criteria, for me, and the workaround - just reboot - isn't exactly awful
16:38:42 <lruzicka> maybe a common bug then?
16:38:45 <cmurf> definitely suboptimal behavior
16:38:50 <frantisekz> -1 blocker, +1 FE, and common bug for sure
16:38:56 <adamw> lruzicka: sure.
16:38:59 <cmurf> yeah
16:39:02 <pwhalen> -1 blocker, +1 FE
16:39:05 <cmurf> -1 blocker, +1 FE
16:39:11 <sgallagh> Yeah, I'm in the same boat. They should probably have selected the preferred keyboard in the installer anyway.
16:39:11 <Southern_Gentlem> -1 B +fe +1cb
16:39:12 <lruzicka> -1 blocker, +1 fe
16:39:15 <sgallagh> -1 Blocker, +1 FE
16:39:20 <contyk> that's horrible
16:39:28 <kparal> isn't this basic functionality?
16:39:32 <kparal> of the panel?
16:39:39 <contyk> I switch layouts all the time; can't imagine suffering from this
16:39:41 <lruzicka> sgallagh, so it's their fault that it does not work :D
16:40:12 <kparal> the problem is not that you need to reboot. the problem is that you don't know it, because everything looks normal. just characters don't print out as you expect
16:40:13 <lruzicka> contyk, it only affects the session in which you add the new layout. It works fine after reboot.
16:40:22 <kparal> I'd honestly consider this rather blocking
16:40:38 <contyk> lruzicka: ah, hm
16:40:40 <sgallagh> contyk: It sounds like that it only matters the first time you add a layout post install
16:40:48 <sgallagh> After that, as long as it's already installed, you can switch fine
16:41:04 <kparal> also, if you have a document in the works, imagine a web form half filled out, and you need to include a special character, e.g. from a russion keyboard, there's no way to do it without losing your work
16:41:15 <frantisekz> kparal, I'd guess anybody would try out rebooting if something is not working, FE seems enough as it looks for me
16:41:44 <kparal> you could remove the keymap, rebooting, try adding it again, and be convinced that it's broken
16:42:02 <kparal> because you need to _keep_ the keymap and reboot
16:42:27 <frantisekz> you could (i wouldnt remove it before reboot)
16:42:49 <kparal> so, that makes it 50% success rate
16:42:53 <jlanda> I'm with kparal, this goes against Default panel criteria, specially because user thinks that he actually has changed the layout
16:43:00 <lruzicka> I think that kparal has his point, however isn't there another option how you would be able to insert a foreign character? Such as Character Map?
16:43:07 <adamw> yeah, that's how i usually do it
16:43:16 <adamw> i guess it's kinda a case of parsing how common this is
16:43:20 <contyk> or compose key
16:43:28 <contyk> well, for a subset of characters
16:43:35 <kparal> adamw: lbrabec found out with the use case I just described
16:43:58 <kparal> he wanted to type some foreign characters, added keymap, didn't work
16:44:02 <jlanda> not now but I had seasons where I used to change the keymap a lot
16:44:06 <kparal> hasn't realized that rebooting will fix it
16:44:18 <kparal> I found out after I played with it more
16:44:32 <lruzicka> jlanda, rebooting fixes it forever, so it is just one session affected
16:44:50 <kparal> lruzicka: not forever. as long as you keep it configured
16:44:59 <sgallagh> I know I sound like a broken record by now, but... if this was the last blocker at a Go/No-Go meeting, does anyone here feel like they'd still be calling it a blocker?
16:45:01 <jlanda> lruzicka: I tend to changr usually
16:45:18 <adamw> let's just call it The Sgallagh Test from now on
16:45:20 <kparal> sgallagh: yes
16:45:21 <frantisekz> sgallagh , I wouldn't
16:45:22 <lruzicka> jlanda, like adding and removing keymaps?
16:45:26 <Southern_Gentlem> -1 B +fe +1cb
16:45:31 <contyk> I would
16:45:36 <contyk> +1 blocker
16:45:47 <jlanda> writing on catalan on an english keyboard, having to reboot or usong the character map every time that I need to write an ç is not usefull
16:46:09 <frantisekz> jlanda, just once, it works after rebooting
16:46:13 <adamw> jlanda: it seems not to be every time. you need to reboot once for each newly-added keymap. aiui.
16:46:14 <kparal> keymaps are essential for non-us users. it's true that many users would configure that in anaconda. but many configure it only in the installed system
16:46:15 <lruzicka> jlanda, once you add a catalan keymap and reboot, you will be able to switch
16:46:23 <adamw> after the first reboot, as long as you keep the layout, it keeps working.
16:46:32 <cmurf> that's weird why is it a reboot and not a logout login thing
16:46:36 <jlanda> lruzicka: once first change, changing from en keymap to es for example works?
16:46:38 <contyk> can you workaround that by restarting just the ibus-daemon?
16:46:38 <cmurf> this is all userspace isn't it?
16:46:40 <sgallagh> cmurf: It is a logout login
16:46:48 <sgallagh> Reboot is just a shorthand in this conversation
16:46:49 <adamw> cmurf: as in, could it be fixed with an update?
16:46:51 <contyk> (still the user would need to know)
16:46:53 <kparal> re-login helps as well
16:46:54 <lruzicka> jlanda, yes .. until you alter the settings again
16:46:59 <adamw> oh, i see
16:47:14 <jlanda> for a non english speaker with an english keyboard
16:47:21 <jlanda> is usual to change the keymap
16:47:30 <cmurf> well i'm still -1 blocker even though I don't like the behavior at all one bit
16:47:31 <jlanda> i used to change it a lot in the same session
16:47:35 <frantisekz> you can do that jlanda
16:47:44 <lruzicka> I am using Czech keymap and I always configure that in anaconda
16:47:49 <jlanda> oh, ok, I misunderstood then
16:47:49 <frantisekz> you have to reboot just after adding a new layout
16:47:51 <kparal> lruzicka: and I never do
16:47:53 <frantisekz> switching works fine
16:47:57 <sgallagh> I'm definitely seeing a divide between US/CA users and EU users in this conversation.
16:48:07 <lruzicka> kparal, because you never use czech keyboard :D
16:48:26 <contyk> I have seven input methods configured currently and that's not everything I use
16:48:27 <kparal> lruzicka: I do. but I keep the system in defaults, because it's easier, and just configure my session
16:48:28 <sgallagh> The ones most likely to be affected are the ones calling for a blocker, so I guess I'm starting to lean in that direction
16:48:36 <cmurf> I think it's a 2+ language divide rather than a regional one
16:48:43 <jlanda> I didn't understand the bug the. The newly added keymap is not usable until you reboot the ?
16:48:49 <frantisekz> yep
16:48:52 <sgallagh> cmurf: potato/potahto
16:48:53 <pwhalen> sgallagh, same
16:48:54 <adamw> jlanda: until you log out and in again, or reboot.
16:49:09 <adamw> jlanda: once you've done that, you can switch between them fine.
16:49:10 <jlanda> ok, then not's so urgent, althrought it could be confusing
16:49:11 <lruzicka> jlanda, and then it works fine until you add another keymap
16:49:14 <adamw> you don't have to reboot each time you switch.
16:49:26 <kparal> that would be a clear blocker :)
16:49:27 <jlanda> I was scared with that :D
16:49:57 <jlanda> I tend to add keymaps on anaconda an not changing them anymore
16:49:58 <adamw> it's a shame we don't have kalev
16:50:05 <adamw> did anyone report this upstream yet?
16:50:10 <contyk> jlanda: and I add them the first time I need them :)
16:50:24 <kparal> switching keyboard is really _the_ basic functionality of a desktop, in my view
16:50:28 <jlanda> contyk: yeah, there will be as many use cases as users :D
16:50:37 <frantisekz> kparal, and it works :)
16:50:50 <sgallagh> contyk: You have seven different languages on your system and you vacationed in Iran... I'm starting to wonder what you do in your off-hours...
16:50:52 <kparal> adamw: I posted a call on #fedora-desktop some time ago, but didn't receive any response
16:50:59 <adamw> kparal: i meant to gitlab
16:51:15 <adamw> sgallagh: he could tell you, but then he'd have to kill you
16:51:24 <kparal> adamw: nope
16:51:33 <adamw> ah. that definitely needs doing, then
16:51:47 <adamw> so, can we revote?
16:51:53 <adamw> i'm not sure where everyone is at this point
16:52:03 <contyk> 🥕
16:52:25 <kparal> +1 blocker
16:52:26 <frantisekz> -1 blocker, +1 FE
16:52:30 <cmurf> -1 block, +1 fe
16:52:35 <contyk> +1 blocker
16:52:39 <bcotton> -1 block, +1 FE
16:52:43 <lruzicka> -1 blocker, +1 fe
16:52:57 <Southern_Gentlem> -1 B +fe +1cb
16:53:12 <lruzicka> and press them hard to fix it before release :D
16:53:13 <jlanda> -1 blocker, +1 fe, in case of no fix, would be possible to add a warning to g-c-c?
16:53:16 <sgallagh> I'm changing my vote to a 0. I'm not sure it'd pass the Go/No-Go test, but a lot of multilingual folks are telling me it would break their workflow.
16:53:41 <jlanda> something like "hei, you must relog to use the new keymap"
16:53:49 <frantisekz> jlanda, I wouldn't count on that
16:53:56 <cmurf> but it's a one time logout/login
16:54:05 <kparal> jlanda: it would be easier to fix the bug than add that
16:54:07 <cmurf> it's like, plug unplug plug and play
16:54:13 <mboddu> I am +1 Blocker, but if its the only bug that is blocking the release, then I will -1 it
16:54:24 <contyk> heh
16:54:28 <cmurf> haha
16:54:33 <jlanda> kparal: no idea about g-c-c internals ;)
16:54:33 <lruzicka> mboddu, :) so it is not as severe, right?
16:54:34 <adamw> mboddu: that means you are -1
16:54:44 <kparal> jlanda: me neither, but I know the maintainers
16:54:44 <sgallagh> mboddu: That literally means "not a blocker"
16:54:48 <adamw> sorry, i am a blocker fundamentalist. if you would not actually hold the release for it, you do not believe it's a blocker
16:54:48 <cmurf> exactly
16:55:00 <cmurf> it's in the definition of the word
16:55:16 <adamw> counting sgallagh and mboddu as 0s, for the time being, that means we're at -5 +2
16:55:37 <adamw> thus we give contyk and kparal the hallowed Right To Say I Told You So, but:
16:55:38 <kparal> adamw: your vote?
16:55:41 <adamw> i'm a 0 too
16:55:42 <mboddu> adamw: Then I would punt it for now and create the gitlab ticket and see what happens
16:55:42 <adamw> sorry
16:55:44 <cmurf> haha
16:55:49 <adamw> we don't have time to punt
16:56:09 <kparal> that's fine, I'm used to be outvoted
16:56:14 <sgallagh> Does anyone disagree on a +1 FE though?
16:56:15 <mboddu> Oh right, for some reason I am thinking of 3 week of freeze, sorry, then I am 0
16:56:22 <sgallagh> There still may be time for this to get fixed
16:56:41 <adamw> proposed #agreed 1637418 - RejectedBlocker AcceptedFreezeException (Final) - on a split vote, under the 'conditional violation' policy where we have to decide how significant the impact of the bug is, this was decided to be not quite significant enough to block the release. it is bad, though, and we definitely would like a fix if at all possible
16:56:46 <cmurf> ack
16:56:54 <frantisekz> ack
16:56:58 <sgallagh> ack
16:57:01 <pwhalen> ack
16:57:03 <bcotton> ack
16:57:03 <Southern_Gentlem> ack
16:57:03 <mboddu> ack
16:57:03 <lruzicka> ack
16:57:05 <kparal> ack
16:57:09 <contyk> well, ack
16:57:11 <adamw> #agreed 1637418 - RejectedBlocker AcceptedFreezeException (Final) - on a split vote, under the 'conditional violation' policy where we have to decide how significant the impact of the bug is, this was decided to be not quite significant enough to block the release. it is bad, though, and we definitely would like a fix if at all possible
16:57:18 <kparal> coremodule: commonbug! :)
16:57:28 <adamw> please do file a gitlab issue, it'll be much more likely to get attention that way
16:57:32 <kparal> and we need to make sure to poke gnome folks about it
16:57:45 <adamw> and try to poke #fedora-desktop again, and maybe #gnome-shell also on gimpnet
16:57:45 <adamw> yep
16:57:46 <kparal> a volunteer for that?
16:57:58 <Southern_Gentlem> which is #fedora-workstation not desktop correct
16:58:02 <kparal> or is it assumed to be me?
16:58:08 <Southern_Gentlem> ^^
16:58:20 <adamw> Southern_Gentlem: no, it's #fedora-desktop. on gimpnet.
16:58:20 <kparal> Southern_Gentlem: it's both, and on different servers :/
16:58:31 <adamw> #fedora-workstation here exists, but isn't really as active
16:58:35 <kparal> alright, I'm the volunteer...
16:59:12 <adamw> =)
16:59:29 <adamw> #action kparal to try and get some response to 1637418 from gnome folks
16:59:35 <adamw> #topic (1637751) Display gets messed up when routing panel is active
16:59:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637751
16:59:35 <adamw> #info Proposed Blocker, gnome-maps, NEW
16:59:36 <lruzicka> I can do it, kparal, if you remind me of it tomorrow
16:59:58 <adamw> this is the 'basic functionality' requirement...kinda depends where you draw that line for gnome-maps, i guess
17:00:00 <lruzicka> +1 blocker
17:00:01 <kparal> lruzicka: thanks, I will
17:00:09 <adamw> it kinda works, but trying to do something pretty standard for a maps app makes it go pretty wrong
17:00:19 <sgallagh> I can actually reproduce this without even the routing
17:00:27 <adamw> worth noting that, if this were taken as a blocker, one way to resolve it is simply to drop the app from Workstation.
17:00:27 <cmurf> cannot reproduce the messed up panel but I can get a "what's here" crash after using the panel
17:00:30 <frantisekz> +1 blocker, although this is HW specific if I remember correctly
17:00:34 <sgallagh> If I just open Maps, then change workspace and back again, there's garbage on the screen
17:00:41 <adamw> i reproduced it at least in a VM and then on my desktop
17:00:42 <kparal> frantisekz get's a big no-no for detecting this a few weeks back and then not reporting it
17:00:44 <cmurf> what video?
17:00:44 <adamw> it may depend on how wide the window is
17:00:56 <adamw> cmurf: there's a video attached to the bug
17:01:06 <sgallagh> I'm +1 blocker, but I strongly recommend the "drop it from the default install" solution
17:01:33 <lruzicka> I could reproduce it in a VM, I believe that VM has the simplest video driver. It must work.
17:01:33 <Southern_Gentlem> +!B
17:01:36 <frantisekz> few weeks is probably two though, didn't report it because my session crashed with open bugzilla window in process of writing it down and I forgot about that ... -_- :D
17:01:42 <bcotton> +1 blocker, +1 drop from the default install
17:01:51 <frantisekz> bcotton++
17:01:51 <zodbot> frantisekz: Karma for bcotton changed to 15 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:01:52 <contyk> +1 blocker per criteria but meh
17:01:53 <cmurf> adamw: I saw that video, I mean what GPU
17:02:06 <lruzicka> +1 blocker, but -1 drop unless totally necessary
17:02:07 * kparal feels sad that we block on gnome-maps and not on keymap switching
17:02:10 <cmurf> is it hardware specific and how common is this?
17:02:14 <kparal> +1 blocker per criteria
17:02:17 <adamw> cmurf: it's a VM.
17:02:23 * kparal would love to make gnome-maps gone from a default install
17:02:26 <sgallagh> cmurf: I have issues on Intel
17:02:28 <adamw> and it seems pretty reproducible across multiple hardware
17:02:36 <frantisekz> adamw, I think it doesn't happen on VMs with 3d accel enabled
17:02:37 <contyk> kparal++
17:02:37 <zodbot> contyk: Karma for kparal changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:02:43 <sgallagh> Though when I force it to run on Nouveau, it seems okay so far
17:02:47 <adamw> kparal: if we didn't have the option to drop the app, it'd be different
17:02:54 <adamw> kparal: i mean, we could drop all keyboard layouts except US...;)
17:03:14 <sgallagh> I take that back; I've somehow gotten it to freeze
17:03:19 <lruzicka> adamw, Please do not, I am using a different one and I am still not affected by that discussed bug.
17:03:20 <contyk> adamw: ㅠㅠ
17:03:34 <frantisekz> regarding the drop... I can't imagine anybody using desktop app for maps today... we have google maps :)
17:03:42 <lruzicka> ←↓→
17:03:46 <adamw> oh, i'd like to use it if it worked
17:03:53 <adamw> i hate telling google where i am and where i'm going all the time
17:03:58 <cmurf> BTW if we +1 block this, they are just going to remove it
17:04:02 <adamw> yes, that's the idea.
17:04:04 <cmurf> doesn't sound like they have resources to fix
17:04:11 <sgallagh> adamw: As if they didn't already know?
17:04:19 <kparal> that's really up to workstation WG to decide
17:04:32 <kparal> if they don't have resources, it makes sense to not have it in a default install
17:04:54 <kparal> but I'd rather expect a fix
17:05:18 <adamw> proposed #agreed 1637751 - AcceptedBlocker (Final) - the issues mentioned in the bug are widely reproducible and agreed to violate "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". We note that dropping the app from Workstation would be an acceptable resolution here
17:05:27 <frantisekz> ack
17:05:28 <pwhalen> +1 blocker/ack
17:05:32 <kparal> ack
17:05:32 <sgallagh> ack
17:05:34 <Southern_Gentlem> ack
17:05:36 <bcotton> ack
17:05:39 <lruzicka> patch
17:05:45 <adamw> waiting
17:05:54 <mboddu> ack
17:05:54 <adamw> hi mclasen
17:06:10 <lruzicka> ... would be the last possible resolution we would accept (or something similar)
17:06:21 * mclasen not really here
17:06:34 <adamw> who said that?
17:06:51 <lruzicka> who said what?
17:07:01 <frantisekz> that it's last possible resolution
17:07:02 <sgallagh> lruzicka: I think the wording as is would be fine.
17:07:03 <adamw> lruzicka: don't know if we have space for that. and it's not really a terrible resolution. let me see
17:07:15 <sgallagh> The people involved know what their options are
17:07:18 <adamw> proposed #agreed 1637751 - AcceptedBlocker (Final) - the issues mentioned in the bug are widely reproducible and agreed to violate "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". We note that dropping the app from Workstation is acceptable if a fix is not available
17:07:32 <frantisekz> ackitty ack
17:07:33 <lruzicka> ack
17:07:34 <sgallagh> ok, ack
17:07:39 <Southern_Gentlem> ack
17:07:41 <bcotton> ack
17:08:00 <kparal> ack
17:08:02 <contyk> ack
17:08:05 <mboddu> ack
17:08:14 <adamw> #agreed 1637751 - AcceptedBlocker (Final) - the issues mentioned in the bug are widely reproducible and agreed to violate "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". We note that dropping the app from Workstation is acceptable if a fix is not available
17:08:20 <adamw> #topic (1637957) Closing GNOME Software outside of the main page causes it to glitch
17:08:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1637957
17:08:20 <adamw> #info Proposed Blocker, gnome-software, NEW
17:08:25 <adamw> similar kinda bug
17:08:31 <adamw> of course, removing Software is a much harder sell :P
17:08:57 <adamw> so i'm definitely +1 FE, kinda +0.5 blocker
17:09:16 <kparal> +1 blocker
17:09:22 <lruzicka> I have seen this bug in real life and I am +1 blocker
17:09:52 <frantisekz> +1 FE, +1 Blocker
17:09:59 <kparal> unless we amend our criteria that apps need to withstand basic functionally only in the first run
17:10:09 <kparal> *functionality
17:10:10 <adamw> heh
17:10:14 <sgallagh> .fire kparal
17:10:14 <zodbot> adamw fires kparal
17:10:20 <frantisekz> :D
17:10:23 <adamw> ok, i'll stop being wussy, +1 blocker
17:10:32 <cmurf> +1 blocker
17:10:46 <contyk> +1 blocker
17:11:23 <pwhalen> +1 blocker
17:11:31 <bcotton> +1 blocker. look like there's a fix in the works already, so it seems largely academic :-)
17:11:34 <Southern_Gentlem> +1 B
17:11:46 <kparal> bcotton: you'd be surprised how often patches don't work
17:11:51 <sgallagh> +1 blocker
17:12:05 <mboddu> I am +1 Blocker on this one
17:12:06 <bcotton> kparal: sorry, couldn't hear you with my fingers in my ears
17:12:17 <adamw> proposed #agreed 1637957 - AcceptedBlocker (Final) - this is agreed to be 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."
17:12:17 <kparal> or take longer than expected. or create other issues. or....  :)
17:12:30 <contyk> ack
17:12:38 <kparal> ack
17:12:39 <pwhalen> ack
17:12:49 <sgallagh> ack
17:12:52 <lruzicka> ack
17:13:09 <mboddu> ack
17:13:14 <frantisekz> ack
17:13:15 <bcotton> ack
17:13:31 <adamw> #agreed 1637957 - AcceptedBlocker (Final) - this is agreed to be 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."
17:13:32 <adamw> grr
17:13:34 <adamw> #agreed 1637957 - AcceptedBlocker (Final) - this is agreed to be 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."
17:13:45 <adamw> #topic (1632981) Cannot commit Japanese candidates or Korean Hangul in gnome-terminal and libreoffice
17:13:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632981
17:13:45 <adamw> #info Proposed Blocker, gtk3, NEW
17:13:58 <adamw> srsly can we just deprecate all languages beside english, jeez, why do you funny foreign people have to make life so hard
17:14:08 <frantisekz> :D
17:14:11 <frantisekz> adamw++
17:14:11 <zodbot> frantisekz: Karma for adamwill changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:14:11 <coremodule> :P
17:14:20 <adamw> 26 letters ought to be enough for anybody
17:14:32 <adamw> (and sixteen thousand emoji, of course)
17:14:43 <cmurf> hmmm that's funny
17:14:50 <lruzicka> why dont the Japanese use emoji instead?
17:15:03 <lruzicka> but +1 blocker
17:15:07 <kparal> 🎉
17:15:26 <cmurf> sixteen thousand emoji sounds like Kanji or any other pictographic writing system
17:15:30 * contyk uses both Korean and Japanese inputs
17:15:33 * contyk is biased
17:15:49 <contyk> but it works in xterm ;)
17:15:53 <contyk> anyway, +1 blocker
17:15:55 <Southern_Gentlem> +1 B
17:16:01 <sgallagh> Yeah, +1 blocker
17:16:05 <frantisekz> +1 B
17:16:37 <bcotton> +1 blocker
17:17:51 <contyk> ftr, I faintly remember Chrome having similar issues
17:18:14 <pwhalen> +1 blocker
17:18:31 <mboddu> +1 Blocker and hopefully the proposed fix just works
17:19:51 <frantisekz> is this wayland only? we can force languages other than English to use Xorg... :D :D :D
17:20:12 <adamw> proposed #agreed 1632981 - AcceptedBlocker (Final) - this is accepted as a conditional violation of the "basic functionality test" criterion when affected input methods are used, certainly including Japanese and Korean and likely also affecting some Chinese IMs
17:20:16 <adamw> (this seems a better fit than the keyboard layout criterion, as that's all about the right layout being used: in this case the right layout *is* used, it just doesn't work right...)
17:20:26 <adamw> frantisekz: i think it is wayland-only, yeah
17:20:32 <adamw> but that might be tricky :)
17:20:47 <adamw> (what if you switch to japanese after you logged in? your session ends? :>)
17:20:59 <frantisekz> yep, sounds like a perfect solution :D
17:21:41 <mboddu> ack
17:21:45 <lruzicka> ack
17:21:46 <frantisekz> ack
17:21:52 <Southern_Gentlem> ack
17:21:52 <bcotton> ack
17:22:05 <contyk> ack
17:22:26 <adamw> #agreed 1632981 - AcceptedBlocker (Final) - this is accepted as a conditional violation of the "basic functionality test" criterion when affected input methods are used, certainly including Japanese and Korean and likely also affecting some Chinese IMs
17:22:34 <adamw> ok, that's all the proposed blockers
17:22:40 <adamw> #info that's all the proposed blockers
17:22:41 * Southern_Gentlem requests a revote on https://bugzilla.redhat.com/show_bug.cgi?id=1637418 please
17:22:58 <adamw> Southern_Gentlem: on what grounds?
17:23:11 <mboddu> adamw: Waht about https://bugzilla.redhat.com/show_bug.cgi?id=1637927?
17:23:21 <adamw> mboddu: we did that one first.
17:23:28 <adamw> #topic End of proposed blockers
17:23:38 <adamw> Southern_Gentlem: do you have new information, or something else that would cause anyone to change their vote?
17:23:56 <Southern_Gentlem> adamw, because i think there has been side channel discussions that may change the out come of the vote
17:23:56 <mboddu> adamw: Oh sorry, joined late to the party :)
17:25:00 <lruzicka> Southern_Gentlem, which is?
17:25:05 <kparal> adamw: we should talk about https://bugzilla.redhat.com/show_bug.cgi?id=1630899
17:25:06 <adamw> anyone else support the motion to revote on 1637418?
17:25:23 <frantisekz> voting was -5 +2 if I remember , pretty significant victory for non-blockers
17:25:32 <lruzicka> if I see the content of the side discussion
17:25:34 <bcotton> -1 revote
17:25:47 <frantisekz> we can re-decide on Thursday if we find out something new
17:26:11 <cmurf> -1 revote but I fully support someone filing a fesco ticket and rallying the cause on devel@ to convince fesco to just make it a blocker
17:26:15 <lruzicka> I would still here those side reasons ...
17:26:18 <adamw> okay
17:26:24 <lruzicka> like to hear
17:26:30 <kparal> I think we should email desktop list first
17:26:30 <adamw> if anyone wants to change their vote or dispute the outcome on that one, please comment on the bug.
17:26:43 <kparal> perhaps the workstation wg will have a different opinion on blockerness
17:26:51 <adamw> kparal: i'm planning on doing accepted blockers after proposed FEs.
17:26:59 <kparal> ok
17:27:06 <adamw> #info moving on to proposed FEs
17:27:14 <Southern_Gentlem> lruzicka, one that all of the people whom use that say it broken we have approved simulair things as blockers with korean and japenese
17:27:30 <mboddu> adamw: OH cool, I am interested in https://bugzilla.redhat.com/show_bug.cgi?id=1616167
17:27:32 <adamw> Southern_Gentlem: how is that bug similar other than 'it's about typing a non-english language'?
17:27:37 <adamw> #topic (1639233) Update nvdimm support with fixes from rhel
17:27:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1639233
17:27:37 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
17:27:41 <adamw> anyhow
17:28:00 <adamw> sure, +1.
17:28:03 <frantisekz> +1
17:28:07 <adamw> working on new hardware is good.
17:28:08 <Southern_Gentlem> +1
17:28:11 <cmurf> +1
17:28:20 <kparal> +1 fe
17:28:21 <pwhalen> +1
17:28:24 <lruzicka> Southern_Gentlem, But those things really do not work. Layout switching works .. you only need to relog
17:28:25 <mboddu> +1 FE
17:28:38 <cmurf> nvdimm is the way to solve our suspend and hibernation problems
17:28:40 <lruzicka> +1 fe
17:28:43 <cmurf> just fix this in hardware haha
17:29:01 <bcotton> +1 because it seems like an isolated change
17:29:13 <contyk> +1
17:29:17 <bcotton> (although TBH i'd rather see it go through the Change process)
17:29:57 <adamw> proposed #agreed 1639233 - AcceptedFreezeException (Final) - hardware enablement in the installer is always desirable, and cannot be fixed with an update. As this is said to be fairly isolated from other storage code, the risk should be low
17:30:05 <frantisekz> ack
17:30:14 <lruzicka> ack
17:30:26 <contyk> ack
17:30:31 <Southern_Gentlem> ack
17:30:51 <adamw> #agreed 1639233 - AcceptedFreezeException (Final) - hardware enablement in the installer is always desirable, and cannot be fixed with an update. As this is said to be fairly isolated from other storage code, the risk should be low
17:30:58 <adamw> #topic (1638444) One of the external displays is sometimes turned off
17:30:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1638444
17:30:58 <adamw> #info Proposed Freeze Exceptions, mutter, ON_QA
17:31:24 <adamw> +1 for me.
17:31:28 <cmurf> +1 FE
17:31:44 <pwhalen> +1 FE
17:31:57 <bcotton> +1 FE
17:32:07 <frantisekz> +1 FE
17:32:08 <sgallagh> +1 FE
17:32:50 <contyk> +1
17:32:53 <lruzicka> +1
17:34:00 <adamw> proposed #agreed 1638444 - AcceptedFreezeException (Final) - this affects some hardware configs on first boot so cannot be fixed with an update, may cause inconvenience if the affected display is the main one
17:34:08 <frantisekz> ack
17:34:18 <kparal> ack
17:34:28 <contyk> ack
17:34:28 <pwhalen> ack
17:35:00 <bcotton> ack
17:35:00 <adamw> #agreed 1638444 - AcceptedFreezeException (Final) - this affects some hardware configs on first boot so cannot be fixed with an update, may cause inconvenience if the affected display is the main one
17:35:09 <adamw> #topic (1632518) PackageKit installs packages from default module streams, but does not enable the module stream
17:35:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632518
17:35:10 <adamw> #info Proposed Freeze Exceptions, PackageKit, NEW
17:35:46 <contyk> shouldn't this be a blocker?
17:35:47 <adamw> uh
17:35:54 <adamw> it should be a blocker or nothing
17:35:56 <lruzicka> contyk, I wanted to say that, too
17:36:05 <adamw> though if it's a blocker, the thing that should be a blocker is the existence of default module streams
17:36:20 <adamw> zbyszek claims there are some for f29, there are not supposed to be any.
17:36:24 <adamw> sgallagh: any idea what he means?
17:36:30 <contyk> what
17:36:41 <Southern_Gentlem> i thought modules was an opt in situation
17:36:44 <adamw> contyk: by policy there are not supposed to be any default module streams for f29 ever.
17:36:47 <adamw> (aiui).
17:36:50 <adamw> they're supposed to come in with f30.
17:36:53 <lruzicka> Southern_Gentlem, no modules are turned on by default
17:36:59 <lruzicka> Southern_Gentlem, you can opt out
17:36:59 <sgallagh> adamw: Not quite
17:37:00 <contyk> adamw: what policy?
17:37:01 <adamw> lruzicka: this is a different thing.
17:37:11 <sgallagh> The policy was that existing packages couldn't be moved to default streams
17:37:17 <sgallagh> These are net-new content
17:37:19 <adamw> a default module stream basically means 'when you do dnf install foo, foo comes from a module by default'
17:37:33 <adamw> sgallagh: but...that leads to problems like this.
17:37:38 <sgallagh> lruzicka, Southern_Gentlem: Modules are no longer optional as of F29
17:37:45 <sgallagh> They are installed by default on all systems
17:37:49 <contyk> this should have been fixed as part of the ModulesForEveryone change
17:37:52 <sgallagh> At least, the mechanism and repos are
17:37:59 <adamw> there is a problem in that we have not assessed whether the distro's mechanisms and policies are ready for this. and introducing it at this point is arguably far too late.
17:38:03 <lruzicka> sgallagh, I know, but you can opt out by disabling modular repos
17:38:12 <sgallagh> lruzicka: ehhh, sort of
17:38:33 <sgallagh> This would be that exact edge-case
17:38:39 <sgallagh> There is content that is only available via modules
17:39:08 <adamw> this really should *not* be showing up *now* for f29. that's just garbage.
17:39:12 <sgallagh> adamw: I think these two were actually available at beta. But, again, they are only new content. No upgrade concerns.
17:39:23 <adamw> sgallagh: so what do we do about bugs like this?
17:39:35 <sgallagh> I agree it's a blocker.
17:39:36 <adamw> i filed this for rawhide on the basis that this mechanism wouldn't suddenly show up for f29 so we wouldn't need to worry about it
17:39:44 <adamw> and now it's a late blocker. :/
17:39:58 <frantisekz> +1 blocker surely :/
17:40:16 <sgallagh> adamw: Actually, hang on.
17:40:17 <adamw> i mean
17:40:20 <adamw> there may be a loophole here
17:40:23 <lruzicka> unless we say that modularity is only functional by dnf
17:40:25 <sgallagh> I'm going to revise that
17:40:34 <adamw> in that release-blocking packagekit-based things may not offer anything in the default module streams
17:40:45 <lruzicka> I think this was the idea for F29.
17:40:49 <adamw> gnome-software does not offer all packages. i'm honestly not sure what anything in KDE does.
17:40:50 <sgallagh> adamw: Give me a moment
17:40:53 <adamw> kk.
17:40:55 <contyk> lruzicka: nah, the whole point of the ModulesForEveryone change was to make it work everywhere, transparently
17:41:44 <sgallagh> Let's be clear: the only two modules affected (no more will be granted permission to be default) are stratis and dwm
17:41:58 <sgallagh> Neither of which are likely to be visible to any front-end of PackageKit
17:42:11 <adamw> i would like that to read 'i tested and they definitely aren't'.
17:42:15 <sgallagh> If we make this a blocker, I am perfectly content to push a change to drop their default streams
17:42:29 <Southern_Gentlem> +1 B
17:42:36 <sgallagh> I can do that in five minutes and it will be the case in tonight's compose
17:42:39 <adamw> for the record, we did have https://bugzilla.redhat.com/show_bug.cgi?id=1636184
17:43:11 <contyk> so, dwm is not entirely new content -- it was available as a non-modular package; it was just *moved* to modules
17:43:18 <adamw> sgallagh: how do these default module streams tie in with your comment in https://bugzilla.redhat.com/show_bug.cgi?id=1636184#c10 ?
17:43:28 <contyk> so without default streams, dwm users will have to enable the module manually
17:43:35 <adamw> was there a Change request for them? were they added in between Fedora releases?
17:43:57 <sgallagh> I think there was one for Stratis. contyk: did you do one for DWM?
17:44:07 <contyk> yeah, I maintain dwm
17:44:25 <contyk> there was no change for that; I just did it before branch point
17:44:27 <frantisekz> okay guys, I need to leave now, thanks adamw for leading and others for attending!
17:44:37 <sgallagh> contyk: That was in violation of the rules you helped write :-/
17:45:01 <adamw> i don't see anything about a stratis module stream on https://fedoraproject.org/wiki/Releases/29/ChangeSet
17:45:01 <contyk> that's probably true
17:45:07 <adamw> there is a Change relating to stratis, but it says nothing about modules
17:45:10 <contyk> although the rules are pretty vague
17:45:12 <adamw> https://fedoraproject.org/wiki/Changes/StratisStorage-1.0
17:45:30 <sgallagh> adamw: Yeah, turns out that was the only way to build that Change for F29.
17:45:43 <adamw> 'turns out' doesn't tell anyone *else* that, though.
17:45:43 <contyk> sgallagh: still, isn't this what your change was about?
17:45:51 <sgallagh> adamw: Yeah, this was a hole in the process
17:46:11 <adamw> the bigger picture here is: the appearance of default module streams in f29 does not appear to have been publicized anywhere i can find, and it surprised at least me, and i suspect most everyone else who wasn't involved
17:46:17 <sgallagh> contyk: Strictly, the ModulesForEveryone Change was about having the repos available for all installations and making sure that install and update worked as expected.
17:46:33 <sgallagh> So while it's not explicitly spelled out, yes pretty much
17:46:41 <adamw> nothing to do with default module streams was, afaik, on the list of modular functions fesco talked about getting tested for f29, and we haven't (afaik) done any testing on it
17:46:49 <adamw> in that context, having them in f29 worries me
17:47:23 <lruzicka> As far modularity is concerned, we tested whether modules and streams can be maintained with dnf
17:47:24 <sgallagh> That's a fair concern. I'm not trying to disagree.
17:47:37 <adamw> i appreciate that it only involves a couple of fairly niche sets of packages and probably won't be a big issue in practice for most people, but it just doesn't seem like the right way to do things
17:47:57 <lruzicka> we did not address any corner cases where a module would install instead of a regular package
17:48:09 <Southern_Gentlem> i perfer an opt in for f29 with the announcement of required for f30
17:48:18 <adamw> you can't 'opt in' to a default
17:48:24 <adamw> that's sort of the opposite of what 'default' means. :P
17:48:30 <sgallagh> adamw: Well, I think he means "nothing has a default stream in F29"
17:48:40 <Southern_Gentlem> correct
17:48:40 <sgallagh> So if you want a module, it means using a module-specific enablement command
17:48:45 <adamw> ok, yeah, phrased that way, that's what i'm saying too.
17:48:53 <contyk> sgallagh, you said there wouldn't be any more default streams in f29; does it mean that adding entirely new content to f29 after GA, as modules only, would make it unavailable by default?
17:49:03 * lruzicka though that even if modular repos would be available by default, it would be a user's decision to enable the modules.
17:49:07 <adamw> so, how about this:
17:49:25 <lruzicka> I do not think having modules replacing normal packages is a good way to go.
17:49:29 <adamw> instead of accepting this as an FE or blocker, we re-open https://bugzilla.redhat.com/show_bug.cgi?id=1636184 and accept *that* as a blocker?
17:49:32 <sgallagh> lruzicka: It will always be a user's decision to enable a module other than the default... if that helps :)
17:50:04 <lruzicka> sgallagh, so any time if I do dnf install package, it will install from main repo?
17:50:05 <contyk> the purpose of the defaults is to make it transparent -- the user doesn't have to care where it comes from
17:50:13 <sgallagh> lruzicka: The purpose of default streams is to have a migration path towards module-only content.
17:50:21 <adamw> and thus require modularity folks to ensure f29 contains no default module streams and commit to not adding any during its lifetime
17:50:26 <sgallagh> Which is a key part of the intent to disconnect their lifecycles
17:50:35 <adamw> the feature should arrive from f30+
17:52:00 <sgallagh> adamw: Honestly, I think the BZ we started on is more correct. From an end-user's perspective, this should be no different than interacting with non-modular content.
17:52:08 <Southern_Gentlem> contyk, we are fedora. we care where our stuff comes from. we should have the freedom to make that ourselfs
17:52:10 <sgallagh> Just the source and release tags are a little different
17:52:43 <sgallagh> There just happens to be a bug here that could lead to incorrect module-enablement
17:53:01 <contyk> Southern_Gentlem: you can always switch to some other source, if it exists
17:53:07 <sgallagh> So I think this one is the blocker, but we *can* choose to resolve it by dropping the default streams
17:53:29 <adamw> sgallagh: i'm not sure it's fair to suddenly require pk/dnf folks to fix this for f29 in a tearing hurry
17:53:36 <adamw> especially as they don't seem to yet agree on where to fix it
17:53:48 <sgallagh> Southern_Gentlem: We are Fedora: we produce an integrated system, not just a bunch of blocks you can throw together. Choice for its own sake isn't our goal
17:53:50 <adamw> hum.
17:54:08 <contyk> I admit I'm confused; I really thought this was meant to land in f29
17:54:19 <contyk> defaults are a major feature
17:54:35 <sgallagh> contyk: It was, but as adamw points out... we didn't communicate that well
17:54:46 <adamw> contyk: it is possible for it to be true both that *you*, sgallagh etc. were always sort of planning on it to be part of f29, *and* that no-one else was aware of this.
17:55:00 <sgallagh> So they haven't tested it appropriately, which is not their fault.
17:55:06 <contyk> yet packagekit sees the content
17:55:18 <contyk> so it's somewhat implemented
17:55:36 <adamw> contyk: PK winds up installing the package requested from the module...but not enabling the module
17:55:41 <sgallagh> contyk: Implemented or not, it's not tested and not on the test *plan*.
17:55:58 <sgallagh> I think adamw is right that we can't certify this for F29 at this point.
17:55:58 <adamw> note, the Modules For Everyone Change does sort of mention this, but in a way that isn't really clear unless you already know what it means
17:56:00 <adamw> it says
17:56:03 <adamw> "Fedora Packagers will be able to use modules and module defaults to build each stream once and have it available for any supported Fedora release they wish."
17:56:10 <adamw> and "It is important to note that Fedora's blocking criteria will apply *only* to packages in the traditional RPM repos or default streams of modules."
17:56:26 <adamw> so the concept is sort of referred to, but never exactly explained, or explicitly stated to be part of the change, afaics
17:56:40 <sgallagh> Yeah, so that was *meant* to cover this, but I'm on your side that we didn't communicate that sufficiently in time.
17:56:55 <adamw> it does also state "The user experience may be as transparent to users as they wish. If users remain unaware or uncaring about modules, all of their existing commands and workflows will continue to work."
17:57:11 <adamw> which can easily be read as implying "if I don't do anything explicitly involving modules, nothing will happen that involves modules"
17:57:23 <contyk> disagree with the last bit
17:57:26 <lruzicka> so I understood that
17:57:43 <contyk> well
17:57:45 <sgallagh> adamw: Except that's not what it mans :-/
17:57:48 <sgallagh> *means
17:58:02 <sgallagh> That's supposed to refer to the defaults
17:58:05 <lruzicka> sgallagh, what does that mean then?
17:58:09 <adamw> sgallagh: it's heavily ambiguous. particularly with the following phrase:
17:58:14 <adamw> "If they wish to interact with modules, they can do so with any of the dnf module <foo> commands that were added in Fedora 28 for Server Edition."
17:58:25 <adamw> which strongly suggests that if you *don't* do "dnf module <foo>", you *won't* be using any modules.
17:58:41 <sgallagh> adamw: That sentence is missing the word "directly" before interact
17:58:45 <sgallagh> So yeah, I can see the ambiguity
17:58:55 <adamw> so, yeah.
17:59:00 <adamw> ok, new proposal
17:59:07 <adamw> we accept this as a blocker and explain the situation
17:59:13 <contyk> so, is this about wording? it's not like the pkgkit folks weren't aware, really
17:59:13 <adamw> and maybe create a fesco ticket for fesco to keep an eye on things
17:59:27 <adamw> contyk: i think the packagekit folks absolutely were not aware of *this* particular thing being needed.
17:59:32 <lruzicka> contyk, but we were not aware.
18:00:24 <adamw> contyk: the issue at question now is essentially this. do we:
18:00:30 <adamw> 1) require f29 not contain any default module streams
18:00:41 <adamw> 2) require *EITHER* that this bug be fixed *OR* that f29 not contain any default module streams
18:01:06 <adamw> (or technically 3) don't require either, but i'm not sure anyone wants that.)
18:01:32 <Southern_Gentlem> 4 that the module repos can be installed just not enabled by default
18:02:02 <lruzicka> Southern_Gentlem, Number 4 is impossible, because it has been so much promoted already.
18:02:12 <cmurf> i don't remember what I installed, but something dragged in a module even though I didn't enable modules or whatever the lingo is supposed to be
18:02:32 <contyk> that was libgit2
18:02:40 <cmurf> nope, it was not recent
18:02:46 <cmurf> month ago maybe
18:02:50 <cmurf> maybe 2
18:03:05 <adamw> yes. that was https://bugzilla.redhat.com/show_bug.cgi?id=1636184
18:03:17 <sgallagh> cmurf: `dnf module list` and tell us what module you have enabled?
18:03:30 <cmurf> in fact never mind, it was on f28 server not workstation - different situation and out of scope
18:03:31 <adamw> anyway...
18:03:41 <adamw> let's get out of this swamp
18:04:11 <sgallagh> adamw: I'd prefer 2) above, as it's in keeping with the original intent of the ModulesForEveryone Change.
18:04:16 <lruzicka> I must leave now, but I am supporting solution number 1
18:04:27 <cmurf> sgallagh: over on fedora-qa later if you want, I've got a LOT of things in 'dnf module list'
18:04:30 <cmurf> on workstation
18:04:36 <sgallagh> From the QA perspective, they should not have specifically needed to even be aware that these defaults existed :-/
18:05:03 <contyk> indeed, that was the point
18:05:24 <contyk> cmurf: add --enabled
18:05:25 <adamw> proposed #agreed 1632518 - AcceptedBlocker (Final) - default module streams appearing in F29 was not expected by all parties involved. We agree at least that this bug must be fixed *OR* default module streams must be delayed to Fedora 30. We will also file a FESCo ticket to ensure FESCo is aware of this situation
18:05:29 <sgallagh> The only reason this is on your plate is because libdnf didn't implement something that PK assumed they had
18:05:58 <sgallagh> adamw: Ack
18:06:02 <cmurf> contyk: workstation 29 "no matching Modules to list"
18:06:17 <contyk> cmurf: then no modules are enabled on your system
18:06:31 <adamw> cmurf: if you did 'dnf install dwm', though, it would come from a module.
18:06:46 <adamw> and if you did 'dnf module list --enabled' after that, it'd show one module.
18:06:48 <cmurf> no I can't remember what I installed and I was surprised it brought in a module
18:06:49 <adamw> that's the feature at issue here.
18:06:54 <adamw> anyhoo
18:06:56 <cmurf> no not workstation - offtopic
18:06:57 <adamw> ack/nack/patch ?
18:07:04 <Southern_Gentlem> ack
18:07:18 <bcotton> ack
18:07:28 <contyk> ack
18:07:58 <pwhalen> ack
18:09:13 <cmurf> On F29 workstation, "no matching modules" and on F29 Server "libgit2 0.27 [e]"
18:09:36 <adamw> #agreed 1632518 - AcceptedBlocker (Final) - default module streams appearing in F29 was not expected by all parties involved. We agree at least that this bug must be fixed *OR* default module streams must be delayed to Fedora 30. We will also file a FESCo ticket to ensure FESCo is aware of this situation
18:09:48 <sgallagh> cmurf: That was an earlier bug; that shouldn't have gained a default and I dropped that from the metadata.
18:09:53 <adamw> OK, last proposed FE
18:09:53 <adamw> #topic (1638847) Privileged containers running as container_t instead of spc_t
18:09:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1638847
18:09:53 <adamw> #info Proposed Freeze Exceptions, podman, ON_QA
18:10:03 <adamw> +1 FE for the 'ostree installs' case
18:10:12 <Southern_Gentlem> +1
18:10:15 <sgallagh> +1 FE
18:10:17 <adamw> we don't exactly _have_ 0-day updates for ostree media, it'd be nice to have this work right on day 1 for those
18:10:38 <contyk> +1
18:10:38 <bcotton> +1 FE
18:11:57 <adamw> proposed #agreed 1638847 - AcceptedFreezeException (Final) - this is accepted to make sure ostree-based installs work correctly from day 1
18:12:06 <contyk> ack
18:12:17 <bcotton> ack
18:12:53 <sgallagh> ack
18:13:05 <adamw> #agreed 1638847 - AcceptedFreezeException (Final) - this is accepted to make sure ostree-based installs work correctly from day 1
18:13:12 <adamw> #topic End of proposed FEs
18:13:16 <adamw> OK, that's all the proposed FEs
18:13:19 <adamw> moving onto accepted blockers
18:13:35 <adamw> gonna skip straightforward ones
18:13:42 <adamw> #topic (1616167) dnf doesn't record modular metadata in a local database
18:13:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1616167
18:13:42 <adamw> #info Accepted Blocker, dnf, NEW
18:13:54 <adamw> so...this has been poked back to fesco, but we should probably mention it here as well
18:13:56 <contyk> FESCo agreed to drop the blocker requirement here
18:14:01 <adamw> oh, that happened already?
18:14:12 <contyk> yes, just before this meeting
18:14:19 <adamw> so we're just gonna ¯\_(ツ)_/¯ it?
18:14:20 <adamw> excellent
18:14:31 <contyk> I wouldn't use those words
18:14:34 * sgallagh goes off into a corner and cries some more.
18:14:37 <adamw> i would. :P
18:14:47 <adamw> i'm the cheeky one who tells it like it is
18:14:49 <adamw> i'm allowed to
18:15:05 <bcotton> too bad we're not still naming releases. ¯\_(ツ)_/¯ would be a great release name
18:15:30 <sgallagh> bcotton: Oh sure. Then we get to deal with unicode in /etc/os-release issues? NO THANKS
18:15:40 <adamw> #info per https://pagure.io/fesco/issue/1974#comment-536385 , fesco has voted to drop their requirements around this issue for Final, so this should be changed to rejectedblocker at this point
18:15:52 <contyk> did bcotton had to reboot to type that?
18:15:59 <bcotton> contyk++
18:16:05 <sgallagh> contyk++
18:16:13 <adamw> proposed #agreed unofficial name: Fedora 29 ¯\_(ツ)_/¯
18:16:19 <bcotton> ack
18:16:30 * sgallagh is tempted
18:16:30 <adamw> :P
18:17:02 <adamw> #topic (1632177) dnf segfault in libdnf::TransactionItem::saveReplacedBy()
18:17:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1632177
18:17:02 <adamw> #info Accepted Blocker, dnf, NEW
18:18:06 <adamw> we are basically waiting on dnf team here
18:18:15 <adamw> they do not seem to have tagged the 4.0.4 update as fixing this
18:18:24 <adamw> #info we are still waiting on a fix from the developers here
18:18:36 <adamw> anyone dispute the in-bug vote, btw?
18:18:46 <contyk> not really
18:19:39 <bcotton> no objections here
18:22:08 <adamw> ok
18:22:16 <adamw> #topic (1630899) unmounting ISO in Nautilus crashes gnome-shell and kills a wayland session
18:22:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1630899
18:22:17 <adamw> #info Accepted Blocker, gnome-shell, NEW
18:22:22 <adamw> kparal wanted to bring this one up
18:22:36 <kparal> yeah, we can probably close it
18:23:31 <adamw> might be a timing issue, perhaps
18:23:36 <adamw> since others couldn't always reproduce it all along
18:23:55 <adamw> but...i'm fine with making it not a blocker if it's no longer reliably reproducible at least...and whether to close it would be up to you
18:24:05 <adamw> so, let's revote this one: i'm now -1
18:24:07 <adamw> other votes?
18:24:12 <bcotton> -1 blocker
18:24:12 <Southern_Gentlem> -1
18:24:14 <kparal> -1
18:24:45 <sgallagh> -1
18:24:47 <kparal> well, I can just close it as fixed perhaps, no need to vote
18:24:53 <kparal> either way
18:26:50 <adamw> i'm not really 100% sure it's *fixed*, is the thing...
18:26:52 <adamw> anyway
18:27:16 <adamw> proposed #agreed 1630899 - RejectedBlocker (Final) - this no longer seems to be reliably reproducible. we are not sure that it is fixed, but it at least no longer seems to have sufficient impact to be a blocker bug
18:28:03 <contyk> ack
18:28:11 <bcotton> ack
18:28:19 <sgallagh> ack
18:28:43 <kparal> ack
18:28:44 <adamw> #agreed 1630899 - RejectedBlocker (Final) - this no longer seems to be reliably reproducible. we are not sure that it is fixed, but it at least no longer seems to have sufficient impact to be a blocker bug
18:28:51 <adamw> that way we're covered wahtever. :)
18:29:36 <adamw> #topic (1633786) SELinux is preventing (boltd) from 'create' accesses on the directory boltd.
18:29:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1633786
18:29:37 <adamw> #info Accepted Blocker, selinux-policy, MODIFIED
18:29:53 <adamw> so...this is MODIFIED, and there's been an selinux-policy build, but cmurf reports he's still seeing similar denials
18:29:59 <cmurf> I noted two straglers on this
18:30:19 <kparal> I'm also still seeing some boltd denials
18:30:32 <kparal> but I haven't installed the new build yet :)
18:30:45 * kparal facepalms himself
18:31:06 <cmurf> a new boltd or a new selinux policy?
18:31:08 <adamw> so i think we should definitely block on any remaining denials that produce notifications in the same way
18:31:24 <kparal> I'm just confused why this was accepted as a blocker
18:31:26 <adamw> there's a -39 now...
18:31:27 <adamw> https://koji.fedoraproject.org/koji/buildinfo?buildID=1153617
18:31:32 <adamw> kparal: selinux denial notification
18:31:34 <kparal> because setroubleshoot is no longer installed by default
18:31:39 <kparal> so you see no notifications
18:31:45 <cmurf> oic
18:31:47 <adamw> people said they were seeing them
18:31:52 <adamw> that was the basis for the vote...
18:31:53 <kparal> interesting
18:31:55 <cmurf> so is -39 going to be in u-t soon?
18:32:02 <adamw> i have a recent live here, let me see
18:32:08 <kparal> I wonder where they come from, I had to install setroubleshoot myself
18:32:13 * sgallagh is still seeing at least one boltd denial on -37
18:32:13 <kparal> or they used an upgraded system
18:32:17 <jlanda> kparal: it was a fc27-> fc29 upgrade
18:32:28 <cmurf> i'm using an upgraded system
18:32:34 <kparal> that explains
18:32:43 <jlanda> default system upgrade, do it should meet all criteria
18:32:51 <jlanda> /s/do/so
18:32:54 <cmurf> but is it the existence of setroubleshoot that causes the notifications in GNOME?
18:33:02 <kparal> yes, it has an applet
18:33:10 * adamw checks how the ootb install works
18:33:12 <cmurf> i really wish things that put up notifications were logged
18:33:13 <jlanda> not, but the criteria is about seeing the notification on desktop
18:33:36 <jlanda> so no throubleshooting applet no criteria violation
18:33:57 <kparal> I'm not sure it's a good idea, but it is according the current criterion wording
18:34:27 <adamw> the 'upgrade must meet all other criteria' requirement is pretty nuclear
18:34:32 <adamw> we do not always entirely honour it, i suspect
18:34:39 <jlanda> yeah, hiding it is not a fix
18:34:43 <kparal> right, that in fact makes this a blocker :)
18:34:45 <adamw> but let's at least propose all the known ones as FEs
18:34:49 <kparal> I forget about that
18:34:51 <cmurf> so selinux bugs will increasingly end up not being filed through attrition
18:34:54 <adamw> jlanda: it absolutely *is* a fix to the requirement :)
18:35:06 <cmurf> well, bugs that trigger notifications, generally
18:35:13 <adamw> the criterion is about the "look" of booting the system and seeing a notification that something went wrong
18:35:16 <adamw> that's what we want to avoid
18:35:22 <kparal> cmurf: correct
18:35:25 <adamw> it's not necessarily that we assume all AVCs are terrible bugs
18:35:30 <cmurf> right, I get 3 alerts on every login
18:35:37 <jlanda> adamw: yep, sure for non-blocking, but absolutly no to fix de issue itself
18:36:07 <adamw> so. uh
18:36:21 <cmurf> I know there is a PRD item that says upgrades should result in an identical system as clean installed, but the PRD is not part of release criteria
18:36:26 <adamw> can you guys at least ensure all other boltd-related issues you're hitting are reported as bugs and propose them as FEs?
18:36:47 <cmurf> i see no other boltd related bugs
18:36:49 <adamw> cmurf: " The upgraded system must meet all release criteria."
18:36:53 <jlanda> it's possible and want we uninstall a package on a upgrade?
18:36:59 <adamw> cmurf: the two you mentioned aren't proposed FE, AFAICS.
18:37:03 <kparal> jlanda: not possible atm
18:37:14 <adamw> well, not without obsoleting it, which obviously isn't wanted.
18:37:19 <adamw> cmurf: https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria#Upgrade_requirements
18:37:28 <cmurf> yeah I know
18:37:34 <cmurf> and I understand that it is a blocker because of that
18:37:41 <adamw> well, we didn't actually discuss that angle
18:37:45 <cmurf> but what's funny is it's only a blocker on upgrades
18:37:46 <jlanda> so then the unique way to make the issue unblocking is fixing it ;)
18:37:47 <adamw> if we did i suspect we might've fudged it
18:37:54 <adamw> but anyway, point is, let's get these fixed if we can
18:38:01 <cmurf> because only on upgrades do you get a notification in teh GUI
18:38:05 <adamw> we at least need the bugs marked as proposed FEs to get the latest selinux-policy update in
18:38:16 <adamw> i will poke lukas to do a build with all the fixes he can manage, and submit an update
18:38:30 <cmurf> ok so it's not fixed in -38 or -39?
18:38:34 <adamw> cmurf: i don't kniw
18:38:39 <adamw> but neither of those is in stable
18:38:43 <cmurf> I only have -37, I don't see -38 or -39 in bodhi
18:38:54 <cmurf> well I have u-t enabled and  38 and 39 do not show up
18:39:02 <adamw> they're in koji
18:39:16 <adamw> but what i'm saying is
18:39:18 <adamw> install -39
18:39:18 <adamw> test
18:39:25 <adamw> if anything is still notifying, file a bug, and propose it as an FE
18:39:31 <jlanda> and could be in lukas' copr? i haven't checked
18:40:37 <adamw> #info some related fixes are in selinux-policy -38 and -39, but no update has yet been submitted. cmurf and kparal will see if any AVCs persist in -39. adamwill will ask lukas to submit an update
18:40:49 <cmurf> ack
18:41:34 <adamw> OK
18:41:39 * bcotton has to drop
18:41:41 <adamw> #info end of accepted blockers
18:41:49 <adamw> #topic Open floor
18:41:54 <adamw> so, we have one significant thing to talk about here
18:42:03 <adamw> #topic Open floor: DNF rebase to 4.0
18:42:23 <adamw> so, as the topic says, to fix various blockers and FEs, DNF team sent us an update which includes new major releases of DNF and libdnf
18:42:49 <adamw> #info as a fix for various blocker and FE issues, DNF team has submitted an update containing major new releases of DNF and libdnf: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
18:43:17 <contyk> they claim it's not a major update, they just wanted to bump the number for no reason
18:43:26 <contyk> I don't know whether that's true or what to think
18:43:51 <adamw> #info this goes fairly strongly against the policy that, during freezes, only changes to fix FE and blocker issues should be made
18:44:03 <adamw> we have been quite sloppy at enforcing that for a while, but at some point you gotta draw a line
18:44:14 <contyk> ¯\_(ツ)_/¯
18:44:33 <jlanda> does the new version fix all the FE and blockers?
18:44:34 <adamw> contyk: it depends a lot on how you define 'major', but it *certainly* includes lots of changes that are not for the purpose of fixing F29 blocker or FE bugs (or even for fixing other serious bugs)
18:44:47 <adamw> jlanda: doesn't fix #1632177, as we just noted
18:45:05 <sgallagh> In other words, it might not be a backwards-incompatible change, but i'ts still a large rebase
18:45:11 <adamw> you can see dnf commits at https://github.com/rpm-software-management/dnf/commits and libdnf commits at https://github.com/rpm-software-management/libdnf/commits
18:45:52 <adamw> we have dnf 3.6.1 in stable, so all the commits from "Do not handle defaults profiles if they are absent (RhBug:1628156)" (on page 2) onwards are new to f29
18:46:13 <adamw> including stuff like 'an an entire new dnssec extension'
18:47:09 <adamw> similarly for libdnf, we have 0.20.0 in stable
18:47:18 <adamw> so everything from "Rename dnf_repo_is_repo to dnf_repo_is_source" onwards is new
18:47:36 <jlanda> well, it's clearly againt thr policiy you cited
18:47:48 <adamw> so, i wanted to flag this up.
18:48:13 <adamw> do we just roll over and take it? do we ask for 3.6.x / 0.20.x branches/releases with more targeted sets of changes? i dunno.
18:48:56 <bcotton> i think in the ideal world, we ask for fixes backported to the branches we currently have. the question is what can we get in reality?
18:49:16 <adamw> that is indeed a question
18:50:01 <bcotton> mattdm: you around?
18:50:25 <jlanda> and can our ask delay the fix for #1632177
18:50:31 <jlanda> ?
18:52:16 <cmurf> haha didn't we start with dnf 2 at branch for F29? And we've blown through v 3.x during testing?
18:52:32 <adamw> yeah,
18:52:34 <cmurf> or was dnf 3 already in rawhide?
18:52:45 <bcotton> we were at 2 at the branch, i think
18:53:41 <adamw> so, seems like we're kinda flagging here
18:53:43 <bcotton> so i'm not sure this is a question we can answer in this meeting. seems like something that should get kicked upstairs to FESCo/FPL?
18:53:57 <adamw> for something like dnf in this release, probably, yeah.
18:53:58 <cmurf> maybe the argument for 4.x is that 3.x hasn't even had time to get very stable and it's a way to just kinda sweep that version under the carpet
18:54:03 <cmurf> i agree with bcotton
18:54:10 <bcotton> dnf 3: like it never even happened
18:54:10 <adamw> cmurf: i am not getting hung up on the numbers
18:54:27 <adamw> i don't care if it's called 3.7 or 4.0 or 3.6.1.1, the point is the actual changes it contains
18:54:28 <cmurf> numbers have connotation
18:54:39 <adamw> but you can also just go look at the damn commit log.
18:55:00 <bcotton> right. the problem is the process, regardless of what number they put on it
18:55:18 <adamw> #info adamw will file a FESCo ticket asking them to consider if we should take dnf 4.0 / libdnf 0.22 for f29, or ask for 3.6 / 0.20 branches with more targeted blocker/fe fixes
18:55:18 <bcotton> process and impact, i guess
18:55:30 <adamw> #topic Open floor
18:55:32 <adamw> ok, any other business?
18:55:34 <bcotton> adamw++
18:55:36 <jlanda> last week we run dnf test day with 3.4? not we are on 3.6 and talking about 4.0
18:55:41 <jlanda> adamw++
18:55:41 <zodbot> jlanda: Karma for adamwill changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:55:45 <coremodule> adamw++
18:55:45 <zodbot> coremodule: Karma for adamwill changed to 11 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:55:52 <coremodule> thanks for running this on your day off adamw
18:56:00 <jlanda> have nice vacatioms adamw ;)
18:56:08 <bcotton> adamw: tag me in that issue and i'll follow along while you're absolutely not checking your work email on vacation
18:56:43 <contyk> adamw++
18:56:43 <zodbot> contyk: Karma for adamwill changed to 12 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:56:45 <coremodule> adamw: will you send out those instructions mentioned at the beginning of the meeting for while you're away?
18:57:34 <adamw> yeah, i will.
18:57:48 <adamw> i'll probably catch up on all this stuff when i'm at the airport in a bit.
18:58:13 <coremodule> sounds good, thanks.
18:58:24 <Southern_Gentlem> adamw++
18:58:25 <zodbot> Southern_Gentlem: Karma for adamwill changed to 13 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:59:18 <Southern_Gentlem> adamw, have a good vacation (yes everything will blow up, but that will not be your issue)
18:59:43 <cmurf> haha everything will blow up
18:59:56 <adamw> =)
18:59:56 <kparal> adamw: enjoy your vacation
19:00:01 <adamw> thanks everyone
19:00:04 <adamw> sorry for the apparently short notice
19:00:21 <jlanda> for blowing this up? you're welcomd
19:00:36 <kparal> throw them into water, they'll learn how to swim
19:00:38 <adamw> =)
19:00:48 <adamw> i have my laptop, i'll be checking in
19:00:56 <cmurf> throw it into the water!
19:01:01 <adamw> i'll be in japan/taiwan timezones, btw
19:01:07 <adamw> see you layer
19:01:10 <adamw> later*
19:01:14 <adamw> #endmeeting