16:00:39 #startmeeting F29-blocker-review 16:00:39 Meeting started Mon Aug 20 16:00:39 2018 UTC. 16:00:39 This meeting is logged and archived in a public location. 16:00:39 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:39 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:39 The meeting name has been set to 'f29-blocker-review' 16:00:39 #meetingname F29-blocker-review 16:00:39 #topic Roll Call 16:00:39 The meeting name has been set to 'f29-blocker-review' 16:00:56 ahoyhoy folks, who's around for some blocker reviewing fun? 16:01:05 oh boy! 16:01:07 * Tenk is here 16:01:13 YES COREMODULE THIS TIME FUN IS PROMISED 16:01:16 hi tenk 16:01:18 hi coremodule 16:01:29 Hello, everybody. 16:01:35 .hello2 16:01:35 lruzicka: lruzicka 'Lukáš Růžička' 16:01:51 I'm so ready for fun 16:02:06 .hello2 16:02:07 frantisekz: frantisekz 'František Zatloukal' 16:03:20 line up the usual suspects 16:03:55 mboddu: nirik: satellit: sgallagh: pwhalen: feel like some blocker reviewing fun? 16:04:17 * nirik still in fesco meeting, will stick to one meeting at a time. :) 16:05:04 .hello2 16:05:04 bcotton: bcotton 'Ben Cotton' 16:05:05 * adamw infiltrates fesco meeting 16:05:08 hi bcotton 16:05:13 hello, adamw 16:05:40 welp, i guess we can get started 16:05:49 #chair lruzicka coremodule 16:05:49 Current chairs: adamw coremodule lruzicka 16:05:58 #topic Introduction 16:05:58 Why are we here? 16:05:58 #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:05:58 #info We'll be following the process outlined at: 16:05:58 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:05:59 #info The bugs up for review today are available at: 16:06:01 #link http://qa.fedoraproject.org/blockerbugs/current 16:06:03 #info The criteria for release blocking bugs can be found at: 16:06:07 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:06:09 #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria 16:06:11 #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria 16:06:13 we have: 16:06:17 #info 9 Proposed Blockers 16:06:17 #info 3 Accepted Blockers 16:06:23 #info 1 Proposed Freeze Exceptions 16:06:23 #info 1 Accepted Freeze Exceptions 16:06:25 (all for Beta) 16:07:00 who wants to secretarialize? 16:07:24 wants to? 16:07:29 I'll do the dirty work 16:07:31 :P 16:08:50 #info coremodule will secretarialize 16:08:53 thanks coremodule! 16:09:12 starting with proposed blockers: 16:09:12 #topic (1615586) segfault in ns-slapd during FreeIPA server deployment (or post-deployment operation) on Rawhide 16:09:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1615586 16:09:13 #info Proposed Blocker, 389-ds-base, ON_QA 16:09:30 this is very likely fixed by now, just it's been hard to tell due to other bugs in f29/rawhide confusing things 16:09:33 but still, let's review it! 16:09:45 since it almost always breaks something in the freeipa criteria - +1 16:11:09 Sorry, my connection went down for a moment. 16:11:21 +1 16:11:59 np lruzicka 16:12:25 As far as 1615586 is concerned, I would say +1 16:13:36 proposed #agreed 1615586 - AcceptedBlocker (Beta) - accepted as a violation of Basic criterion "It must be possible to configure a Fedora Server system installed according to the above criteria as a FreeIPA domain controller, using the official deployment tools provided in the distribution FreeIPA packages. Once deployed, the system must handle multiple client enrolments and unenrolments, and client authentication via Kerberos..." 16:13:51 ack 16:13:56 ack 16:14:20 ack 16:14:27 #agreed 1615586 - AcceptedBlocker (Beta) - accepted as a violation of Basic criterion "It must be possible to configure a Fedora Server system installed according to the above criteria as a FreeIPA domain controller, using the official deployment tools provided in the distribution FreeIPA packages. Once deployed, the system must handle multiple client enrolments and unenrolments, and client authentication via Kerberos..." 16:14:46 #topic (1596540) RuntimeError: C++ std::exception: Exec failed: no such table: main.trans_cmdline 16:14:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1596540 16:14:47 #info Proposed Blocker, dnf, NEW 16:17:38 this is one of those kinda messy dnf bugs 16:17:52 it does seem like dnf 3 has some issues with some people's history files... 16:18:18 hard to tell if it ought to be a blocker, i *am* a bit concerned we might have an undesirable number of people run into this kinda thing on upgrade 16:18:21 anyone have any thoughts? 16:19:42 well, I think it has to be a blocker, unless there is a documented workaround in known bugs ... 16:21:04 Even, if the bug will not happen in all people's machines, it is a painful thing for those affected 16:21:11 true... 16:21:17 i can imagine dnf team saying it's hard to debug, though... 16:21:25 but need to be blocker? 16:21:44 i do wish we had some more input from them on these bugs 16:22:00 proposal: punt for now, directly request input from dnf team? 16:22:12 adamw, yeah, we can do taht 16:22:49 could be a good compromise 16:23:26 frantisekz? 16:24:15 punt for me , I think we should get more data to have some idea on how many % of people are affected :) 16:24:54 ok 16:25:56 proposed #agreed 1596540 - punt - we are worried about this and similar bugs that seem to affect some but not other users on upgrade to DNF 3, but do not have sufficient information yet to make a good decision on whether they should be blockers. we will directly request evaluation of this by dnf team and discuss it again after that 16:26:08 ack 16:26:11 ack 16:26:14 ack 16:26:31 #agreed 1596540 - punt - we are worried about this and similar bugs that seem to affect some but not other users on upgrade to DNF 3, but do not have sufficient information yet to make a good decision on whether they should be blockers. we will directly request evaluation of this by dnf team and discuss it again after that 16:26:43 #topic (1598336) dnf no longer understands its repository configuration 16:26:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1598336 16:26:43 #info Proposed Blocker, dnf, NEW 16:27:10 I would say -1 here, since it is probably language related 16:27:24 i was gonna say +1 for the same reason, heh 16:27:29 if an entire language can't update... 16:27:38 still, does mean there's an 'easy' workaround, i guess 16:28:05 frankly it seems worrying that dnf team has not even responded to such an 'obvious' bug after a month and a half, too 16:29:06 -1 can t block a beta for this. +1 final perhaps 16:29:37 I think I can drop in at the dnf team and ask them about it 16:29:55 And agree with Tenlk 16:29:56 yeah, maybe just in general say 'hey, can you take a look at fedora dnf 3 bugs' 16:29:57 Tenk 16:30:19 i can agree with -1 for beta, i guess, 'use LC_ALL=C' or whatever is ok for beta users 16:30:31 adamw, I can. I have discussed one bug with them already, it is on the line, so no need to prolong this one, though 16:30:38 thanks 16:31:43 lruzicka: frantisekz: what do you vote for Final on this one? 16:31:58 +1, I said I would agree with Tenk 16:32:20 +1 for Final :) 16:33:05 alright 16:34:31 proposed #agreed 1598336 - RejectedBlocker (Beta) AcceptedBlocker (Final) - we agreed that this is a conditional violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated.", affecting Swedish installs (and possibly others). we agreed that 16:34:31 using LC_ALL is an acceptable workaround for Beta but not for Final 16:34:33 grr 16:35:06 proposed #agreed 1598336 - RejectedBlocker (Beta) AcceptedBlocker (Final) - we agreed that this is a conditional violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager)...", affecting Swedish installs (and possibly others) and that using LC_ALL is an acceptable workaround for Beta but not for Final 16:35:17 ack 16:35:22 ack 16:35:25 ack 16:35:46 adamw: Sorry, I am dragged into several other discussions and work 16:35:59 well now i'm dragging you in here :) 16:36:02 #agreed 1598336 - RejectedBlocker (Beta) AcceptedBlocker (Final) - we agreed that this is a conditional violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager)...", affecting Swedish installs (and possibly others) and that using LC_ALL is an acceptable workaround for Beta but not for Final 16:36:35 #topic (1616118) DNF update fails with "cannot install the best update candidate for package" 16:36:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1616118 16:36:36 #info Proposed Blocker, dnf, NEW 16:37:34 sgallagh: if we can grab you just for a sec - this is still valid? 16:38:12 Yes, such messages really do appear on F29 16:38:39 I have updated today and have been seeing them since then. 16:38:43 i mean, in this specific situation 16:39:10 well 16:39:23 i guess if you're getting these messages referring to module packages, it's the same bug 16:39:25 adamw, when calling dnf update, yes 16:39:46 as sgallagh says, it's a bit questionable whether this really violates the criterion 16:39:57 i think i'd probably vote same as last bug - -1 Beta, +1 Final 16:40:06 adamw, confirmed ... I can also confirm that once you enable the module, the message for that module goes away 16:40:15 ah, good triage 16:40:26 not the module, the message 16:40:58 adamw, I have experienced this with gimp, which is only available from a modular repo. 16:41:27 As soon as I enabled gimp, the message for gimp stopped appearing 16:41:35 others still do 16:41:39 yeah, i get it 16:41:46 adamw, ok :) 16:41:51 so, votes? 16:42:04 -1 beta, +1 final 16:42:17 -1 beta, +1 final 16:42:33 -1 beta, +1 final 16:45:06 proposed #agreed 1616118 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this bug seems mostly cosmetic, it doesn't actually cause any packages to be wrongly updated (or not updated), but it's likely to affect many users and looks bad. We agreed it is a Final blocker as a conditional violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software 16:45:06 type" 16:45:18 that'll work, with the 'proposed' removed. :P 16:46:22 ack 16:46:28 ack 16:47:08 frantisekz? 16:47:15 ack 16:47:38 #agreed 1616118 - RejectedBlocker (Beta) AcceptedBlocker (Final) - this bug seems mostly cosmetic, it doesn't actually cause any packages to be wrongly updated (or not updated), but it's likely to affect many users and looks bad. We agreed it is a Final blocker as a conditional violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type" 16:47:48 #topic (1616167) dnf doesn't record modular metadata in a local database 16:47:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1616167 16:47:48 #info Proposed Blocker, dnf, NEW 16:48:56 This is the bug I have discusses with the dnf team 16:49:23 they believe that there will not be an easy solution to this one 16:49:33 note, i think "ursine" is the word they're using for "not in a module", right? 16:49:50 yes ... I had that explained by contyk 16:50:13 and apparently, the one in modules would be called canine 16:50:47 +1 for me, as this one really can cause modular packages to be upgraded incorrectly, with unpredictable consequences 16:51:16 but, there might a high potential of this bug not being fixed in time 16:51:26 does it mean, we will hold the release: 16:51:27 ? 16:51:41 that's what blocker means, yes. 16:51:56 adamw, I mean, what if it never gets fixed? 16:52:17 then in theory, we never release. of course, something has to give at some point. but we don't have to decide that now. 16:52:52 well, if modularity is a compulsory feature in F29, than it will have to be a blocker. 16:53:05 so +1 for me 16:53:17 right 16:53:25 if we're turning it on for everyone it better *work* right 16:53:36 so so 16:53:50 +1 16:53:53 +1 16:56:17 proposed #agreed 1616167 - AcceptedBlocker (Beta) - this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type", as it is means an update may be inappropriately installed in a not too unusual scenario 16:56:37 ack 16:57:05 ack 16:58:48 ack 16:58:51 #agreed 1616167 - AcceptedBlocker (Beta) - this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type", as it is means an update may be inappropriately installed in a not too unusual scenario 16:59:06 #topic (1601479) Packaging issues with outdated hub.docker.com fedora:rawhide containers 16:59:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1601479 16:59:07 #info Proposed Blocker, gdbm, NEW 16:59:22 i think we can finally kick this one off the list, since it became clear it had to do with outdated docker container images 16:59:34 which should be fixed, but there's no reason to associate that problem with the f29 release process 16:59:51 yes, -1 for this one 17:00:54 -1 17:01:42 -1 blocker 17:02:45 proposed #agreed 1601479 - RejectedBlocker (Beta) - with latest information it's clear this is to do with outdated container images on the docker.com hub, there is no reason to block Fedora 29 release on it (though obviously we should ensure those images are updated more often) 17:02:51 ack 17:02:53 ack 17:02:56 ack 17:03:19 #agreed 1601479 - RejectedBlocker (Beta) - with latest information it's clear this is to do with outdated container images on the docker.com hub, there is no reason to block Fedora 29 release on it (though obviously we should ensure those images are updated more often) 17:03:28 #topic (1618928) grub2-2.02-50.fc29 shows error/debug messages in pager on x86_64, requires user input to complete boot 17:03:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=1618928 17:03:28 #info Proposed Blocker, grub2, ON_QA 17:03:38 i think we've had confirmation this is fixed in -51, so we can probably just close it. 17:04:38 #info testing has confirmed this is fixed in -51, so we will close the bug 17:04:49 #topic (1619295) nothing provides libpoppler.so.74()(64bit) needed by gdal-libs-2.2.4-7.fc29.x86_64 / libreoffice-pdfimport-1:6.0.6.1-7.fc29.x86_64 17:04:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1619295 17:04:49 #info Proposed Blocker, poppler, NEW 17:06:28 I had that issue, too, but I have used --allow-erasing and could update 17:06:50 I agree, however, that this is rather stupid behaviour 17:07:03 i think we can still +1 it, due to one footnote on the criterion: 17:07:04 "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)." 17:07:15 libreoffice is not obsolete. 17:07:24 presumably --allowerasing removed it 17:07:25 ? 17:07:52 let me check 17:08:51 libreoffice starts in my computer 17:09:55 but pdf import does not work 17:10:10 libreoffice-pdfimport is gone? 17:11:15 cups-filters is probably in a default workstation install too 17:11:26 libpoppler is gone - nothing provides libpoppler 17:11:40 therefore libreoffice-pdfimport cannot be installed 17:11:52 ah, libreoffice-draw requires libreoffice-pdfimport 17:11:56 so draw is probably gone completley 17:12:21 i think we can say we're sufficiently certain this causes some packages that were installed before to be gone. 17:12:28 so, I'm gonna say +1 on that basis. 17:12:41 yes, it seems so 17:13:01 +1 for sure ... and must say, that it upsets me a bit 17:13:05 +1 17:13:21 +1 17:13:51 yeah, i think the poppler maintainer sent out a 'notification' which basically said 'nearly everything rebuilds except these two really important things, but whatever, i'm sending it out anyway" :/ 17:14:31 proposed #agreed 1619295 - AcceptedBlocker (Beta) - this is accepted as a violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed. ... The upgraded system must include all packages that would be present on the system after a default installation 17:14:31 from install media, plus any packages the user previously had (minus any obsolete content)." 17:14:33 gr 17:14:35 trim time 17:15:21 proposed #agreed 1619295 - AcceptedBlocker (Beta) - violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed. ... The upgraded system must include all packages that would be present on the system after a default installation from install media..." 17:16:27 ack 17:16:31 ack 17:17:07 ack 17:17:28 #agreed 1619295 - AcceptedBlocker (Beta) - violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed. ... The upgraded system must include all packages that would be present on the system after a default installation from install media..." 17:17:35 #topic (1616269) [abrt] xorg-x11-server-Xwayland: OsLookupColor(): Display server crashed 17:17:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=1616269 17:17:35 #info Proposed Blocker, xorg-x11-server, NEW 17:17:43 last proposed blocker! 17:18:21 i'm either -1 or punt on this one, all we really know for sure is 'sgallagh's graphics are bust' 17:18:28 which sucks for sgallagh but isn't necessarily a blocker yet... 17:19:19 lbrabec also has problems with graphics, he is unable to get anything graphical started 17:19:31 dont know whether it is this one, though 17:19:36 multiple monitor issues can be blocker? 17:19:50 DevConf got in the way, but last I looked it was either nVidia or hybrid that included nVidia that is affected. 17:20:01 lbrabec cannot even start gdm on his laptop 17:20:12 Also, turns out to sometimes happen on single monitor as well 17:20:30 i remember we had a discussion about it some month (year) ago. 17:20:40 I was having XWayland crashing during the startup, but I was able to start gdm and run sway 17:20:41 ok, i'd say we still need to identify with some kinda precision what the affected configurations are 17:20:49 all nvidia? all hybrid nvidia? some particular ones? 17:20:54 Please punt and I’ll try to get info for next week 17:20:55 mine is intell 17:20:57 rgr, thanks 17:21:22 so +1 punt 17:22:25 proposed #agreed 1616269 - punt (delay decision) - we're not yet sure of just how many systems are likely to be affected by this, we need to figure out more precisely what the affected configurations are. sgallagh has volunteered to try and gather some more data by next week 17:22:29 another report on #fedora-qa just now 17:22:35 ack 17:23:11 ack for punt, but it seems really annoying 17:23:19 ack 17:23:37 jlanda, yes, handsome_pirate is complaining about it 17:26:08 well, *possibly* the same thing. that's part of the problem... 17:26:13 anyhow, we have acks 17:26:18 #agreed 1616269 - punt (delay decision) - we're not yet sure of just how many systems are likely to be affected by this, we need to figure out more precisely what the affected configurations are. sgallagh has volunteered to try and gather some more data by next week 17:26:28 OK, we have one proposed FE 17:26:37 #info moving on to the proposed Beta FE 17:26:56 #topic (1616118) DNF update fails with "cannot install the best update candidate for package" 17:26:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=1616118 17:26:56 #info Proposed Freeze Exceptions, dnf, NEW 17:26:56 oh, same one we had earlier, i just didn't notice 17:27:16 do we accept it as an FE for Beta as well as a blocker for Final? i'm +1 17:28:19 yeas, why not? If they will be able to fix it before Beta, the better 17:28:35 +1 on FE 17:28:52 +1 FE 17:30:30 proposed #agreed 1616118 - AcceptedFreezeException (Beta) - as well as being a Final blocker, it makes sense for this to have an FE for Beta, we certainly would like it fixed if it can safely be fixed. 17:33:25 ack 17:33:30 ack 17:33:33 ack 17:34:14 #agreed 1616118 - AcceptedFreezeException (Beta) - as well as being a Final blocker, it makes sense for this to have an FE for Beta, we certainly would like it fixed if it can safely be fixed. 17:34:19 alrighty, that's all the proposals! 17:34:24 nice 17:34:28 good 17:34:56 i'll follow up on the accepted blockers via bugzilla, i think, don't think we really need to discuss them now 17:35:04 #topic Open floor 17:35:16 anyone have any other issues to bring up? bugs we should consider? 17:35:32 nop 17:36:13 not this time 17:38:26 alrighty 17:38:37 thanks for coming, folks! 17:38:51 now i m back in France time is easier :) 17:39:00 great 17:39:11 always good to have more input :) 17:40:26 Thanks for hosting adamw! 17:41:01 Been mobile at an appointment, will have secretarializing done in less than two hours 17:41:05 roger 17:41:23 #endmeeting