16:18:20 <adamw> #startmeeting F33-blocker-review
16:18:20 <zodbot> Meeting started Mon Jul 20 16:18:20 2020 UTC.
16:18:20 <zodbot> This meeting is logged and archived in a public location.
16:18:20 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:18:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:18:20 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:18:20 <adamw> #meetingname F33-blocker-review
16:18:20 <adamw> #topic Roll Call
16:18:20 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:18:27 <King_InuYasha> .hello ngompa
16:18:27 <bcotton> .hello2
16:18:27 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:18:30 <pwhalen> .hello2
16:18:31 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:18:33 <adamw> #chair cmurf coremodule
16:18:33 <zodbot> Current chairs: adamw cmurf coremodule
16:18:33 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
16:19:15 <adamw> impending boilerplate alert
16:19:22 <adamw> #topic Introduction
16:19:23 <adamw> Why are we here?
16:19:23 <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:19:23 <adamw> #info We'll be following the process outlined at:
16:19:24 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:19:24 <adamw> #info The bugs up for review today are available at:
16:19:26 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:19:28 <adamw> #info The criteria for release blocking bugs can be found at:
16:19:30 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:19:32 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:19:34 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:19:44 <adamw> #info for Beta, we have:
16:19:44 <adamw> #info 5 Proposed Blockers
16:19:49 <adamw> #info 1 Proposed Freeze Exceptions
16:19:58 <adamw> #info for Final, we have:
16:20:07 <adamw> #info 2 Proposed Blockers
16:20:17 <adamw> #topic Proposed Beta blockers
16:20:30 <adamw> oh, who wants to secretarialize?
16:20:41 <coremodule> i'll oblige that one
16:20:54 <adamw> #info coremodule will secretarialize
16:21:04 <adamw> #topic (1856496) Anaconda cannot reclaim space from swap partition
16:21:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1856496
16:21:05 <adamw> #info Proposed Blocker, anaconda, NEW
16:23:08 <adamw> this does seem covered by Beta requirement "When using the guided partitioning flow, the installer must be able to:  ... Remove existing storage volumes to free up space, at the user's direction"
16:23:09 <cmurf> i haven't had a chance to reproduce, but the reporter/tester did a good job i think
16:23:17 <cmurf> so it's convincing
16:23:18 <adamw> i haven't either
16:23:29 <cmurf> +1 blocker
16:23:39 <adamw> it'd be good if someone could, just to confirm there's no other unexpected user-specific factor here
16:23:43 <cmurf> yeah
16:23:50 <adamw> but as described probably +1 for me
16:23:52 <lruzicka> +1 blocker as I see it
16:23:52 <pwhalen> +1 blocker
16:23:59 <sumantro> +1 blocker
16:24:08 <coremodule> +1
16:25:25 <adamw> proposed #agreed 1856496 - AcceptedBlocker (Beta) - it would be good to have independent confirmation of this, but as described we accept it as a blocker as a violation of Beta requirement "When using the guided partitioning flow, the installer must be able to:  ... Remove existing storage volumes to free up space, at the user's direction"
16:25:44 <coremodule> ack
16:25:45 <pwhalen> ack
16:25:47 <lruzicka> ack
16:25:48 <cmurf> ack
16:26:01 <adamw> #agreed 1856496 - AcceptedBlocker (Beta) - it would be good to have independent confirmation of this, but as described we accept it as a blocker as a violation of Beta requirement "When using the guided partitioning flow, the installer must be able to:  ... Remove existing storage volumes to free up space, at the user's direction"
16:26:09 <adamw> #topic (1855174) btrfs installation crashes with multiple disks, when one of them is too small for the OS
16:26:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1855174
16:26:09 <adamw> #info Proposed Blocker, btrfs-progs, NEW
16:26:11 <coremodule> the first blocker of F33, mah feels
16:26:23 <adamw> i think we may have had an automatic blocker before
16:26:38 <coremodule> good, then i feel nothing
16:26:40 <King_InuYasha> this definitely seems to be an auto-blocker
16:26:42 <pwhalen> heh
16:26:48 <lruzicka> coremodule, yeah, the eels
16:26:48 <cmurf> the reason this bug happens is kparal
16:26:50 <cmurf> haha
16:26:50 * adamw has acquired an extremely large furry wrist rest (not called bach), please excuse any typing slowness...
16:27:08 <cmurf> kparal came up with the perfect test, two small devices, bizarrely uneveningly sized
16:27:16 <adamw> classic kparal
16:27:19 <King_InuYasha> it's an awesome case too :D
16:27:34 <cmurf> and it exposes a long standing bad mkfs.btrfs default of using data raid0 in the multiple device case
16:27:40 <cmurf> so it's gonna get fixed :P
16:27:47 <cmurf> https://github.com/kdave/btrfs-progs/issues/270
16:28:56 <lruzicka> for Kamil his surname is his omen
16:29:06 <cmurf> unevenly
16:29:16 <cmurf> uneveningly is not a word haha
16:29:17 <lruzicka> so it must be the way it is
16:29:31 <bcotton> +1 blocker
16:29:32 <adamw> seems like +1 blocker to me, anyway, under "When using the guided partitioning flow, the installer must be able to:  ... Complete an installation using any combination of disk configuration options it allows the user to select"
16:29:45 <cmurf> and it can't so it's a blocker, +1
16:29:50 <adamw> ok it's slightly 'conditional' in that you need a fairly specific set of disks to trigger it, but i'm still +1
16:30:07 <pwhalen> +1 blocker
16:30:09 <King_InuYasha> likewise, +1
16:30:10 <lruzicka> yes, +1 blocker. If one disk is enough to host the system, the size of the second disk is irrelevant
16:30:19 <coremodule> +1 blocker
16:30:20 <sumantro> +1 blocker
16:30:21 <cmurf> it is conditional, but lvm+ext4 default in the same situation succeeds
16:30:35 <cmurf> and the change to use data single by btrfs makes it behave that way too
16:30:51 <adamw> proposed #agreed 1855174 - AcceptedBlocker (Beta) - accepted as a violation of "When using the guided partitioning flow, the installer must be able to:  ... Complete an installation using any combination of disk configuration options it allows the user to select"
16:31:09 <coremodule> ack
16:31:11 <lruzicka> ack
16:31:17 <bcotton> ack
16:31:18 <pwhalen> ack
16:31:24 <King_InuYasha> ack
16:31:30 <cmurf> but your data on the surviving drive can be saved, unlike the lvm_ext4 case (esoteroic info)
16:31:47 <King_InuYasha> cmurf: doesn't matter if it can't install so that you can _have_ data to save
16:32:04 <adamw> #agreed 1855174 - AcceptedBlocker (Beta) - accepted as a violation of "When using the guided partitioning flow, the installer must be able to:  ... Complete an installation using any combination of disk configuration options it allows the user to select"
16:32:13 <adamw> #topic (1830343) Network manager started stuck when I tries connecting to VPN (openconnect)  after upgrade gnome-shell to 3.37.1-1.fc33 version
16:32:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1830343
16:32:14 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:32:20 <cmurf> yeah i mean once it's fixed
16:33:00 <adamw> so this is basically 'networkmanager-openconnect is broken', aiui
16:33:11 <adamw> it's been hanging around for a while
16:34:04 <King_InuYasha> yikes
16:34:12 <bcotton> it does seem pretty blockery
16:34:54 <King_InuYasha> I'd say so... but do we have a good way to test these things to verify fixes?
16:35:06 <adamw> i can think of workarounds - connecting from console with nmcli for e.g.
16:35:09 <bcotton> now that's a good question
16:35:16 <adamw> we don't have specific VPN requirements
16:35:30 <adamw> so this becomes a sort of conditional violation of other criteria that require VPN connection, i guess...
16:35:33 <cmurf> soo there's other issues here too, including if you have a VPN profile that disables ipv6, NetworkManager ignores it, ipv6 is still enabled when your VPN is enabled
16:36:15 <adamw> i think i'd struggle to +1 this under the criteria as they stand, but if someone proposed VPN criteria that'd be an interesting discussion...
16:36:15 <King_InuYasha> I *personally* would like to block on this (especially as $DAYJOB is switching to VPN tech that requires this), but I don't know how we'd validate this reasonably
16:36:24 <adamw> do we have any idea how common openconnect is?
16:36:27 <King_InuYasha> very
16:36:56 <King_InuYasha> it's the only way to use Cisco AnyConnect and Palo Alto GlobalProtect based corporate VPNs
16:37:08 <cmurf> yeah a clear criterion for VPN is reasonable: also rolls in related systemd-resolved change
16:37:13 <King_InuYasha> $DAYJOB is moving from the former to the latter, for example
16:37:42 <King_InuYasha> I do not know if there's an open source server side thing that can pretend to be an AC or GP VPN gateway, though
16:37:49 <King_InuYasha> for testing and such
16:38:17 <cmurf> testing part is a hurdle but maybe not insurmountable
16:38:22 <King_InuYasha> adamw: I think I would at least give it a freeze exception
16:38:49 <adamw> King_InuYasha: i don't tend to worry about that till we're near a freeze
16:38:49 <King_InuYasha> ah
16:38:50 <cmurf> month + 5 days away
16:38:54 <King_InuYasha> :D
16:39:04 <adamw> also, btw, seems this might not be as simple as 'openconnect broken'
16:39:19 <adamw> it might be broken only in a certain configuration
16:39:20 <King_InuYasha> the ticket mentions 2FA causing it to get stuck
16:39:29 <adamw> per https://bugzilla.redhat.com/show_bug.cgi?id=1830343#c4
16:39:37 <adamw> yeah, iiuc, the expected workflow is you send username + password
16:39:42 <adamw> and the remote end sort of challenges back for a 2FA code
16:39:51 <adamw> it sounds like GNOME is dropping the ball at that point
16:40:02 <adamw> so if your openconnect VPN isn't configured that way, it might be OK
16:40:14 <cmurf> are the logs sufficiently revealing?
16:40:33 <King_InuYasha> so mine would be screwed then, since it does a 2FA flow
16:40:38 <King_InuYasha> though it's weird and forces a browser prompt
16:40:48 <cmurf> there could be unexpected interaction with systemd-resolved
16:40:51 <adamw> cmurf: the one from #c1? i don't think so, that reads like a 'warning you are doing something bad but it'll keep working for now' to me
16:41:02 <cmurf> uh hmmm
16:41:11 <adamw> could ask for full logs i guess
16:41:14 <King_InuYasha> yeah
16:41:27 <adamw> cmurf: i think this was filed before systemd-resolved change?
16:41:34 <adamw> 2020-05-01
16:41:37 <King_InuYasha> I'm not confident that I could trigger this bug, given that the 2FA method the reporter is using is different from mine
16:41:40 <cmurf> oh well that could fix it too for that matter
16:41:54 <adamw> King_InuYasha: wouldn't hurt to try i gues
16:41:55 <adamw> s
16:42:01 <cmurf> yeah punt
16:42:05 <King_InuYasha> adamw: I can and will certainly try
16:42:38 <cmurf> see if it's still a problem with current Rawhide, and if so please attach 'journalctl -b -o short-monotonic'
16:43:01 <cmurf> needinfo
16:44:42 <adamw> i mean, if we punt, what are we punting *for*?
16:44:56 <adamw> what more information are we expecting to make a decision?
16:45:00 <adamw> i like to have that clear when we punt
16:45:18 <King_InuYasha> logs from the journal specifically about what's happening with nm, nm-openconnect, and openconnect itself
16:45:50 <King_InuYasha> it tends to be pretty verbose in the journal iirc
16:45:52 <cmurf> is this still reproducible since systemd-resolved landed, and if so please attach logs
16:46:18 <King_InuYasha> did resolved land yet?
16:46:30 <cmurf> it could be better or worse or just different
16:47:03 <cmurf> yes it did land
16:47:10 <cmurf> running on rawhide now
16:47:20 <King_InuYasha> do we have test media to link to the poster to install and try with?
16:48:12 <cmurf> yeah what's the current recommended rawhide?
16:49:03 <cmurf> 20200719 worked for me (except with io='io_uring' enabled in qemu) both VM and baremetal
16:50:05 <adamw> King_InuYasha: and when we get the logs is it going to change our opinion on whether it's a blocker or not? as opposed to helping us fix the bug?
16:50:40 <cmurf> good point
16:51:47 <cmurf> back to the 'we probably need a VPN criterion' discussion
16:52:35 <adamw> i'm fine punting to discuss a criterion
16:53:51 <bcotton> arguably we could stretch the Final criterion "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test. "
16:54:21 <bcotton> but i think it'd be better to have an explicit vpn criterion (particularly with an eye toward what is out of scope, because this could get edge-casey quickly)
16:54:34 <lruzicka> bcotton, then we arrive to "what is the basic functionality"
16:55:06 <cmurf> yeah
16:55:22 <bcotton> lruzicka: yeah, that's the stretch :-)
16:55:40 <cmurf> is it basic when VPN companies who say "we don't collect logs ever ever ever" get caught collecting logs in a huge leak of their not ever collected logs
16:55:59 <bcotton> haha, no, because that's not in Fedora :-)
16:56:13 <cmurf> :D
16:56:15 <cmurf> i know
16:56:22 <adamw> ok, this is taking too long :)
16:56:22 <cmurf> but it's complicated is the point, not basic
16:57:06 <adamw> proposed #agreed 1830343 - punt (delay decision) - we see this as a bad problem and on its face potentially a blocker, but existing criteria don't really cover it, and we're not sure exactly how broken it is yet. punting for more research on how common the bug is, and also a potential proposal of VPN-specific release criteria
16:57:14 <lruzicka> ack
16:57:17 <coremodule> ack
16:57:18 <cmurf> ack
16:57:21 <sumantro> ack
16:57:24 <adamw> for that matter, we don't really have *network* criteria, that might be good to write out...
16:57:24 <pwhalen> ack
16:57:29 <adamw> #agreed 1830343 - punt (delay decision) - we see this as a bad problem and on its face potentially a blocker, but existing criteria don't really cover it, and we're not sure exactly how broken it is yet. punting for more research on how common the bug is, and also a potential proposal of VPN-specific release criteria
16:57:37 <adamw> #topic (1856514) In default boot with 2GB of RAM or less, network install images crash with "loading repo 'rawhide' failure: write_ext(0) has failed: -1" since systemd-246~rc1-1.fc33
16:57:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1856514
16:57:37 <adamw> #info Proposed Blocker, systemd, NEW
16:58:00 <adamw> so when i proposed this as a blocker we hadn't figured out the "only with 2GB RAM or less" constraint so it was more clearly a blocker
16:58:10 <adamw> but even with that i think it's a contender
16:58:16 <adamw> install has worked with 2GB of RAM for a loooong time
16:58:30 <King_InuYasha> most of my Fedora VMs are 2GB of RAM
16:58:32 <lruzicka> does it happen on server, too?
16:58:35 <King_InuYasha> I'd be pretty sad if this doesn't work
16:58:39 <adamw> and the release notes state the minimum as 1GB
16:58:40 <adamw> https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/Hardware_Overview/
16:58:45 <adamw> lruzicka: it'll happen with any netinst, i think
16:58:55 <adamw> it doesn't happen with Server DVD because it doesn't have to populate remote repos there
16:59:00 <lruzicka> here, it is then ... +1 blocker
16:59:01 <King_InuYasha> I'd solidly put it in the blocker camp
16:59:03 <King_InuYasha> +1
16:59:09 <pwhalen> +1 blocker
16:59:31 <cmurf> +1 blocker
16:59:41 <coremodule> yeah, I think I'm definitely +1 blocker
16:59:44 <cmurf> there are other systemd-246 blockery realm bugs
16:59:54 <bcotton> +1 blocker
17:00:32 <pwhalen> on arm 1GB hasnt worked in a long time, we need to nfs mount the squashfs to do network installs on systems with 1GB . Now that fails too
17:01:32 <cmurf> what's using all that memory?
17:01:40 <cmurf> separate discussion i guess...
17:01:55 <King_InuYasha> libsolv cache generation in RAM
17:02:35 <cmurf> oh
17:03:19 <adamw> i could see us waiving this in future if someone says 'welp there's nothing we can do'
17:03:21 <adamw> but for now i guess +1 is good
17:03:44 <pwhalen> adamw: thats what happened when I filed the issue on 1GB failing
17:04:10 <pwhalen> thankfully the nfs mount work around worked.. until now
17:04:15 <adamw> proposed #agreed 1856514 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "The installer must run when launched normally from the release-blocking images" when booting release-blocking netinst images with 2GB of RAM or less. We note that 2GB is a fairly common config for VMs, and the official docs state 1GB is the minimum requirement
17:04:29 <lruzicka> ack
17:04:33 <King_InuYasha> ack
17:04:37 <coremodule> ack
17:04:41 <pwhalen> ack
17:05:17 <bcotton> ack
17:05:19 <sumantro> ack
17:05:54 <cmurf> i think there's some sort of leak or other problem because not only 2G should be enough, all these environments now have swaponzram
17:06:06 <cmurf> where before that didn't get activated in every case until anaconda launched
17:06:13 <King_InuYasha> well, swaponzram just landed, right?
17:06:15 <cmurf> i'm gonna look at it
17:06:16 <cmurf> yes
17:06:27 <cmurf> the @core change hasn't
17:06:48 <cmurf> but it's on most all other media now
17:07:12 <adamw> #agreed 1856514 - AcceptedBlocker (Beta) - this is accepted as a violation of Basic criterion "The installer must run when launched normally from the release-blocking images" when booting release-blocking netinst images with 2GB of RAM or less. We note that 2GB is a fairly common config for VMs, and the official docs state 1GB is the minimum requirement
17:08:33 <cmurf> oic what's up
17:08:36 <cmurf> cgroups related limits
17:08:52 <cmurf> mayyybe what's needed is a more aggressive zram value for he install environments...
17:09:15 <cmurf> go with 100%
17:09:39 <adamw> anyhoo
17:09:43 <adamw> continuing on!
17:09:48 <adamw> #topic (1857043) FreeIPA server deployment fails in Fedora-Rawhide-20200714.n.0 due to pki-tomcat failing to run with "java.lang.ClassNotFoundException: org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource"
17:09:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1857043
17:09:48 <adamw> #info Proposed Blocker, tomcat, NEW
17:09:53 <adamw> this one's pretty slam dunk, i think
17:10:01 <adamw> freeipa deployment don't work, it's required to work
17:10:02 <adamw> +1
17:10:06 <lruzicka> +1
17:10:08 <cmurf> haha
17:10:16 <cmurf> +1
17:10:20 <pwhalen> +1
17:10:29 <King_InuYasha> +1
17:10:40 <King_InuYasha> (I like freeipa, so I especially want it to work!)
17:12:28 <bcotton> +1
17:13:49 <adamw> proposed #agreed 1857043 - AcceptedBlocker (Beta) - accepted as a clear 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."
17:14:14 <King_InuYasha> ack
17:14:19 <pwhalen> ack
17:14:21 <lruzicka> ack
17:14:55 <coremodule> ack
17:15:00 <adamw> #agreed 1857043 - AcceptedBlocker (Beta) - accepted as a clear 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."
17:15:34 <adamw> #info that's all the proposed Beta blockers, and the only proposed Beta FE is the same openconnect bug we punted, so let's move on to...
17:15:37 <adamw> #topic Proposed Final blockers
17:15:43 <adamw> #topic (1855292) btrfs is not resizable in anaconda
17:15:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1855292
17:15:43 <adamw> #info Proposed Blocker, anaconda, NEW
17:15:54 <King_InuYasha> oh dear
17:16:46 <King_InuYasha> I'm conflicted here
17:17:10 <King_InuYasha> on one hand, btrfs *does* support shrink, but I don't know if we can get this implemented and exposed in Anaconda right now
17:18:02 <adamw> i'm -1
17:18:09 <adamw> the criterion means "if a mechanism is there it must work"
17:18:13 <adamw> it does not require that any mechanisms be there
17:18:28 <King_InuYasha> hmm that's fair
17:18:46 <King_InuYasha> we don't have a mechanism supported in anaconda right now, so I would go with -1 too
17:18:58 <bcotton> -1 for the same reason adam said (but it'd be nice if this were available)
17:19:11 <adamw> i mean, if fesco wants to require that we grow btrfs resizing as a condition of the 'btrfs by default' change that'd be one conversation
17:19:26 <adamw> but to me it's clear the criteria don't flat out require us to be able to resize all fs types
17:19:34 <King_InuYasha> yeah
17:19:37 <adamw> also i think we can't shrink xfs, right? and that's already the server default
17:19:42 <King_InuYasha> we already have this with LVM+XFS
17:19:46 <King_InuYasha> yeah, no shrinking there
17:19:51 <adamw> so it's not like we don't have precedent for not being able to shrink our own default fses :)
17:19:58 <adamw> wow, that was a lot of negatives!
17:20:00 <lruzicka> I am not sure what this means. Is it that a previously created btrfs partition cannot be shrunk in anaconda to save some space for another installation?
17:20:04 <adamw> lruzicka: yes
17:20:19 <adamw> lruzicka: it's just not a thing blivet currently supports
17:20:27 <adamw> so the installer doesn't let you try it
17:20:35 <King_InuYasha> yep
17:20:42 <lruzicka> but I would be able to shrink ext4, right?
17:20:45 <adamw> yes
17:20:55 <King_InuYasha> btrfs itself supports shrinking the filesystem, but blivet does not expose this capability
17:21:01 <lruzicka> I somehow think this is a step down
17:21:48 <lruzicka> but if we accept the this cost to introduce btrfs over ext4, then I agree, we do not push it now
17:21:56 <pwhalen> -1 blocker,  (+1 future enhancement )
17:21:57 <lruzicka> I mean creation of such functionality
17:22:05 <King_InuYasha> it's probably worth a conversation to anaconda on the difficulty of fixing this as an enhancement
17:22:26 <King_InuYasha> personally, I'd like it available in the safe subsets where anaconda doesn't have to make it complicated to shrink
17:22:50 <King_InuYasha> (e.g. weird multi-disk setups)
17:23:06 <King_InuYasha> err e.g. only single disk setups, and not weird multi-disk ones
17:23:45 <cmurf> -1 blocker
17:24:01 <lruzicka> -1 blocker
17:24:04 <cmurf> nice to have but we don't have it for the current default (lvm+ext4)
17:24:17 <King_InuYasha> cmurf: we could record this as an RFE, right?
17:24:30 <adamw> -1 blocker for me too
17:24:34 <cmurf> btrfs can do it, it's just getting udisks and libblockdev sorted out, and constrained to single device probably
17:24:48 <cmurf> yeah i think this might actually be a dup
17:25:06 <cmurf> i'm pretty sure i have an old RFE for this very think lurking in RHBZ
17:25:09 <adamw> proposed #agreed 1855292 - RejectedBlocker (Final) - it would be nice to have this feature, but we agree the criteria are not intended to require it, and we have substantial precedent for not being able to shrink our own default filesystem layouts
17:25:11 <cmurf> s/think/thing/
17:25:42 <King_InuYasha> ack
17:25:44 <lruzicka> ack
17:25:59 <lruzicka> I must go now, sorry about that. Have a nice time.
17:26:03 <bcotton> ack
17:26:08 <King_InuYasha> lruzicka: bye
17:26:10 <coremodule> ack
17:26:50 <cmurf> fwiw i've started the conversation with anaconda+libblockdev+udisks folks to support it
17:26:54 <cmurf> needed in Disks anyway
17:26:57 <adamw> #agreed 1855292 - RejectedBlocker (Final) - it would be nice to have this feature, but we agree the criteria are not intended to require it, and we have substantial precedent for not being able to shrink our own default filesystem layouts
17:26:59 <adamw> thanks lruzicka!
17:27:22 <King_InuYasha> cmurf: awesome
17:27:27 <adamw> #topic (1829079) Second session fails to start correctly when user switching
17:27:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1829079
17:27:28 <adamw> #info Proposed Blocker, gnome-shell, POST
17:27:35 <adamw> so a PR for this showed up over the weekend, I need to test it today
17:27:46 <cmurf> also gparted can do it but seriously overestimates how much it can shrink (filed multiple bugs for that)
17:27:58 <adamw> did we agree the new criterion yet? i forget
17:28:06 <cmurf> we did
17:28:11 <adamw> oh we did
17:28:11 <adamw> https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#User_switching
17:28:21 <adamw> so, pretty straightforward +1 there.
17:28:37 <cmurf> yeah it should work
17:28:40 <cmurf> +1 blocker
17:29:10 <pwhalen> +1 blocker
17:29:38 <bcotton> +1 blocker
17:29:40 <adamw> proposed #agreed 1829079 - AcceptedBlocker (Final) - accepted as a clear violation of "User switching must work using the mechanisms offered (if any) by all release-blocking desktops in their default configuration."
17:29:42 <King_InuYasha> +1
17:29:45 <King_InuYasha> ack
17:29:52 <bcotton> ack
17:29:57 <coremodule> ack
17:29:57 <cmurf> ack
17:30:50 <pwhalen> ack
17:31:08 <bcotton> ack
17:31:09 <adamw> #agreed 1829079 - AcceptedBlocker (Final) - accepted as a clear violation of "User switching must work using the mechanisms offered (if any) by all release-blocking desktops in their default configuration."
17:31:12 <adamw> okely dokely
17:31:16 <adamw> that's all the proposals!
17:31:19 <adamw> #topic Open floor
17:31:22 <adamw> any other business, folks?
17:31:52 <coremodule> as usual, I am going to have lunch, then I'll update each bug with the secretarialization
17:31:57 <coremodule> so give me an hour or so
17:34:17 <adamw> rgr
17:36:06 <King_InuYasha> I need food too...
17:36:14 <King_InuYasha> but this has gone well :)
17:36:40 * bcotton ate during the meeting
17:37:55 <cmurf> hmm i'm not having much luck with this systemd 2G RAM VM bug...
17:38:16 <cmurf> as in, it's not using more than the available swap
17:42:42 <cmurf> interesting, the bug report is netinstaller
17:42:55 <cmurf> that should need even less ram
17:45:11 <bcotton> not that anyone is waiting for this channel, but we can probably #endmeeting at this point
17:45:35 <cmurf> #endmeeting