15:02:17 <adamw> #startmeeting Fedora QA Meeting
15:02:17 <zodbot> Meeting started Mon Jul  8 15:02:17 2019 UTC.
15:02:17 <zodbot> This meeting is logged and archived in a public location.
15:02:17 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:17 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
15:02:21 <adamw> #meetingname fedora-qa
15:02:21 <zodbot> The meeting name has been set to 'fedora-qa'
15:02:24 <adamw> #topic Roll call
15:02:26 <lruzicka> .hello2
15:02:27 <adamw> ahoyhoy folks
15:02:27 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
15:02:29 <frantisekz> .hello2
15:02:30 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
15:02:38 * coremodule is here
15:02:39 <lruzicka> ahoy, ship
15:02:41 <coremodule> .hello2
15:02:42 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
15:02:42 <tablepc> .hello2
15:02:43 <cmurf> .hello chrismurphy
15:02:45 <zodbot> tablepc: tablepc 'Pat Kelly' <pmkellly@frontier.com>
15:02:46 * satellit_ here
15:02:49 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
15:02:52 <coremodule> long time, no meet! I like when we meet after a long break
15:03:52 <tflink> .hello2
15:03:53 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:04:13 <jlanda> .hello2
15:04:14 <zodbot> jlanda: jlanda 'Julen Landa Alustiza' <julen@landa.eus>
15:04:20 <jlanda> heya
15:04:22 <adamw> i like when everything works and we can go for pina coladas
15:04:32 <adamw> ...one day, one day...
15:05:22 <jlanda> A beer for each broken compose would work better
15:05:35 <adamw> you hate my liver that much?!
15:05:52 <tablepc> That might be a bit much
15:06:11 <jlanda> :D
15:06:59 <adamw> alrighty then
15:07:09 <tablepc> I do celebrate some when I test a Rawhide drop and don't find problems.
15:08:11 <adamw> i wonder what it's like when that happens
15:08:15 <adamw> #topic Fedora 31 status
15:08:57 <adamw> so, the good news, we have composes, nothing is completely on fire
15:09:22 <adamw> the bad news, we do have some broken stuff, most notably recently a new libdnf update seems to have made packagekit start crashing
15:09:44 <adamw> see https://bugzilla.redhat.com/show_bug.cgi?id=1727343
15:11:43 <jlanda> we have a couple of beta blocker proposals then, this one and alciregi's realm one
15:11:50 <adamw> we have 8 actually
15:12:00 <adamw> i meant to run a blocker review meeting today but forgot to announce it
15:12:01 <coremodule> have you heard from the pk team or the libdnf team on this one?
15:12:20 <lruzicka> adamw, the dnf team know about it, it seems. Today, Dan said they had fix for your bug ... is this the one?
15:12:31 <lruzicka> adamw, or have you filed anything else against dnf?
15:12:40 <adamw> there's also https://bugzilla.redhat.com/show_bug.cgi?id=1727424
15:12:46 <adamw> lruzicka: that's the one i filed
15:12:49 <adamw> but i think the two are related
15:13:09 <adamw> yes, they have a scratch build there...i'll try that later
15:13:40 <lruzicka> ok, it may solve both, or just the one you filed
15:13:49 <adamw> not sure
15:14:13 <adamw> well, i guess in theory it could possibly solve both
15:15:19 <tablepc> when will it be in a rawhide drop?
15:16:56 <cmurf> I notice packagekitd spins up with every login and uses 100% cpu for maybe a minute; so I'm guessing it's processing some update metadata to know if updating is needed?
15:17:14 <cmurf> does pk crash at that point or only during updates?
15:17:51 <cmurf> might be possible to test just by manually updating libdnf by grabbing the package from koji rather than waiting for it to appear as an update
15:18:04 <adamw> hmm, well, no, i don't see how it could solve matt's...
15:18:17 <adamw> tablepc: at present it won't be - scratch builds are just tests
15:18:31 <adamw> but if it seems to help, it'll go into an official build probably
15:18:36 <cmurf> got it
15:19:07 <jlanda> do we have any progress on libgit2 this?
15:19:25 <jlanda> s/this/thing
15:19:38 <adamw> i have not been following it specifically
15:19:48 <adamw> but i'm not getting those errors when running dnf any more...
15:20:10 <adamw> oh wait, yes i am. but a shorter version
15:20:17 <adamw> with only tokei:rolling complaining...
15:20:29 <adamw> sgallagh: around by any chance?
15:21:03 <tflink> adamw: he's on PTO until thursday
15:21:19 * tflink just saw it mentioned in another channel
15:21:36 <adamw> oh, kay
15:21:54 <lruzicka> adamw, the DNF guys think that the libgit2 issue a serious problem and they do not know how to fix it without the assistance of the modularity guys
15:22:10 <lruzicka> is a serious problem
15:22:39 <lruzicka> it looks like we will have to live with it for some time
15:22:52 <cmurf> ruhroh Shaggy!
15:22:57 <adamw> well, there are various ideas to fix the problem
15:23:01 <lruzicka> the good thing is that installations no longer fail on that
15:23:19 <adamw> it doesn't necessarily need anything to change in dnf
15:23:32 <lruzicka> adamw, for example?
15:23:49 <adamw> lruzicka: all the choices in https://communityblog.fedoraproject.org/modularity-vs-libgit/ , plus all the ones that came up in the devel@ discussion
15:24:26 <jlanda> it's annoying and freezes deps right now, wich could freep updates of leaf paclages too, but for QA while the module works...
15:25:06 <adamw> #info Rawhide is getting composes quite regularly and nothing is entirely on fire, but we have known significant bugs ATM: notably PackageKit crashes with new libdnf (#1727343 and #1727424), and the libgit2 module problems are still ongoing to some extent
15:25:43 <lruzicka> adamw, thanks for this, but I think that's exactly why they do not know how to fix it without assistance of modularity guys.
15:26:02 <adamw> well sure, that's the point: someone still needs to decide what to do.
15:26:12 <lruzicka> adamw, the article suggests, but they probably need an order by someone responsible
15:26:14 <adamw> but it's not necessarily the case that dnf needs to do anytning.
15:27:04 <adamw> anyhow, we can't solve it here
15:27:31 <lruzicka> adamw, I was just giving you the status and opinion of the DNF team :)
15:27:42 <adamw> #info the system-wide Change submission deadline has passed, so we should have a fairly complete set of proposed system-wide changes at this point
15:28:33 <jlanda> python38 had been deferred too
15:28:56 <adamw> yeah, that's....good i guess?
15:29:00 <adamw> no change is good!
15:29:25 <adamw> any further notes on f31 status?
15:29:50 <jlanda> yep, the time window was too narrow and upstream missed their deadline, so it's good for sure :D
15:30:04 <cmurf> haha
15:31:18 <adamw> alrighty then
15:31:19 <adamw> #topic Fedora 31 Change review
15:31:24 <adamw> so, speaking of those Changes...
15:31:33 <adamw> #info jlanda notes Python 3.8 has been deferred, so we no longer need to worry about that
15:32:55 * satellit_ note that armhfp spins are working on RPiB3+
15:33:07 * satellit_ mate and soas
15:33:27 <jlanda> I wanna remenber that we have the firefox default to wayland one pending from last cycle
15:33:44 <jlanda> And the new ones ofc ;)
15:34:52 <adamw> yeah. firefox has been wayland by default on rawhide for some time, though, so if it's causing terrible problems it should be doing it now
15:34:59 <adamw> (well, aside from messing with openqa, that is...)
15:35:01 <cmurf> Interestingly, there is a single firefox icon in Rawhide and it looks like it figures out on launch whether to use X11 or native Wayland
15:35:13 <adamw> https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd might be one people get tripped up by...
15:35:24 <cmurf> whereas on Fedora 30 I still have separate icons, and packages, the firefox on wayland package isn't installed by default
15:35:42 <adamw> cmurf: the wayland build has to be able to fall back to x11
15:35:54 <adamw> otherwise it'd be no use on anything but workstation
15:36:10 <adamw> if you install the 'wayland' build on f30 and run it on kde, it'll fall back to x11
15:36:28 <cmurf> i can't parse that
15:36:32 <adamw> okay
15:36:37 <cmurf> the "firefox on wayland" package is teeny tiny
15:36:54 <cmurf> it's not a binary it's just setting a flag to run natively on wayland
15:36:56 <adamw> yes
15:37:04 <adamw> but what it really means is 'run natively on wayland if you can'
15:37:09 <adamw> that is the same in f30 and rawhide
15:37:21 <cmurf> ok well the appearance is totally different on f30 and rawhide
15:37:26 <cmurf> two icons, vs one icon
15:37:27 <jlanda> Fc30 went with wayland support, but disabled for default
15:37:34 <adamw> cmurf: you can get two icons in rawhide too
15:37:38 <adamw> just install firefox-x11
15:37:40 <jlanda> The other pkg just activates it
15:37:57 <adamw> f30 has 'firefox' (x11) and 'firefox-wayland' (wayland-with-fallback)
15:38:07 <adamw> rawhide has 'firefox' (wayland-with-fallback) and 'firefox-x11' (x11)
15:38:11 <jlanda> Now (rawhide) is on the other way :)
15:38:45 <cmurf> looks like firefox has been failing to buildon Rawhide for some time
15:39:04 <adamw> yeah
15:39:21 <adamw> which is a problem because we're stuck on a version without that actively-exploited-in-the-wild 0 day fix
15:39:24 <adamw> but never mind!
15:39:56 <cmurf> OH I see, there is a firefox-x11 package on Rawhide, and there's a firefox-wayland package on F30
15:40:05 <cmurf> that's why i was confused
15:40:46 <cmurf> there is an environment variable that tells us whether it's an x11 or wayland session, i'm not sure why it can't just be one binary that looks at that at launch
15:40:54 <cmurf> but whatever
15:41:21 <cmurf> firefox 68 building now, maybe that'll work on fc31
15:41:41 <adamw> cmurf: because you might still want to force the use of the x11 backend on wayland. that's why.
15:41:56 <cmurf> and kernel 5.2.0 released and building now for fc31 as well
15:42:06 <adamw> there's a new glibc version coming, but we're already on git snapshots for it, so it hasn't caused anything terrible so far
15:42:30 <adamw> rpm similarly, 4.15 is coming, we are already on a beta of it
15:42:36 <jlanda> On the root password one, imho the biggest issue is warning kickstart users. Anaconda should ensure a sane user setup on interactive install, but should we warn kickstart users to add a pubkey/change config/whatever ?
15:43:00 <adamw> "Switch RPMs to zstd compression" seems like one that could cause unexpected problems potentially
15:43:17 <adamw> jlanda: warn them how, exactly?
15:43:52 <adamw> you mean just in the release notes, or something else?
15:44:06 <jlanda> Dunno how exactly
15:44:37 <jlanda> Release notes or a warning on kickstart or... dunno :D
15:44:47 <adamw> this is mentioned in the Change page which means it should show up in release notes somehow
15:44:54 <adamw> we can ping docs team and flag it up, i guess
15:45:04 <adamw> problem with warning on kickstart is that kickstarts are mainly meant to be run unattended :)
15:47:09 <adamw> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update is in 'change ready for wrangler'
15:47:12 <adamw> that looks...interesting...
15:47:16 <jlanda> yep
15:47:18 <adamw> especially "Fedora installations on systems with CPUs which are not able to execute AVX2 instructions will not be able to upgrade. "
15:47:34 <adamw> oh, it's targeted for 32
15:47:40 <adamw> so we can have the fight about it then
15:48:57 <kwizart> my intel multimedia station bought in 2016 does not have avx2
15:49:40 <kwizart> intel celeron j1900
15:50:24 <adamw> yeah, i think that's gonna get kicked out
15:50:28 <adamw> but as it's not for f31, we don't need to worry
15:50:35 <adamw> so...i think the current change set looks actually quite not bad
15:50:45 <adamw> anyone see any concerning ones i've missed?
15:52:48 <adamw> #info in general, the F31 Changes list - https://fedoraproject.org/wiki/Releases/31/ChangeSet - isn't looking too scary at the moment, we will monitor all changes as we go along
15:52:55 <adamw> #topic Test Day / community event status
15:52:59 <adamw> sumantro: are you around today?
15:54:12 <frantisekz> i think he is sick
15:54:54 <adamw> i saw he replied to a ticket, so thought he might be here
15:54:56 <adamw> but i guess not
15:55:37 <adamw> #info for F31 an upgrade test day, GNOME test day, i18n test day, and Silverblue test day are planned; if sumantro is not back soon I will take over planning those
15:56:44 <adamw> #topic Open floor
15:56:50 <adamw> ok folks, any other business?
15:56:58 * adamw realizes he forgot previous meeting follow-up...
15:57:11 <adamw> oh, we didn't have any, so that's good
15:57:21 <tablepc> Some day we might want to get back to the process for last minute blocker bugs.
15:57:22 <cmurf> haha
15:58:11 <cmurf> oh hey, question, blocking on optical media not working has been nixed, correct?
15:58:48 <cmurf> and was it nixed for Fedora 30 or is it new for Fedora 31?
15:59:27 <adamw> tablepc: yeah, i should follow up on that
15:59:52 <adamw> optical is still in criteria right now
15:59:55 <adamw> if we agreed to nix it, we need to update that
15:59:58 * adamw checks
16:00:24 * satellit_ my latest install to bare metal using external DVD writer worked
16:01:05 <tablepc> I'm still one of those holdouts testing on bare metal using DVDs to load and they still work.
16:01:22 <adamw> optical media, we're still waiting for matthew to update the proposal
16:01:25 <adamw> since december
16:01:28 <cmurf> ohdear
16:01:31 <adamw> he said "If
16:01:31 <cmurf> ok
16:01:31 <adamw> I don't, and you remember before I do, pleaes remind me :)"
16:01:35 <adamw> so...we should probably remind him :)
16:01:37 <cmurf> lalalala
16:01:40 <adamw> i'll do that, thanks for the reminder to remind...
16:02:33 <adamw> #action adamw to follow up on last minute blocker process proposal
16:02:59 <adamw> we still have the xen stuff outstanding i guess
16:04:24 <adamw> ok, sounds like we're done here!
16:04:28 <adamw> thanks for coming, everoyne
16:04:30 * adamw sets fuse
16:04:31 <cmurf> cya
16:04:37 <tablepc> Have a Great Day!
16:05:33 <jlanda> thanks everyone
16:05:41 <adamw> #endmeeting