15:13:51 #startmeeting Fedora QA Meeting 15:13:51 Meeting started Mon Jun 17 15:13:51 2019 UTC. 15:13:51 This meeting is logged and archived in a public location. 15:13:51 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:13:51 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:13:51 The meeting name has been set to 'fedora_qa_meeting' 15:13:53 #meetingname fedora-qa 15:13:53 The meeting name has been set to 'fedora-qa' 15:13:55 #topic Roll call 15:14:01 anyone still around? :) 15:14:04 yep 15:14:28 jskladan, frantisekz and lbrabec are also mostly here 15:14:38 meeting in the birch room :) 15:14:53 ah, the good old birch room 15:15:00 such a good place for...meetings... 15:15:22 exactly! 15:15:34 * satellit listening 15:16:21 .hello2 15:16:22 lruzicka: lruzicka 'Lukáš Růžička' 15:16:54 alrighty 15:17:05 #topic Previous meeting follow-up 15:18:23 "lailah to propose KDE system settings crash as F31 blocker" - I don't see that this has happened yet... 15:18:25 * cmurf is in the ether 15:18:57 well stop that and get out of it immediately 15:20:10 #info "lailah to propose KDE system settings crash as F31 blocker" - this doesn't seem to have happened yet, we will follow up with lailah outside of the meeting 15:20:14 any other followups from last time? 15:21:17 i guess not 15:21:20 #topic Fedora 31 status 15:21:45 so...i'd say right now F31 status is "a mess" 15:21:51 haha 15:21:52 LOL 15:22:01 i was JUST about to say, hmmm, something's wrong, I'm not finding any bugs 15:22:05 (in rawhide) 15:22:19 maybe I'm behind 40 updates... 15:22:33 well 15:22:40 it's more that there aren't any updates because composes are failing... 15:23:23 well that'd explain it 15:23:48 especially the modularity failures are painful 15:23:48 dnf update shows some libgit module problems, and 219MB of updates otherwise 15:23:48 * satellit seeing many partial composes.... 15:23:54 composes have been failing lately due to various issues with compose tools being ported to python3 for the first time 15:24:11 I mean the problem cmurf is mentioning 15:24:14 #info Rawhide composes have been failing lately due to various issues with compose tools being ported to python3 for the first time 15:24:18 yes 15:25:37 #info the libgit2 modularity dependency issue - https://bugzilla.redhat.com/show_bug.cgi?id=1717117 - breaks network installs at present and is annoying for existing installs 15:26:07 however it only affects netinstalls, at least last week that wy 15:26:08 yeah i haven't done an update because i can't parse that message 15:26:11 was the case 15:26:30 cmurf: as best as i can tell, dnf is basically warning about dependency issues in default module streams any time you do *anything* with dnf 15:26:38 it'll show the message even if you just do a 'dnf search' or a 'dnf info' 15:26:49 so if the transaction you actually want to run doesn't involve those modules, i think it's ok to ignore the message 15:27:15 ahh yes it does 15:27:20 lruzicka: well, other installs aren't affected just because the bits they have are from before the problem showed up. 15:27:55 i did my rawhide install with netinstall, must've been right before this problem showed up 15:27:56 i'm curious what happens when we get a compose past the python3 issues actually. i suspect either the module bug itself will fail the compose of one or more images, or we'll get images that fail to install because of it...but we'll see 15:27:58 adamw, all right ... seems plausible 15:28:17 cmurf: if you try a test one again right now it ought to crash, it does for openqa, lruzicka and me :) 15:28:26 well, more 'abort' than 'crash' 15:28:40 that's ok i'll take a pass 15:28:48 we don't branch for another couple of months, so there's time to sort this all out, but...it's kinda ugly 15:29:00 indeed 15:29:55 any other notes on F31 in general? 15:30:34 several arm builds for RPi3B+ work (spins) 15:31:33 that's good i guess? were they not working before? 15:32:01 f30 worked rawhide had kernel problems 15:32:30 been working through bluetooth kernel problems 15:32:36 that's affected both f30 and rawhide 15:32:49 there was a kernel issue up until 5.2 rc2+ on armhfp 15:32:50 satellit: ah ok, so i guess that's good news 15:33:11 #info early 5.2 kernels were causing problems for F31 ARM images but these now seem to be resolved 15:33:12 * satellit FYI testing: https://wiki.sugarlabs.org/go/Fedora_31#.3C-Pass-.3E 15:33:47 the bluetooth issues have been reverted by Fedora kernel dev team and now upstream as well 15:34:03 oop, i'll brb...call of nature... 15:36:02 * cmurf wonders if it that's a prank call 15:36:29 nature has a hilarious sense of humor 15:37:21 let's just skate right over that huh 15:37:24 #topic Modularity stream dependency problems (libgit2) 15:37:34 so, yeah, i put a specific topic for this mess on the agenda. what with it being so...messy 15:38:30 the bug again is https://bugzilla.redhat.com/show_bug.cgi?id=1717117 , there is a fesco ticket also at https://pagure.io/fesco/issue/2146 15:40:46 egads 15:41:53 it's an awkward issue...but basically it seems that modules aren't supposed to change from depending on one stream of another module to depending on a different stream of that same module 15:42:15 which turns out to be not very compatible with what the libgit2 maintainer was trying to do by putting libgit2 into modules 15:42:28 but this is just the first time we hit such a problem, it seems fairly likely we'll hit it in other contexts too 15:42:38 it looks like corner cases jumping out of the cabinet like skeletons. 15:43:06 i wonder if they're not corner cases 15:43:09 Modules look pretty easy the first time you look, but calm waters are deep 15:43:19 exactly 15:43:36 oh yeah, there'll be tons of stuff like this 15:43:39 it was always gonna happen 15:43:52 might've been nice if we'd thought about it a bit earlier, but...i guess none of us did :/ 15:44:04 sgallagh: ping? got any thoughts/insight/news on this? 15:44:53 Give me a couple minutes 15:45:49 adamw: The core problem is that the public packaging guidelines are missing a key sentence. 15:46:09 is that sentence "BTW don't use modules"? 15:46:39 adamw: I'd appreciate it if you, at least, didn't shit all over two years of me getting not enough sleep. 15:46:49 sorry, it was just a bad joke, no harm intended 15:47:08 I've been getting attacked personally a lot over this, so I'm not feeling terribly jobial 15:47:11 *jovial 15:47:38 The dependencies of a stream are part of the definition of that stream. 15:47:50 Changing them therefore requires a new stream. 15:48:06 This was a core tenet of the implementation from day one, and somehow we failed to include that in the guidelines. 15:48:22 Now we're dealing with that oversight. 15:48:26 okay. 15:49:04 sgallagh, may I ask whether there is a follow-up on that UIX meeting we had? I could not attent the next meeting, because it was quite late. 15:49:09 sgallagh, what is the result? 15:49:11 libgit2 should never have been made a module, because its upstream behavior is incompatible with modularity. 15:49:26 this does seem like it's kind of untenable for long-term maintenance, though, if combined with version-based streams? 15:49:41 without assuming manual intervention by the system admin to switch streams 15:49:49 Which is why we've been trying to be louder about explaining that streams have to be functionality-based, not version-based. 15:49:53 ah, okay. 15:50:06 Of course, for libgit2, that's the same thing 15:50:14 Because they BREAK ABI EVERY MINOR RELEASE. 15:50:14 i definitely remember some of the initial explanations of modularity using version-based streams as examples 15:50:24 if i'm not misremembering that...perhaps that may be part of the confusion? 15:50:32 adamw: We did, but they were specifically semver examples 15:50:52 Because semver mandates functional compatibility at Y releases 15:51:17 okay, so 15:51:36 it sounds like the guidelines need to be improved 15:51:46 Realistically, libgit2 should not be a version-based module. 15:51:52 and possibly someone should look through existing modules for ones that look like they might get into this situation in future? 15:52:17 IF they want it to be modularized, they should have it provide libgitX and libgitX+1 as a "rolling" stream, keeping one previous version around each time. 15:52:41 right, call the streams 'current' and 'previous' or whatever. 15:52:49 No, you misunderstand 15:52:53 A single stream providing both. 15:53:00 oh i see 15:53:03 alright 15:53:06 The latest including the -devel package, plus a compat one for just runtime 15:53:35 Sonar_Gal: does this mean we need better procedures around approving default stream modules? since libgit2 got approved as a default stream module *with this problematic setup* 15:54:01 heh 15:54:08 maybe, we could do with not only the guidelines, but also some examples of good practices ... and some "use cases" alike? 15:54:08 Sonar_Gal: sorry, that was meant to be just "so:" 15:54:19 yeah, some do's and don'ts 15:54:23 this being a great 'don't' :P 15:55:45 adamw: That one was my fault. I didn't realize libgit2 had such a short lifespan or I'd have not approved it as a default stream. 15:55:53 okay 15:55:57 so i guess this is a learning experience 15:56:02 We probably need to come up with a questionnaire of some sort 15:56:28 Question, is there a fedora modularity group similar to the fedora packaging group or fesco where modules need to be reviewed and approved like a package would? [and if there is take it that I had not seen in like I had seen those] 15:57:19 There's a Modularity WG that meets weekly. And yes, probably we should ask FESCo to make that an official duty. 15:57:25 Good thought. 15:57:33 not a general group like : I am working on the backend of mbs,etc but something which does more like package reviews and 15:57:44 Up to now, it's mainly been just me or mboddu making the decision. 15:58:05 smooge: Maybe I'm not following. 15:58:23 sorry that was me thinking I hit control-a to remove and hitting enter instead 15:58:32 We used to do full reviews, but we determined that it was unnecessary overhead, since the main purpose of most reviews is for legal compliance. 15:58:52 But since modules contain only content already reviewed for legal compliance, it was excess effort. 15:59:06 anyway, we don't need to solve the whole problem here and we're about to hit time 15:59:10 thanks for all the info, sgallagh 15:59:20 sgallagh, any result of UX meeting? 15:59:21 Any time 15:59:22 well most of the package reviews I have had have been on package needs and layout and does this need to be in this subpackage or not. 15:59:50 sorry thanks adamw for my side conversation. I should do it out of meeting 15:59:50 lruzicka: The follow-up didn't have quorum, others were responsible for rescheduling it; they haven't. 16:00:10 my inclination for the QA team here is that we don't need to do anything specific right now, there is a lot of heat going on but folks are already working towards a solution and ways to improve the guidelines and processes in future 16:00:13 ok, so it is possible I am getting an invite, too, if rescheduled? 16:00:16 thanks 16:00:49 sgallagh ^ 16:01:12 Yes 16:01:28 #info sgallagh tells us that the module guidelines are supposed to state that a module stream cannot change to depending on a different version of another module stream during its lifetime - this is supposed to be a core requirement - but that was left out; this is a major contributor to the current problem 16:02:41 #info obviously with that restriction in mind, libgit2 should not be a module with version-based streams since it changes ABI with each minor release. libgit2 should either not be modularized or should be modularized with a different stream setup 16:03:19 #info sgallagh says the modularity folks will work to improve the guidelines and look at reviews of modules in general and new default stream modules to try and avoid this kind of problem in future 16:03:36 sgallagh: is it allowed for a module stream to *add* or *remove* a dependency on another module stream? 16:04:44 adamw: Undefined right now. (Officially, "no", but we're looking at whether we can do one or the other cleanly.) 16:05:13 okay. 16:05:26 we're over time now, so we can kick this around elsewhere i guess :) 16:05:28 #topic Open floor 16:05:34 anyone have anything terribly important for open floor? 16:05:41 nothing from me 16:06:26 and not ffom me 16:06:52 alllrighty 16:06:55 thanks for coming, folks 16:06:58 sorry for the lateness 16:07:09 adamw: thanks for running the meeting 16:07:17 its monday lateness is expected 16:07:17 i've got a Fedora Media Writer breakage issue, i'll bring it up on #fedora-qa 16:07:30 cmurf: oh yeah i saw you filed something about that somewhere, but didn't quite grok it 16:07:34 #endmeeting