16:11:46 <adamw> #startmeeting F33-blocker-review
16:11:46 <zodbot> Meeting started Mon Aug 17 16:11:46 2020 UTC.
16:11:46 <zodbot> This meeting is logged and archived in a public location.
16:11:46 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:11:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:11:46 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:11:46 <adamw> #meetingname F33-blocker-review
16:11:46 <adamw> #topic Roll Call
16:11:46 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:11:56 <adamw> say hi again, everyone
16:12:19 * pwhalen is here
16:12:25 <kparal> .hello2
16:12:26 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:12:30 <kalev> .hello2
16:12:31 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:12:36 <coremodule> .hello2
16:12:37 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:12:47 * coremodule willing to secretarialize.
16:12:52 <bcotton> .hello2
16:12:54 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:12:59 * bcotton unwilling to secretarialize
16:13:06 <adamw> .fire bcotton
16:13:06 <zodbot> adamw fires bcotton
16:13:17 <bcotton> ohnoes
16:13:21 <frantisekz_> .hello frantisekz
16:13:24 <zodbot> frantisekz_: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:13:52 <cmurf> bcotton is fired, guess f33 is cancelled
16:14:00 <adamw> woohoo
16:14:03 <lruzicka> .hello2
16:14:03 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:14:08 <adamw> now to stay in bed watching SGDQ all week
16:14:10 <cmurf> .hello chrismurphy
16:14:11 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:15:00 <bcotton> better than staying in bed watching GDPR
16:15:33 <adamw> it is that
16:15:34 <adamw> alrighty
16:15:50 <adamw> #chair bcotton kparal
16:15:50 <zodbot> Current chairs: adamw bcotton kparal
16:15:52 <adamw> impending boilerplate alert!
16:15:57 <adamw> #topic Introduction
16:15:57 <adamw> Why are we here?
16:15:57 <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:15:57 <adamw> #info We'll be following the process outlined at:
16:15:58 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:15:58 <adamw> #info The bugs up for review today are available at:
16:16:00 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:16:02 <adamw> #info The criteria for release blocking bugs can be found at:
16:16:05 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:16:06 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:16:08 <adamw> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:16:16 <adamw> #info for Beta, we have:
16:16:17 <adamw> #info 5 Proposed Blockers
16:16:17 <adamw> #info 5 Accepted Blockers
16:16:21 <adamw> #info 1 Proposed Freeze Exceptions
16:16:33 <adamw> #info coremodule will secretarializie
16:16:39 <adamw> ...i think that was one too many i's
16:17:14 <coremodule> its the hip way to say it
16:17:22 <adamw> let's start with...
16:17:22 <adamw> #topic Proposed Beta blockers
16:17:30 <adamw> #topic (1869140) adding a disk after make some partitions makes anaconda crash everytime
16:17:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1869140
16:17:30 <adamw> #info Proposed Blocker, anaconda, NEW
16:18:27 <adamw> hmm
16:18:34 <cmurf> hmm indeed
16:18:37 <adamw> i don't think the criterion cited really covers this
16:18:57 <cmurf> final blocker
16:19:25 <kparal> the error says "PV /dev/sda1 Already exists!"
16:19:41 <adamw> eh, even for final i find it a bit arguable
16:19:51 <adamw> it's definitely a bug, it seems like a fairly unlikely flow though, and easy enough to workaround
16:19:54 <cmurf> guided flow is not manual partitioning
16:20:02 <kparal> I wonder if the error is caused by a particular disk contents?
16:20:51 <kparal> what I'm interested in is if the existing disk contents was changed in any way before anaconda crashed
16:20:53 <kparal> that would be bad
16:21:07 <bcotton> you could make a case that it covers https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria#Custom_partitioning but it seems a little edge-case-y to me?
16:21:34 <adamw> bcotton: "add a disk" stuff is basically only in final criteria
16:21:39 <adamw> https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#Network_attached_storage
16:22:46 <bcotton> ah, i missed that it was network-attached
16:22:50 <cmurf> +1 final blocker
16:22:55 <cmurf> -1 beta blocker
16:23:06 <pwhalen> +1 final blocker as well
16:23:09 <bcotton> -1 BB, +1 FB
16:23:14 <adamw> what criterion are we citing for final blocker?
16:23:24 <adamw> i'm definitely -1 beta but i'm not really feeling +1 final for sure at least yet
16:24:53 <bcotton> I'd say "The installer must be able to detect (if possible) and install to supported network-attached storage devices. " because if it crashes, you can't install to it
16:25:07 <cmurf> well it shouldn't crash
16:25:12 <frantisekz_> -1 beta blocker
16:25:22 <lruzicka> I feel blockery about the crash +1 final, -1 beta
16:25:27 <adamw> bcotton: it's not like this always happens though
16:25:34 <adamw> only if you do one specific kinda unusual flow
16:25:55 <jlanda> -1bb +1fb. Removing the add button on that particular scenario would be enough to unblock
16:26:04 <adamw> if you know you're going to be installing to an iSCSI/FCoE/whatever disk it's kind of weird to first make some partitions, *then* go back out and add that disk, *then* go back into custom partitioning
16:26:12 <lruzicka> it is unusual but sort of last help thing
16:26:47 <lruzicka> like, hey ... I also want to use the iSCSI
16:27:00 <adamw> ok, i request that someone who is +1 final blocker on this write the proposed #agreed text :P
16:27:36 <bcotton> i'd be okay with punting on a final blocker decision, but i'm not sure what we'd wait for other than hoping it gets fixed before we have to make a decision so we don't have to decide :-)
16:29:31 <lruzicka> adamw, I do not feel so strong to formulate it, unless you want to wait for some time.
16:29:40 <adamw> wusses
16:29:41 <adamw> :P
16:29:45 <adamw> let's just whiff on it for now
16:30:28 <bcotton> i guess we could wait and see if there are other cases where the crash is triggered
16:30:42 <adamw> proposed #agreed 1869140 - RejectedBlocker (Beta) - we do not believe this violates the Beta criteria (the cited criterion refers to "guided partitioning" but the bug involves using custom partitioning, and network storage devices are only in the Final criteria). there is some support for making this a Final blocker but not clear enough to accept it yet
16:30:46 <bcotton> if it's really just this one workflow, my +1 is a lot weaker
16:30:51 <bcotton> ack
16:31:14 <cmurf> ack
16:31:20 <frantisekz_> ack
16:31:23 <kparal> ack
16:31:25 <lruzicka> ack
16:31:31 <adamw> #agreed 1869140 - RejectedBlocker (Beta) - we do not believe this violates the Beta criteria (the cited criterion refers to "guided partitioning" but the bug involves using custom partitioning, and network storage devices are only in the Final criteria). there is some support for making this a Final blocker but not clear enough to accept it yet
16:31:50 <adamw> #topic (1869102) ipxe-roms-qemu-20190125-7 breaks UEFI-based VMs (won't boot)
16:31:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1869102
16:31:50 <adamw> #info Proposed Blocker, edk2, NEW
16:32:06 <cmurf> i'm hitting this
16:32:21 <kparal> cmurf: did the downgrade solve it?
16:32:24 <cmurf> applies to uefi vms, not bios vms
16:32:26 <cmurf> yes
16:32:45 <adamw> so it's a conditional violation, and most people use BIOS VMs I think, but...i'm probably still +1
16:32:50 <kparal> +1
16:32:54 <frantisekz_> does anything create uefi vms by default (eg. GNOME Boxes)?
16:33:03 <cmurf> no
16:33:12 <frantisekz_> -1 then for beta from me
16:33:25 <kparal> yeah, sounds reasonable to move this to final
16:33:37 <lruzicka> +1, even we need EFI Vms to test
16:33:40 <cmurf> well we need to be able to test uefi in vm's during beta
16:33:46 <lruzicka> cmurf, exactly
16:33:47 <cmurf> reduces test coverage
16:33:59 <adamw> i mean, you can always run the VM on F32 :P
16:34:00 <kparal> you have a point
16:34:04 <adamw> but still, think i'm still +1
16:34:07 <adamw> this oughta work
16:34:19 <lruzicka> adamw, but is not one of the criteria to run a VM on a current version?
16:34:25 <cmurf> and there's a work around
16:34:26 <lruzicka> at least it is one of the tests
16:35:19 <bcotton> +1, weakly (would be strong if uefi VMs were a default on anything)
16:35:27 <pwhalen> +1 blocker, I havent hit this but uefi is the default on aarch64
16:35:36 <adamw> lruzicka: yeah, it's just that this is conditional so we have more room to consider "circumstances"
16:35:43 <adamw> pwhalen: that's also a point
16:35:47 <adamw> can't use BIOS on every arch
16:36:10 <adamw> pwhalen: would be useful to know if this happens on aarch64 too i guess, if you can test
16:36:32 <pwhalen> adamw: will do
16:36:39 <adamw> proposed #agreed 1869102 - AcceptedBlocker (Beta) - accepted as a conditional violation of "The release must be able host virtual guest instances of the same release" (when the virtual guest instance is using UEFI)
16:37:00 <bcotton> ack
16:37:03 <cmurf> ack
16:37:27 <pwhalen> ack
16:37:29 <coremodule> ack
16:37:36 <lruzicka> ack
16:38:14 <adamw> #agreed 1869102 - AcceptedBlocker (Beta) - accepted as a conditional violation of "The release must be able host virtual guest instances of the same release" (when the virtual guest instance is using UEFI)
16:38:24 <adamw> #topic (1869335) error: ../../grub-core/net/net.c:1795:timeout reading initrd.img
16:38:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1869335
16:38:24 <adamw> #info Proposed Blocker, grub2, NEW
16:39:14 <pwhalen> I just hit this today, spoke with javier__ who is going to take a closer look tomorrow.
16:39:31 <adamw> hm
16:39:39 <adamw> test passed on x86_64 on most recently rawhide nightly
16:39:40 <adamw> https://openqa.fedoraproject.org/tests/641434
16:40:07 <adamw> 33 nightly i can't tell because we need to add 33 ident needles, agh
16:40:10 <cmurf> is this on real hardwar eor vm?
16:40:12 <adamw> let's do that
16:40:34 <pwhalen> cmurf: was on hw
16:40:48 <cmurf> ok so no related to ipxe-rom-qemu
16:40:55 <pwhalen> hit it on the rpi4, and enterprise hw
16:41:30 <cmurf> seems like a clear blocker
16:42:00 <adamw> yeah, i guess even if it's aarch64-only it's a blocker, since that's a blocking arch
16:42:01 <adamw> so +1
16:42:08 <pwhalen> +1 for me too
16:42:19 <lruzicka> +1
16:42:27 <cmurf> +1 beta blocker
16:42:33 <bcotton> +1
16:42:36 <frantisekz_> +1
16:42:59 <coremodule> +1
16:44:01 <adamw> proposed #agreed 1869335 - AcceptedBlocker (Beta) - accepted as a violation of "It must be possible to install by booting the installation kernel directly (including via PXE)..." there's some question about how many scenarios this affects, but it at least affects some significant aarch64 platforms
16:44:11 <coremodule> ack
16:44:32 <cmurf> ack
16:44:50 <pwhalen> ack
16:45:07 <bcotton> ack
16:45:10 <adamw> #agreed 1869335 - AcceptedBlocker (Beta) - accepted as a violation of "It must be possible to install by booting the installation kernel directly (including via PXE)..." there's some question about how many scenarios this affects, but it at least affects some significant aarch64 platforms
16:45:11 <lruzicka> ack
16:45:21 <adamw> #topic (1863041) systemd-resolved.service not work with DNS server placed behind VPN (openconnect)
16:45:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1863041
16:45:21 <adamw> #info Proposed Blocker, systemd, NEW
16:46:27 <adamw> i do wonder if we should have specific VPN criteria, sometimes...
16:47:03 <cmurf> yeah i'm not sure what criterion applies, beta or final
16:47:39 <cmurf> similar to the systemd-resolved induced regression of mDNS...
16:47:41 <adamw> i mean we don't even really have a clear "teh intarwebz must werk" criterion
16:47:49 <bcotton> yeah, i just noticed that
16:47:54 <adamw> we have to infer it from things like package update requirements
16:48:03 <adamw> which is tricky for VPN stuff as your package update source is not likely to be behind a VPN
16:49:23 <cmurf> the impetus of systemd-resolved is to make vpn stuff better, not cause regressions like this
16:49:43 <cmurf> so i think it'll get fixed, but yeah no criterion
16:49:53 <michel_slm> late to the meeting, but chiming in here - we do have internal package repos behind VPN
16:50:02 <michel_slm> (we == my workplace)
16:50:53 <bcotton> michel_slm: are those internal package repos or fedora mirrors?
16:51:01 <adamw> the closest thing we could crowbar it in under is probably "Default application functionality" for apps that use network resources
16:51:03 <adamw> but that's a stretch
16:51:39 <cmurf> that'd be for final though right
16:51:40 <michel_slm> bcotton: internal package repos; and we mark them as skip_if_unavailable so Fedora updates are not affected
16:51:44 <adamw> so, we could possibly agree that we want to add explicit network functionality criteria, including VPN, and accept this under that...or punt it for proposal and discussion of criteria
16:52:01 <adamw> i think i'd probably be in favor of punting for proposal+discussion as it's a complex area
16:52:32 <cmurf> +1 punt
16:52:37 <bcotton> yeah, punting for proposal sounds good. i think this should block somehow, but i'm not convinced it should block beta
16:53:05 <pwhalen> +1 punt
16:53:22 <cmurf> i think it's a final blocker not beta
16:53:24 <cmurf> however
16:53:52 <adamw> yeah, that might be the outcome
16:54:09 <cmurf> if it were more broad than just openconnect vpn, i might get on board using the beta catch all 'reduces test coverage'
16:54:21 <cmurf> which isn't the case here
16:54:40 <adamw> proposed #agreed 1863041 - punt (delay decision) - this bug really points up an inadequacy of the criteria: we don't have explicit network or VPN criteria, and it'd just be too much of a stretch to crowbar this into any existing criterion. so we are punting on the decision to propose and discuss explicit network/VPN criteria
16:54:47 <cmurf> ack
16:54:50 <coremodule> ack
16:55:10 <kparal> ack
16:55:29 <pwhalen> ack
16:55:49 <lruzicka> ack
16:56:50 <adamw> #agreed 1863041 - punt (delay decision) - this bug really points up an inadequacy of the criteria: we don't have explicit network or VPN criteria, and it'd just be too much of a stretch to crowbar this into any existing criterion. so we are punting on the decision to propose and discuss explicit network/VPN criteria
16:56:58 <adamw> #topic (1861463) zram-setup@zram0.service: Failed to load configuration: No such file or directory
16:56:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861463
16:56:58 <adamw> #info Proposed Blocker, udisks2, NEW
16:57:19 <cmurf> oh man... this one
16:57:43 <adamw> well that sounds ominous
16:57:53 <pwhalen> cmurf: the good news is, it looks to be gone with the latest compose I tested
16:58:04 <cmurf> oh thank the maker
16:58:11 <pwhalen> heh, I said the same
16:58:16 <cmurf> i was gonna say it's malware and baked into your firmware
16:58:24 <cmurf> because i can't find it anywhere
16:58:52 <pwhalen> and qemu worked the entire time..
16:59:00 <cmurf> udisks2-zram has a udisks modules and udev rules - and that stuff isn't on armv7hl or aarch64 images
17:00:00 <cmurf> let's just call it a poltergeist experience and not ask more questions, hopefully it's just gone
17:00:33 <cmurf> i definitely feel slimed though haha
17:00:53 <adamw> if it's working now i'm fine with just close it and move on
17:00:59 <adamw> we can re-open and be sad later if it comes back?
17:01:18 <bcotton> WFM
17:01:21 <cmurf> sound good to me
17:02:39 <adamw> #info according to pwhalen this bug has mysteriously gone away again, so we'll close the report for now and hope it never comes back
17:02:51 <adamw> ok, let's move onto...
17:03:03 <adamw> #topic Proposed Beta freeze exception
17:03:06 <adamw> #topic (1863041) systemd-resolved.service not work with DNS server placed behind VPN (openconnect)
17:03:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1863041
17:03:07 <adamw> #info Proposed Freeze Exceptions, systemd, NEW
17:03:09 <adamw> oh hey, this one again
17:03:36 <cmurf> i'm not opposed to FE
17:03:42 <cmurf> but we aren't in freeze for a week
17:03:43 <adamw> yeah, there's reasons to use VPN from a live image
17:03:52 <adamw> cmurf: that's close enough to start reviewing FE proposals i think
17:03:56 <adamw> weeks go by fast :P
17:03:59 <bcotton> +1 FE
17:04:02 <adamw> so i'd be +1 FE
17:04:09 <cmurf> even 6/7ths of a week
17:04:23 <cmurf> or wait, 8/7ths
17:04:25 <cmurf> +1 FE
17:04:46 <lruzicka> +1 FE
17:05:12 <pwhalen> +1 FE
17:05:18 <adamw> proposed #agreed 1863041 - AcceptedFreezeException (Beta) - it seems reasonable to grant this an FE as someone may want to access an affected VPN from a live image and that would be difficult with this bug
17:06:14 <cmurf> ack
17:06:20 <coremodule> ack
17:06:27 <kparal> ack
17:06:49 <michel_slm> ack
17:06:53 <pwhalen> ack
17:07:48 <bcotton> ack
17:08:02 <cmurf> i think we need more acks
17:08:22 <lruzicka> ack
17:08:25 <cmurf> any Martians around?
17:08:36 <coremodule> my last name is Marr...
17:08:49 <lruzicka> cmurf, I have a friend called Martha, do Marthians count as well?
17:09:05 <adamw> #agreed 1863041 - AcceptedFreezeException (Beta) - it seems reasonable to grant this an FE as someone may want to access an affected VPN from a live image and that would be difficult with this bug
17:09:07 <cmurf> haha it's a very obscure reference to Mars Attacks!
17:09:15 <adamw> sorry, i was busy not paying attention
17:09:19 <cmurf> where the martians only say "ack ack ack!"
17:09:20 <cmurf> haha
17:09:25 <adamw> ok, let's do a quick review of the accepted blockers
17:09:31 <adamw> #topic Accepted Beta blocker check-in
17:09:46 <adamw> once more for the cheap seats: we are not revoting here, just checking on progress with resolving them
17:09:46 <adamw> #topic (1860616) abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33
17:09:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1860616
17:09:46 <adamw> #info Accepted Blocker, libreport, POST
17:10:07 <adamw> so getting the fix for this actually into f33 is allegedly "in the works"
17:10:12 <adamw> i'll give them a bit longer then just do it myself
17:10:22 <adamw> oh, right, they did do a libreport release, didn't they?>
17:10:24 <adamw> it went...poorly
17:10:31 <adamw> well fun.
17:10:58 <adamw> sigh, i guess i get to bust some heads
17:11:13 <adamw> #info a new libreport release was attempted last week, but badly muffed and has been untagged for the moment
17:11:40 <cmurf> zoiks
17:11:56 <adamw> hmm, wait
17:11:59 <adamw> #undo
17:11:59 <zodbot> Removing item from minutes: INFO by adamw at 17:11:13 : a new libreport release was attempted last week, but badly muffed and has been untagged for the moment
17:12:28 <adamw> they did a new fricking libreport 2.14.0 build
17:12:31 <adamw> but still didn't rebuild abrt
17:12:32 <adamw> wtaf
17:13:13 <adamw> okay, fortunately that build hasn't made any composes yet
17:13:21 <cmurf> a for actual
17:14:08 <adamw> yes
17:14:31 <bcotton> i might even upgrade it to wt-entire-f
17:14:38 <adamw> #info a new libreport release was attempted last week, but had all kinds of problems and was untagged; a new one was done today but the problems aren't fixed so it may need untagging again
17:15:02 <adamw> #action adamw to find some people to yell at to get this mess dealt with properly
17:15:13 <cmurf> :D
17:17:14 <adamw> #topic (1866570) FreeIPA deployment fails in current Rawhide due to various issues with Java 11
17:17:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1866570
17:17:14 <adamw> #info Accepted Blocker, resteasy, NEW
17:18:17 <bcotton> i haven't seen a hot potato get passed around this much since my last birthday party
17:18:21 <adamw> heh
17:18:27 <adamw> well, big picture, freeipa deployment still fails
17:18:35 <adamw> i have not looked at the logs of the latest composes yet to see if the details have changed
17:18:44 <adamw> i'm kinda trusting freeipa team to solve this
17:18:59 <adamw> but we may have to switch to 'trust but verify' at some point...
17:19:02 <adamw> ab: around? any thoughts?
17:20:23 <ab> adamw: we should back out to java 8
17:21:25 <ab> adamw: I asked cipherboy to join the meeting, as that's affects pki-core
17:21:36 <lruzicka> ab, would 10 not be enough?
17:21:55 <ab> lruzicka: I meant 'previous' java version it worked with
17:22:32 <cmurf> wow that's a significant revert
17:22:49 <cmurf> lruzicka: i think they want to stay on lts versions but i'm not sure
17:22:51 <adamw> ab: so basically you don't think we can get it working with java 11 in time?
17:22:52 <Eighth_Doctor> it's also probably not needed
17:22:57 <adamw> ab: would having parallel javas be acceptable?
17:23:02 <adamw> i think that's a thing we can do
17:23:15 <Eighth_Doctor> we already have the parallel java thing
17:23:20 <adamw> right, that's what i meant
17:23:26 <Eighth_Doctor> though it's very concerning that this is broken on Fedora and not Debian or openSUSE
17:23:30 <ab> adamw: I do not see any effort happening on fixing it.
17:23:49 <adamw> Eighth_Doctor: i don't see how that can be the case. are they actually running freeipa on java 11 and testing it and it's worknig?
17:23:52 <adamw> i mean, we write the damn thing
17:23:54 <ab> Eighth_Doctor: I don't think it is not broken on Debian. There is simply no data as there is no working FreeIPA there.
17:24:04 <Eighth_Doctor> adamw: Debian does at least
17:24:09 <adamw> ab seems to disagree
17:24:31 <Eighth_Doctor> adamw: Fedora's Java stack has been, to be blunt, borked, for three years
17:24:57 <ab> Eighth_Doctor:  it is not about Fedora Java stack. It is about a set of components that aren't yet supported on Java 11
17:25:02 <Eighth_Doctor> I'm fine with ab disagreeing with me, but I know Debian is shipping FreeIPA Server with Java 11
17:25:05 <ab> as of in released versions
17:25:09 <cipherboy> \o
17:25:24 <ab> cipherboy has the best knowledge about the current state of affairs
17:26:10 <adamw> Eighth_Doctor: shipping it doesn't mean it's working.
17:26:17 <Eighth_Doctor> pki-core is built against Java 11 in Debian unstable right now: https://packages.debian.org/sid/dogtag-pki
17:26:19 <adamw> we're shipping it on java 11 as well. :D
17:26:25 <adamw> it just doesn't *work*.
17:26:36 <Eighth_Doctor> adamw: well, we're not really doing that, pki-core FTBFS on Java 11
17:26:47 <cipherboy> I've been on PTO since the 7th and just came back. This is now top on my plate to look at, but this probably needs a real tracker + additional bugs assigned against other components from status on Friday.
17:26:49 <Eighth_Doctor> it's been that way for a few months
17:26:52 <adamw> still, "it builds" and "it works" are very different things.
17:27:06 <cipherboy> Now, decathorpe has done a lot of JDK11 work in the mean time, so perhaps all our deps have magically been fixed, but I don't think so.
17:27:11 <ab> https://packages.debian.org/sid/pki-base-java built against openjdk 8 in Debian
17:27:17 <cipherboy> I'm inclined to revert to JDK8 in the mean time and rebuild in rawhide.
17:27:36 <cipherboy> (in PKI)
17:27:52 <adamw> well, whatever we're gonna do, it would be good to get it started ASAP, so we have as much time as possible to make sure it actually works before beta release
17:27:55 <ab> that's what I suggested too, sorry for using 'java 8' instead of 'jdk 8'
17:28:17 <cipherboy> ab: Sorry, didn't see you suggest that, I just joined :) But yes, I'm +1 for that.
17:28:21 <Eighth_Doctor> meh, whatever, we can keep default Java 11 and have PKI use Java 8
17:28:27 <adamw> less than a month to beta release date
17:28:41 <Eighth_Doctor> that's why we don't remove old Java versions anyway
17:28:45 <ab> jdk8 version of Dogtag is stable and in production
17:29:07 <cipherboy> Eighth_Doctor: pki-core built on Rawhide with JDK11, but like adamw pointed out, it builds but doesn't work. I could close the FTBFS bug but that gets us nowhere.
17:29:14 <adamw> #info ab/cipherboy suggest that we may need to build dogtag against an older Java at least for Beta, however the details of that are worked out exactly
17:29:15 <cipherboy> Plus, rawhide is currently broken due to glibc anyhow.
17:29:28 <Eighth_Doctor> right, there's that at the moment
17:29:35 <Eighth_Doctor> that can be worked around locally though
17:29:45 <Eighth_Doctor> and it doesn't affect Koji
17:29:58 <Eighth_Doctor> (by virtue of Koji not supporting secure builds with mock)
17:30:09 <adamw> #info we've asked the team to start doing whatever they're going to do ASAP so we have as much time as possible to get it working before Beta release
17:30:33 <adamw> i guess that covers it
17:30:47 <adamw> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
17:30:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
17:30:47 <adamw> #info Accepted Blocker, sddm, NEW
17:30:51 <adamw> thanks ab/cipherboy
17:31:40 <adamw> #info kamil is working on debugging this, it seems not straightforward to solve
17:32:00 <adamw> any other details, kparal?
17:33:40 <kparal> well, I added all details I could
17:33:52 <kparal> I'm waiting on some developer input
17:34:17 <adamw> rgr
17:34:25 <adamw> #info waiting on developer feedback on kparal's latest debugging
17:34:33 <adamw> #topic (1862686) SELinux is preventing systemd-machine from 'create' accesses on the sock_file io.systemd.Machine.
17:34:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1862686
17:34:33 <adamw> #info Accepted Blocker, selinux-policy, POST
17:35:15 <adamw> #info this is in POST, so we're just waiting on a new selinux-policy build. we're not sure yet if more fixes will be needed after the initial one
17:35:30 <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:35:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1857043
17:35:30 <adamw> #info Accepted Blocker, tomcat, MODIFIED
17:35:44 <adamw> #info this one is still kind of "behind" the general FreeIPA vs. Java 11 issue, we'll know if this is resolved once that's resolved
17:35:53 <adamw> #topic Open floor
17:35:55 <adamw> that's about all I had
17:35:57 <adamw> any other business, folks?
17:36:17 * pwhalen has nothing else
17:36:28 <bcotton> just a heads up that i have a stack of "image too large" BZs assigned to me that I'll be dealing with in the next day or two
17:36:36 <bcotton> so there may be a few autoblockers that show up
17:37:05 <adamw> the magic script *should* propose them as blockers when they're blocker images
17:37:09 <adamw> of course, it might be busted!
17:37:21 <bcotton> i guess we'll find out :-D
17:39:00 <cmurf> thinking we can deprecate the bootloader selection criterion
17:39:04 <cmurf> maybe an email on test@
17:39:10 <adamw> hmm, apparently it is, cos https://bugzilla.redhat.com/show_bug.cgi?id=1827915 is definitely release-blocking...
17:39:18 * adamw goes to kick the magic script
17:40:34 <adamw> welp, guess i've got a bug to fix
17:41:47 <bcotton> is your magic script release blocking? ;-)
17:42:26 <lruzicka> adamw itself is release blocking, bcotton
17:42:31 <lruzicka> himself
17:42:42 <adamw> haha
17:42:45 <adamw> so hum
17:42:58 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1849431 and https://bugzilla.redhat.com/show_bug.cgi?id=1827915 should be blockers i believe
17:43:00 <adamw> i'll set those
17:44:47 <adamw> thanks for the heads-up, bcotton
17:44:50 <adamw> anything else, folks?
17:45:03 <lruzicka> no, afaik
17:46:27 <adamw> ok, thanks for coming, everyone!
17:47:41 <adamw> #endmeeting