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