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