16:06:53 #startmeeting F30-blocker-review 16:06:53 #meetingname F30-blocker-review 16:06:53 #topic Roll Call 16:06:53 Meeting started Mon Apr 8 16:06:53 2019 UTC. 16:06:53 This meeting is logged and archived in a public location. 16:06:53 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:06:53 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:06:53 The meeting name has been set to 'f30-blocker-review' 16:06:53 The meeting name has been set to 'f30-blocker-review' 16:06:58 alright, now you can go :) 16:07:15 .hello2 16:07:16 bcotton: bcotton 'Ben Cotton' 16:07:23 .hello2 16:07:25 coremodule: coremodule 'Geoffrey Marr' 16:07:25 * cmurf claims he is here 16:07:31 Good morning, /me is ready to act as secretary! 16:07:41 your claim will be referred to the claims review department 16:08:27 .hello2 16:08:29 kalev: kalev 'Kalev Lember' 16:09:42 #chair coremodule bcotton 16:09:42 Current chairs: adamw bcotton coremodule 16:09:54 #topic Introduction 16:09:54 Why are we here? 16:09:54 #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:09:54 #info We'll be following the process outlined at: 16:09:56 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:09:56 #info The bugs up for review today are available at: 16:09:58 #link http://qa.fedoraproject.org/blockerbugs/current 16:09:59 #info The criteria for release blocking bugs can be found at: 16:10:01 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:10:03 #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria 16:10:05 #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria 16:10:07 #info for F30 Final, we have: 16:10:09 #info 6 Proposed Blockers 16:10:11 #info 7 Accepted Blockers 16:10:13 #info 1 Accepted Freeze Exceptions 16:10:21 #info coremodule will secretarialize 16:10:23 I'm running the FESCo meeting, but I'll try to monitor this channel as well 16:10:27 thanks sgallagh 16:10:42 man, that whole 'fesco' thing is so rude, scheduling their meeting against ours 16:10:54 #info let's start with proposed Final blockers 16:10:56 #topic (1695637) initial-setup doesn't start 16:10:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=1695637 16:10:56 #info Proposed Blocker, appliance-tools, NEW 16:10:57 adamw: More like "running way over" 16:12:48 +1 blocker 16:13:10 so, this is a clear blocker, for me - we are still working on figuring out the exact cause here, but whatever the cause is, i-s has to work 16:13:38 I can try an arm test right after this meeting 16:13:46 +1 blocker 16:13:46 +1 blocker 16:13:50 +1b 16:13:52 To confirm, this is true of the aarch64 Server images or the xfce armv7 images? 16:14:58 the 32-bit disk images 16:15:04 including minimal and arm, which are the blocking ones 16:15:15 i dunno about aarch64 16:16:21 +1 blocker 16:16:22 minimal and arm? 16:17:20 proposed #agreed 1695637 - AcceptedBlocker (Final) - accepted as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for the ARM Xfce disk image (which is release blocking) 16:17:27 sgallagh: er, minimal and xfce, i meant :) 16:17:28 ack 16:17:35 ok, yeah. XFCE was my question. Ack 16:17:39 ack 16:17:39 ack 16:17:40 ack 16:17:43 ack 16:18:19 #agreed 1695637 - AcceptedBlocker (Final) - accepted as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for the ARM Xfce disk image (which is release blocking) 16:18:28 #topic (1692089) cannot install Eclipse 16:18:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1692089 16:18:29 #info Proposed Blocker, eclipse, ASSIGNED 16:18:45 I don't see a criterion that applies 16:18:51 me neither 16:18:56 yeah. this sucks, but i don't think it's a blocker 16:19:17 yep 16:19:31 yeah 16:19:31 -1 blocker, +1 FE (assuming it doesn't get fixed before the freeze) 16:19:44 it's not a specified component of anything i can think of 16:19:51 -1 blocker, not sure about FE 16:19:56 -1 blocker, +1 FE 16:20:08 -1b, +1fe 16:20:34 well, is it shipped on any disk? 16:20:56 What sense has here a +1fe if it isn't on a burned media? 16:21:04 fixes upgrades 16:21:11 during the late release cycle 16:21:23 final freeze in 7 days, april 16 16:21:25 (also it's kinda a bad look for the frozen release repos to have uninstallable eclipse in them, i guess) 16:21:36 true, good point 16:21:41 -1 blocker, +1 FE 16:21:51 -1 blocker 16:21:55 -1 blocker, +1 FE 16:22:12 -1 B, +1 FE 16:22:52 jlanda: not being on release media also means that taking it as a FE is unlikely to affect the release process in a negative way 16:23:18 Yep, sure 16:23:36 proposed #agreed 1692089 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as a blocker as it does not actually violate any criteria, Eclipse is not a default component of anything release-blocking. Accepted as a freeze exception issue as this will affect many upgrades, fixing upgrade issues during the freeze is usually a good idea 16:23:42 ack 16:23:47 ack 16:23:47 ack 16:23:48 ack 16:24:05 ack 16:25:22 #agreed 1692089 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as a blocker as it does not actually violate any criteria, Eclipse is not a default component of anything release-blocking. Accepted as a freeze exception issue as this will affect many upgrades, fixing upgrade issues during the freeze is usually a good idea 16:25:29 #topic (1695297) Upgrading a FreeIPA server from F29 to F30 broke with 389-ds-base-1.4.1.2-2.fc30 16:25:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1695297 16:25:29 #info Proposed Blocker, freeipa, VERIFIED 16:26:07 +1b, the server criteria should be met on a upgrade 16:26:25 since we should be able to actually upgrade 16:26:33 +1B 16:26:36 yeah, the criteria specifically require that this work 16:26:41 +1 blocker 16:26:45 +1 blocker 16:26:49 +1 blocker 16:27:06 +1 blocker 16:27:09 +1 blocker 16:28:08 proposed #agreed 1695297 - AcceptedBlocker (Final) - accepted as a clear violation of "It must be possible to successfully complete a direct upgrade from a fully updated installation of each of the last two stable Fedora Server releases with the system configured as a FreeIPA domain controller or postgresql server as specified in the relevant criteria. The upgraded system must meet all relevant release criteria, including criteria relating to 16:28:08 functionality of the server software" 16:28:09 gr 16:28:12 editing time! 16:28:13 ack 16:28:32 proposed #agreed 1695297 - AcceptedBlocker (Final) - accepted as a clear violation of "It must be possible to successfully complete a direct upgrade from a fully updated installation of each of the last two stable Fedora Server releases with the system configured as a FreeIPA domain controller...as specified in the relevant criteria. The upgraded system must meet all relevant release criteria, including criteria relating to functionality of the 16:28:32 server software" 16:28:34 sigh. 16:28:48 proposed #agreed 1695297 - AcceptedBlocker (Final) - accepted as a clear violation of "It must be possible to successfully complete a direct upgrade from a fully updated installation of each of the last two stable Fedora Server releases with the system configured as a FreeIPA domain controller...The upgraded system must meet all relevant release criteria, including criteria relating to functionality of the server software" 16:28:53 ack 16:28:54 ack this one too :D 16:28:57 ack 16:28:58 ack 16:29:00 man, the idiot who wrote that criterion sure loves using long words 16:29:04 ack 16:29:29 #agreed 1695297 - AcceptedBlocker (Final) - accepted as a clear violation of "It must be possible to successfully complete a direct upgrade from a fully updated installation of each of the last two stable Fedora Server releases with the system configured as a FreeIPA domain controller...The upgraded system must meet all relevant release criteria, including criteria relating to functionality of the server software" 16:29:45 #topic (1693409) gdm/X start fails on 'nomodeset' UEFI boot on test system with Radeon HD 8470D: "Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices" 16:29:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1693409 16:29:45 #info Proposed Blocker, gdm, NEW 16:29:59 so...i think i'd like to know this happens on at least one card that actually needs nomodeset 16:30:04 though getting that tested may be tricky 16:30:10 would be useful to have input from graphics devs too 16:30:32 can we just drop graphics and become text-only? :-) 16:31:08 yes we're moving to the i3 window manager 16:31:11 all graphics dropped 16:31:14 nvidia and radeons hit this. yeah, they are not the main audience of this feature, but new discrete gpus are and if the already supported ones fail here, the unsupported one will probably hit too, so I'm +1b on this 16:31:34 bcotton: i would accept a textonly anaconda option as non blocker 16:32:15 we don't know that new nvidias which actually need nomodeset hit this 16:32:28 testing on one or two devices isn't sufficient to prove that, if we don't have a clear causation 16:32:37 also, there is a text only anaconda option 16:32:39 boot with 'inst.text 16:32:52 text only anaconda results in a CLI system 16:33:01 uhhhh 16:33:10 Yesh, we don't know, but we know of a lot of modern hardware that hits this, and one of the biggest audience of the nomodeset optiom is new hardware 16:33:13 i don't think that's true 16:33:30 And if a radeon n hits this, n+1 will probably hit too 16:33:35 And the same for nvidia 16:33:39 if you do a inst.text installation of Workstation, it still boots graphical.target 16:33:57 But you can fight to configure it 16:34:03 Boot on text mode and fight 16:34:04 if you do nomodeset at install time, anaconda picks that up and applies it to the default boot parameters for the installed system 16:34:22 I'm +1 conditional blocker 16:34:43 But with this hitting new hard that can no go on normal mode, you can't install a box with wks live 16:34:54 cmurf, how does a text installation set up graphics correctly? 16:35:00 And the link on getfedora to gold lasts, mmm, 13months ? 16:35:02 that's still an assumption. i'd just like to know it. 16:35:13 lruzicka: there isn't really anything to 'set up' these days 16:35:22 We can have to iterations of new gpus on that time 16:35:25 it's all autodetected, when it works correctly 16:35:27 lruzicka: graphics is setup per boot by the kernel 16:35:42 but when it works, you do not need text installtion 16:35:57 But we you need, you can't 16:36:07 lruzicka: it's a fair point that inst.txt means you install, but then at reboot time, you still fail 16:36:08 A third option on grub, text mode anaconda 16:36:12 And i'm fine 16:36:17 :) 16:36:33 s/inst.txt/inst.text 16:36:52 cmurf, yes 16:37:27 i suppose what would be more useful would be if the installer sees inst.text or nomodeset, that it does NOT include 'rhgb quiet' for the installed system 16:37:34 so that the user can see the blow up 16:37:43 rather than possibly a silent failure 16:37:52 it already doesn't do it for non-graphical installs, iirc. 16:37:55 anyway, we're kinda off-topic 16:38:08 i would personally like more data on this before voting, so i'm 0 (vote for punt0 16:38:09 other votes? 16:39:24 +1b as said 16:39:26 devel@ call for testing on this and similar graphics? 16:39:37 Hello folks! Sorry for my lateness 16:39:40 But let punt 16:39:43 .fas lailah 16:39:43 Lailah: lailah 'Sylvia Sánchez' 16:39:44 I think more data would be good 16:39:45 We have time 16:39:52 +1 punt 16:39:54 +1 punt 16:39:59 punt this 16:40:00 I saw this one 16:40:04 +1 punt 16:40:10 +1 punt 16:40:22 hi lailah 16:40:22 +1 punt 16:40:46 hi adamw 16:41:10 proposed #agreed 1693409 - punt (delay decision) - we are concerned about this one, but do not yet have enough data to be confident about exactly what range of hardware is affected. We will try to get more folks to test on different cards, and also ask the graphics developers to look at the issue and see if they can provide any useful information on causation 16:41:21 ack 16:41:25 ack 16:41:34 ack 16:41:34 ack 16:41:44 ack 16:41:44 ack 16:41:56 #agreed 1693409 - punt (delay decision) - we are concerned about this one, but do not yet have enough data to be confident about exactly what range of hardware is affected. We will try to get more folks to test on different cards, and also ask the graphics developers to look at the issue and see if they can provide any useful information on causation 16:42:07 #topic (1695967) initial-setup crashes with "ImportError: cannot import name 'setup_ifcfg_log' from 'pyanaconda.network'" (function was removed from anaconda) 16:42:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1695967 16:42:07 #info Proposed Blocker, initial-setup, ON_QA 16:42:18 I haven't run into this, is it fixed? Anyway +1 blocker if it's not. 16:42:19 this is a different initial-setup failure 16:42:33 cmurf: it only came into f30 recently, with the new anaconda build that appeared a few days ago 16:42:52 and it's fixed with a new version in updates-testing now 16:42:53 Let me take a look... 16:43:06 +1 blocker 16:43:19 +1b 16:43:21 +1 blocker 16:43:24 +1 16:43:27 +1 b 16:43:35 It's a blocker, definitely 16:43:44 +1 blocker 16:44:02 proposed #agreed 1695967 - AcceptedBlocker (Final) - accepted as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for the ARM Xfce disk image (which is release blocking) 16:44:05 ack 16:44:17 ack 16:44:19 ack 16:44:22 ack 16:44:25 ack 16:44:26 #agreed 1695967 - AcceptedBlocker (Final) - accepted as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" for the ARM Xfce disk image (which is release blocking) 16:44:37 #topic (1696784) systemd 241 does not register bcache caching device 16:44:37 #link https://bugzilla.redhat.com/show_bug.cgi?id=1696784 16:44:38 #info Proposed Blocker, systemd, ASSIGNED 16:44:54 so, this is basically a hardware/configuration-dependent issue... 16:45:10 with known fix 16:45:16 bcache is a sort of hybrid storage thing, it's when you use an ssd as a cache for a larger hdd 16:45:40 there probably aren't a *lot* of people with this setup, but otoh it's very bad for those who *are*... 16:45:42 But it has a known fix. 16:45:51 It says that it only needs to be backported 16:45:55 There is a criterion cited, however I think that applies to clean Fedora n-1 installations being upgraded, and the installer doesn't support bcache. 16:46:05 cmurf: true 16:46:13 i think this might just fail the last blocker test... 16:46:23 -1 blocker, +1 FE 16:46:24 i'd be +1 FE for it though 16:46:26 Do we supporr bcache? 16:46:34 no 16:46:46 well, haha, we support it if we bock on it 16:46:49 -1b, +1fe then ;) 16:46:51 s/bock/block 16:47:05 -1 blocker, 16:47:08 To me it's not a blocker 16:47:10 +1 fe 16:47:10 -1 16:47:30 +1 FE 16:47:32 +1 fe 16:47:40 "support" is such a tricky word :P 16:48:11 -1 blocker, +1 FE 16:48:17 yeah :D 16:48:33 proposed #agreed 1696784 - RejectedBlocker (Final) AcceptedFreezeException (Final) - as bcache is not supported by the Fedora installer and requires manual setup, this does not really violate the upgrade criteria. However its impact on anyone who did manually set up bcache is severe, so this is accepted as a freeze exception issue to ensure any fix can be pushed as soon as possible 16:48:50 .fas ttorcz 16:48:51 zdzichu: ttorcz 'Tomasz Torcz' 16:48:57 ack 16:49:08 ack 16:49:08 ack 16:49:08 ack 16:49:13 ack 16:49:18 ack 16:50:06 medium sized pile of approved blockers to check up on 16:50:25 Yeah... 16:51:02 #agreed 1696784 - RejectedBlocker (Final) AcceptedFreezeException (Final) - as bcache is not supported by the Fedora installer and requires manual setup, this does not really violate the upgrade criteria. However its impact on anyone who did manually set up bcache is severe, so this is accepted as a freeze exception issue to ensure any fix can be pushed as soon as possible 16:51:06 ack 16:51:25 well, we've got time, so let's go through 'em properly 16:51:31 #topic Accepted blockers 16:51:37 #info moving on to a review of the accepted blockers 16:51:42 #topic (1691832) NFSISO test failed on f30 (20190320) 16:51:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1691832 16:51:42 #info Accepted Blocker, anaconda, MODIFIED 16:51:57 #info the next anaconda should fix this; not much to do but wait for it and see 16:52:06 #topic (1683197) gdm Fails to load with "nomodeset" 16:52:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=1683197 16:52:06 #info Accepted Blocker, gdm, ASSIGNED 16:52:19 for this and the next one, we need to ping halfline and get him to decide what to do 16:52:32 adamw this bug... I don't understand a word of what is written there! 16:52:42 don't worry about it :P 16:52:42 No, the previous one 16:52:56 the developers did, which is the important thing :P 16:53:12 Ah, okay 16:53:41 The GDM one is understandable to me, the other about NFSISO... sounds alien. 16:53:44 To me. 16:54:14 it's just a different way of getting the installer bits delivered, basically. 16:54:25 Ah, okay. 16:54:27 #info this is waiting on the GDM developer to decide how to address it 16:54:41 * mboddu is kinda here now 16:54:45 #action adamw to ping halfline about 1683197 16:54:51 #topic (1691909) GDM fallback from Wayland to X11 no longer works because it takes too long to start gnome-shell (affects 'basic graphics mode' / nomodeset, maybe other cases) 16:54:51 #link https://bugzilla.redhat.com/show_bug.cgi?id=1691909 16:54:51 #info Accepted Blocker, gdm, NEW 16:54:54 ditto with the previous one, basically 16:55:01 for both there's an easy choice and some harder choices 16:55:05 yes 16:55:09 #info this is waiting on the GDM developer to decide how to address it 16:55:17 #action adamw to ping halfline about 16:55:19 grr 16:55:20 #undo 16:55:20 Removing item from minutes: ACTION by adamw at 16:55:17 : adamw to ping halfline about 16:55:23 #action adamw to ping halfline about 1691909 16:55:30 anyone have any other notes on these two? 16:55:33 Oh, I remember this one 16:57:00 guess not! 16:57:11 Not from me. 16:57:14 #topic (1690429) sometimes icon not showing for eg firefox in gnome-shell overview dash 16:57:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=1690429 16:57:14 #info Accepted Blocker, gnome-shell, NEW 16:57:16 * linuxmodder late 16:57:25 hi linuxmodder 16:57:30 we're just going through the accepted blockers to check status 16:57:48 cmurf, by the way, I have tried to use text.inst in a VM, installed Workstation and ended up in a CLI environment. 16:57:50 upstream bug is still open too, here... 16:57:58 kalev: can this one get prioritized? 16:58:09 Oh, I remember this one. 16:58:14 Any news? 16:58:27 it seems not, the bug is known but no fix seems to be showing up 16:59:12 :-( 16:59:29 So? What do we do with it? 16:59:36 we bug the desktop team! 16:59:47 Yeah!!! 16:59:52 which is what i just tried to do, but kalev actually left, so that didn't work. :P 17:00:00 Doh... 17:00:08 i'll have to do it elsewhere 17:00:27 #info this bug seems to be accepted and more or less understood, but no fix has appeared downstream or upstream 17:00:37 #action adamw to poke desktop team to prioritize work on fixing this bug 17:00:43 lruzicka, your cli env is during installer or post install? 17:01:05 adamw: I believe it is somewhere on florians list 17:01:37 lruzicka: huh, what's the output from `cat /proc/cmdline` ? 17:01:47 lruzicka: discuss on #fedora-qa 17:02:01 linuxmodder, I installed Workstation using inst.text, rebooted and I have a CLI on my screen with gdm.service inactive (dead) 17:02:13 mclasen: we would like to move in a topwards direction ;) 17:02:46 sure, but 17:03:33 hi again kalev 17:03:33 lruzicka, seems like it is setting systemd.unit=mulit-user.target to me 17:04:00 ,oving to -qa re: lruzicka's issue 17:04:06 adamw: kalev is back, now you can bug him at will :-D 17:04:12 woohoo 17:04:53 * adamw waiting on the other half of that "but" 17:05:46 * Lailah waiting too 17:05:52 eeks :D 17:05:53 mclasen: you have us holding our breath 17:06:18 not much more to say. competing priorities are a fact of life 17:06:48 Why it took you so long to finish that "but" ? 17:07:19 I thought some lengthy explanation was coming. 17:07:25 sorry 17:07:27 =) 17:07:35 alrighty, anyhow 17:07:37 moving on 17:07:39 well it doesn't have to get fixed today the question really is, is it going to get fixed in a ~3-4 week timeline? 17:07:49 #topic (1688462) System upgrades involving modular content require explicit --setopt=module_platform_id to work correctly 17:07:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1688462 17:07:49 #info Accepted Blocker, libdnf, NEW 17:07:50 s/in/within 17:07:57 oh god this one :D 17:07:58 so a proposal went out for this recently, iirc 17:08:13 the proposal being we just ditch platform IDs and assume it's the same as the releasever, more or less 17:08:27 that's neat 17:08:45 * cmurf was thinking it might involve chickens and vodka 17:09:07 adamw, I see a slight issue in the edgecase of migrating boxes with that logic 17:09:13 chickens and vodka in the upgrade cmurf ? 17:09:22 Lailah, dsdf ? 17:09:33 Lailah: just laugh, that's all my observations require 17:10:44 I just didn't get it cmurf 17:10:49 I'm sorry 17:10:52 :-( 17:11:41 adamw any idea how that proposal would work? 17:11:55 let me see if i can find it again 17:12:11 Sounds sensible to me, but I'm not really experienced with modular 17:12:24 well, #c6 has a brief note 17:13:15 i can't find the more detailed email i was thinking of, though... 17:15:23 #info DNF team is working on a plan to fix this by getting rid of platform IDs 17:15:42 sgallagh: it seems to me the last comment implies FESCo is waiting for some sort of approval from fesco, is this known? 17:16:18 * sgallagh looks 17:16:45 Ah, no. This was approval from Modularity team 17:16:48 Which we sorted out this morning 17:17:26 We agreed that they need to file a Change, but that it's a formality because it's needed for F29, F30 and F31 17:17:58 This should hopefully all be finished by the end of the week. 17:18:02 okay, so they're not waiting on Change approval before going ahead with the work for f30? good 17:18:09 Right. 17:18:29 okay then, so this is in their hands. cool 17:18:36 #topic (1666920) iSCSI installs fail to boot since systemd-240 (Fedora-Rawhide-20181222.n.1) 17:18:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1666920 17:18:36 #info Accepted Blocker, systemd, NEW 17:18:42 this one has just been sitting around for a loooong time 17:18:50 i need to hit zbyszek with something pointy and painful 17:18:57 #info this has been sitting unaddressed for many weeks now 17:19:04 agreed 17:19:09 #action adamw to poke systemd team to actually look into fixing it 17:19:19 i guess i could try and do some triage on it too. 17:19:55 maybe sea salt caramel chocolate as a bribe first 17:20:14 hey, i have 30 seat salt caramel lindor just lying around here 17:20:21 see 17:20:24 no excuses 17:20:36 wonder if it'll get through customs 17:21:01 adamw How can you have all that caramel chocolate without eating it? 17:21:08 * cmurf is adamw's stalker, looking in his window 17:21:42 xD 17:21:43 Lailah: i didn't say how many there were *yesterday* 17:21:45 :P 17:21:53 Oh! 17:22:05 #topic (1674045) Upgrade from F29 to Rawhide (F30) hangs at end, showing "Upgrade complete! Cleaning up and rebooting..." 17:22:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=1674045 17:22:05 #info Accepted Blocker, systemd, NEW 17:22:16 same as previous 17:22:19 this one likewise has been well established and reported for some time, but is not getting fixed 17:22:20 yup 17:22:29 #action adamw to poke zbyszek about this one too 17:22:45 adamw is down to 28 lindor 17:23:11 =) 17:23:20 hey that's slanderous 17:23:23 ...i do not eat that slow 17:24:21 alright, that covers all the blockers 17:24:24 #topic Open floor 17:24:28 do we have any other business, folks? 17:24:38 not I 17:25:52 I have some weirdness with time & dates but I still have to check what exactly is wrong because it seems to be a bit random. 17:26:03 I'm on KDE 17:26:23 So, no, not other business 17:27:11 no, not here 17:28:58 alrighty folks 17:29:03 in that case, thanks for coming, everyone 17:29:09 see you same time next week 17:29:17 #endmeeting