16:05:45 <adamw> #startmeeting F31-blocker-review
16:05:45 <zodbot> Meeting started Mon Jul 15 16:05:45 2019 UTC.
16:05:45 <zodbot> This meeting is logged and archived in a public location.
16:05:45 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:45 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:05:45 <adamw> #meetingname F31-blocker-review
16:05:45 <adamw> #topic Roll Call
16:05:46 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:05:50 <adamw> alright, we're on tape now
16:05:53 <adamw> everyone stop beating patrick
16:06:03 <puiterwijk> hah.
16:06:06 <nb> .hi
16:06:07 <zodbot> nb: nb 'Nick Bebout' <nick@bebout.net>
16:06:09 <frantisekz> .hello2
16:06:10 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:06:14 <lruzicka2> .hello lruzicka
16:06:15 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:06:41 <kparal> .hello2
16:06:42 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:06:44 <coremodule> .hello2
16:06:45 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:06:56 * satellit_ listening
16:06:58 <cmurf> .hello chrismurphy
16:06:59 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:07:44 <coremodule> Willing to act as secretary on this first F31 blocker review!
16:07:45 * kparal looking into blocker list
16:07:47 <kparal> geez, I signed up for discussing modularity bugs? should have known beforehand
16:08:10 <cmurf> kparal: what were you thinking?
16:08:22 <kparal> I was being naive today
16:08:31 <adamw> thanks coremodule
16:08:50 * pwhalen is here
16:09:10 <adamw> #chair kparal frantisekz
16:09:10 <zodbot> Current chairs: adamw frantisekz kparal
16:09:20 <adamw> impending boilerplate alert!
16:09:20 <adamw> #topic Introduction
16:09:21 <adamw> Why are we here?
16:09:21 <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:21 <adamw> #info We'll be following the process outlined at:
16:09:21 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:24 <adamw> #info The bugs up for review today are available at:
16:09:25 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:27 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:29 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:31 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria
16:09:33 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria
16:09:41 <adamw> #info for Beta, we have:
16:09:43 <adamw> #info 7 Proposed Blockers
16:09:43 <adamw> #info 1 Accepted Blockers
16:09:48 <adamw> #info 1 Proposed Freeze Exceptions
16:09:52 <adamw> #info for Final, we have:
16:10:03 <adamw> #info 2 Proposed Blockers
16:10:10 <adamw> #info coremodule will secretarialize
16:10:30 <adamw> alrighty, let's get started with proposed Beta blockers
16:10:32 <adamw> isn't this exciting
16:10:39 <adamw> #info starting with proposed Beta blockers
16:10:53 <coremodule> I'm so excited
16:10:54 <adamw> #topic (1616167) provide fail-safe mechanisms when repos with modulemd are unavailable/disabled and when repos lose modulemd by accident
16:10:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1616167
16:10:55 <adamw> #info Proposed Blocker, dnf, POST
16:10:59 <adamw> so this is a Greatest Hit
16:11:13 <cmurf> great bug number too
16:11:16 <adamw> it's the thing we first decided should definitely block the release of 28 or 29 or something then it turned out to be hard so we were like 'eh whatever'
16:11:21 <adamw> software: we're great at it
16:11:33 <cmurf> haha
16:11:41 <adamw> so at this point i kinda agree with sgallagh's comment
16:12:00 <frantisekz> yep
16:12:08 <adamw> we're clearly okay on a cosmic level with shipping fedoras that don't have this, so deciding that it blocks the f31 release just because we actually think there's a whelk's chance in a supernova that it'll get done this round seems arbitrary
16:12:12 <cmurf> yep, baring some convincing contra agrument
16:12:28 <adamw> and let's face it, if dnf team said 'oh whoops we can't actually do it this time sorry' we'd just waive it
16:12:31 <adamw> so, let's not pretend...
16:12:41 <pwhalen> agreed, -1
16:12:59 <lruzicka2> -1
16:13:03 <cmurf> whelk is a new word, that'd be a great nick
16:13:15 <cmurf> sea snail
16:13:16 <adamw> cmurf: i stole that line from either H2G2 or Red Dwarf. i forget which.
16:13:25 <lruzicka2> I do not thing they will have time to fix it anyway
16:13:41 <sgallagh> By coincidence, it's actually done already.
16:13:43 <cmurf> -1 blocker
16:13:47 <sgallagh> But it shouldn't be a blocker if there are issues with it.
16:14:11 <lruzicka2> sgallagh, hah, will have to test it the first thing in the morning
16:14:12 * cmurf will brb, laundry
16:14:15 <sgallagh> (Though implementing it discovered some interesting bad assumptions elsewhere)
16:14:22 <sgallagh> So it's temporarily turned back off
16:14:24 <frantisekz> so, -1 Blocker and, do we wanna talk about FE, or not yet at this point?
16:14:40 <lruzicka2> sgallagh, ok, I see
16:16:10 <adamw> beta freeze isn't for a month and a half, so, probably not worth considering yet
16:16:27 <adamw> and honestly this doesn't seem like the kind of thing to be implementing in a freeze
16:17:34 <adamw> proposed #agreed 1616167 - RejectedBlocker (Beta) - as we shipped the last two releases without this, it seems arbitrary to start blocking on it now just because it might actually be ready this cycle. Clearly we've established a precedent that it's OK to release Fedora without it. We'd still like to see it done, though
16:17:55 <frantisekz> ack
16:17:58 <lruzicka2> ack
16:18:18 <cmurf> ack
16:18:20 <kparal> ack
16:18:38 <cmurf> shoulda said bACK
16:18:40 <adamw> #agreed 1616167 - RejectedBlocker (Beta) - as we shipped the last two releases without this, it seems arbitrary to start blocking on it now just because it might actually be ready this cycle. Clearly we've established a precedent that it's OK to release Fedora without it. We'd still like to see it done, though
16:18:44 <pwhalen> ack
16:19:19 <adamw> #topic (1717117) Can't install module libgit2:0.28 due to (uninstalled) conflicts
16:19:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1717117
16:19:19 <adamw> #info Proposed Blocker, dnf, NEW
16:19:22 <adamw> oh good, this one
16:19:29 <adamw> why did i decide to have this meeting, this was a bad idea
16:19:33 <adamw> let's all go back to bed
16:19:51 <frantisekz> or to bed already, in CET :)
16:20:07 <adamw> potato, potahto (seriously though who says potahto?)
16:20:27 <lruzicka2> tomato, tomahto
16:20:43 <lruzicka2> let's call the whole thing off?
16:21:30 <adamw> so uh
16:21:32 <adamw> where are we at with this
16:21:32 <frantisekz> so, to the topic, I see -1 from sgallagh there, but isn't this breaking some installs, as anaconda bails out if it sees some dnf error?
16:21:36 <coremodule> hmmm
16:21:49 <coremodule> I can't find a criteria this violates directly
16:21:57 <adamw> this isn't breaking anaconda atm
16:22:00 <sgallagh> If it's breaking installs (first I've heard), then that's a problem.
16:22:05 <adamw> it *was*
16:22:07 <adamw> but that changed
16:22:16 <adamw> either we fixed anaconda not to blow up or at present anaconda doesn't get the warning from dnf
16:22:49 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1719976 is still NEW
16:23:46 <adamw> but yeah, it's definitely not actually breaking installs any more.
16:23:53 <adamw> i can be -1 beta blocker on that basis
16:24:17 <adamw> i'd be sad about shipping final with the problem, though, because you get told about the error every time you run dnf for anything at all
16:24:41 <frantisekz> yeah, -1 if it's not breaking anything, we can discuss this again for final though
16:24:49 <sgallagh> Also, according to ignatenkobrain this morning, the workaround packages have been built over the weekend; I think this BZ might need updating with that in mind.
16:25:10 <cmurf> punt
16:25:11 <lruzicka2> agree, I would consider +1 for final, at the moment I vote -1
16:25:36 <pwhalen> -1 beta blocker
16:25:39 <adamw> we can agree -1 for beta and re-propose for final
16:25:53 <lruzicka2> if it does not break installations, I do not see why would not vote -1 for beta, cmurf
16:25:55 <adamw> though it's not clear what criterion it'd violate even for final i guess
16:26:10 <frantisekz> (we apparently don't have any criteria for this even for final, but we can make some if it's still not fixed :) )
16:26:32 <adamw> yeah
16:26:34 <adamw> anyhoo
16:26:40 <coremodule> -1 beta blocker
16:26:42 <lruzicka2> adamw, errors like that do not look good
16:26:42 <cmurf> ok -1 beta blocker
16:27:32 <adamw> proposed #agreed 1717117 - RejectedBlocker (Beta) - at the moment nothing about this seems to be violating any release criteria, it only results in an annoying error message showing up all the time, and a non-essential module not being installable. This is acceptable for Beta. We will re-propose it as a Final blocker in case it's not fixed by then
16:27:53 <frantisekz> ack
16:27:55 <coremodule> ack
16:28:01 <pwhalen> ack
16:28:20 <lruzicka2> ack
16:28:21 <kparal> ack
16:28:57 <adamw> #agreed 1717117 - RejectedBlocker (Beta) - at the moment nothing about this seems to be violating any release criteria, it only results in an annoying error message showing up all the time, and a non-essential module not being installable. This is acceptable for Beta. We will re-propose it as a Final blocker in case it's not fixed by then
16:29:10 <adamw> #topic (1723777) gnutls-dane depends on unbound-libs which creates huge bootstrap loop
16:29:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1723777
16:29:10 <adamw> #info Proposed Blocker, gnutls, NEW
16:29:49 <cmurf> ok so it prevents installation of systemd?
16:30:19 <adamw> uh.
16:30:25 <adamw> i'm a bit confused here.
16:30:33 <adamw> i doubt it? or else nothing would build or work at present at all.
16:30:38 <coremodule> me too...
16:30:42 <adamw> ok, we haven't had a compose since friday, but this is not why.
16:31:46 <adamw> hm
16:31:54 <adamw> it looks like the *original* problem here was serious
16:31:58 <adamw> but that got fixed/worked around
16:31:59 <cmurf> if I read any two comments, I become confused
16:32:04 <adamw> and now igor re-opened to bug to request some dependency trimming
16:32:18 <adamw> so i'm gonna say i'm -1 to what the bug is currently about
16:33:28 <cmurf> if I ignore comment 18 by sgallagh then I'm a -1
16:33:48 <sgallagh> I am completely willing to believe I failed to follow the conversation
16:34:28 <kparal> -1, also seems like the major problem got resolved. let them re-propose if it's not the case
16:34:44 <cmurf> it looks like that was the case and then it got fixed, and the name of the bug was changed
16:35:21 <pwhalen> agreed, -1
16:35:31 <coremodule> -1 blocker
16:35:35 <cmurf> -1 blocker
16:35:47 <sgallagh> -1
16:36:12 <lruzicka2> -1 blocker
16:37:06 <adamw> right
16:37:13 <adamw> it can always be re-proposed if we misunderstood
16:38:08 <adamw> proposed #agreed 1723777 - RejectedBlocker (Beta) - our understanding is that the initial problem covered by this bug indeed was a blocker (it would've prevented composes), but that issue was resolved and now the bug has been re-opened for a different and less critical reason (see comment #14). as we understand the current issue, it does not violate any criteria
16:38:21 <lruzicka2> ack
16:38:32 <coremodule> ack
16:38:43 <sgallagh> ack
16:38:44 <pwhalen> ack
16:38:53 <kparal> ack
16:40:39 <adamw> #agreed 1723777 - RejectedBlocker (Beta) - our understanding is that the initial problem covered by this bug indeed was a blocker (it would've prevented composes), but that issue was resolved and now the bug has been re-opened for a different and less critical reason (see comment #14). as we understand the current issue, it does not violate any criteria
16:40:45 <adamw> #topic (1724380) 3DES removal breaks credential acquisition
16:40:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1724380
16:40:46 <adamw> #info Proposed Blocker, krb5, POST
16:41:05 <adamw> so, sgallagh's question here is a good one. i think punting on this is a good idea atm
16:41:32 <adamw> the openqa test no longer hits this on upgrade from clean deployments on updated f30 to rawhide, but that doesn't *necessarily* mean there's no longer a blocker bug, it'd be good to wait for clarification
16:42:04 <cmurf> there is a fix that will be backported for F30, and since the requirement is that you update before upgrading, you should hit this bug
16:42:11 <cmurf> ^shouldn't
16:42:19 <coremodule> adamw, I can get behind that train of thought
16:43:09 <sgallagh> cmurf: The problem is that it may be that F30 upgraded from GA to current may end up in a situation where upgrading from there to F31 hits it
16:43:19 <cmurf> right
16:43:21 <sgallagh> Where a fresh install of F30-plus-latest doesn't
16:43:36 <frantisekz> but, we don't support upgrading from fresh F30 if I am not mistaken
16:43:39 <sgallagh> If that's the case, I'd call it a blocker.
16:43:44 <sgallagh> frantisekz: You're misunderstanding.
16:43:52 <frantisekz> it's possible :)
16:44:04 <sgallagh> We know that if someone installs the latest FreeIPA (4.8.0) on F30 and then upgrades to F31, it is fine.
16:44:17 <frantisekz> oh, I see now
16:44:18 <sgallagh> And if they upgrade from 4.7 on F30 -> 4.8 on F31 it is not.
16:44:31 <sgallagh> We don't know if F30 4.7->4.8->F31 is fine
16:44:39 <lruzicka2> sgallagh, DNF tells people to update first, so will it still be a problem?
16:44:51 <sgallagh> lruzicka2: That is literally the question I am asking :)
16:44:56 <cmurf> if they ever had 4.7 on F30, it's possible they run into it
16:45:01 <sgallagh> cmurf: Exactly
16:45:16 <adamw> i actually would've expected the openqa updates test for the f30 update to run into this
16:45:16 <cmurf> so we needinfo + punt
16:45:19 <adamw> but it doesn't seem like it did
16:45:28 <adamw> so, yeah, i think this requires a bit more poking
16:45:29 <sgallagh> cmurf: +1
16:45:39 <frantisekz> punt +1
16:45:48 <lruzicka2> we can punt today and I will test fresh F30, update to newest updates and go to F31 and see
16:45:49 <coremodule> +1 punt
16:45:56 <lruzicka2> punt +1
16:45:58 <sgallagh> lruzicka2: Thanks
16:46:12 <adamw> proposed #agreed 1724380 - punt (delay decision) - there is definitely a significant bug here, but as things stand we aren't clear if it breaks the criteria for F31 due to the changes in F30. we will investigate this further and decide blocker status once we have more information
16:46:14 <lruzicka2> I will put the results into Bugzilla
16:46:22 <coremodule> ack
16:46:36 <frantisekz> ack
16:46:42 <sgallagh> ack
16:47:33 <adamw> #agreed 1724380 - punt (delay decision) - there is definitely a significant bug here, but as things stand we aren't clear if it breaks the criteria for F31 due to the changes in F30. we will investigate this further and decide blocker status once we have more information
16:47:46 <adamw> #topic (1727343) [abrt] PackageKit: libdnf::Repo::Impl::detachLibsolvRepo(): packagekitd killed by SIGSEGV
16:47:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1727343
16:47:46 <adamw> #info Proposed Blocker, libdnf, ASSIGNED
16:47:49 <adamw> this one has a sort of friend:
16:48:04 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1727424
16:48:31 <adamw> at least on current understanding, they have the same root cause, it's just a question of circumstance which particular crash you run into
16:48:47 <cmurf> is this transient?
16:48:50 <adamw> no
16:49:01 <cmurf> huh, why have I not hit it?
16:49:07 <adamw> are you sure you haven't?
16:49:10 <cmurf> i'm inclined to say +1 blocker
16:49:11 <adamw> is your packagekitd running?
16:49:14 <cmurf> i definitely have not
16:49:21 <adamw> and have you tried running gnome-software ?
16:49:32 <cmurf> i'm running into packagekitd hanging transiently on reboots on both F30 and F31
16:49:34 <cmurf> yes
16:49:53 <adamw> just starting packagekit and running gnome-software crashes packagekitd every time, for me.
16:50:01 <cmurf> huh ok
16:50:49 <kparal> gnome-software is then not usable, right?
16:51:04 <adamw> right, for me and openqa, anyway
16:51:10 <kparal> sounds like +1
16:51:12 <adamw> also cockpit software installation
16:51:24 <cmurf> testing...
16:51:46 <cmurf> so i login and gnome-software uses ~60% cpu and packagekitd uses 100% cpu, for about 30-40s
16:51:51 <cmurf> i have not launched them
16:51:56 <cmurf> just a login
16:52:03 <adamw> there's a gnome-software --application-service process which runs on login
16:52:13 <cmurf> flatpak is doing a thing now
16:52:17 <adamw> for testing i kill that, restart packagekit, then run gnome-software from a terminal
16:52:24 <adamw> packagekitd then dies
16:52:27 <cmurf> flatpak-system-helper and gnome-sfotware are busy
16:52:54 <cmurf> i've got a lot of messages here...
16:52:59 <cmurf> and it's just a login
16:53:54 <cmurf> ok after all that calms down, click on Gnome Software and it's up
16:53:56 <cmurf> no crashes
16:54:54 <cmurf> i wonder if there's some kind of race and it will crash if I launch gnome-software immediately on login
16:55:39 <adamw> no, it's not that.
16:55:45 <adamw> i can crash it any time i like.
16:55:48 <kparal> if it is consistent in openqa, I think that's good enough
16:55:56 <adamw> but it does involve threads, so it could be different on different systems, i guess.
16:57:16 <adamw> so yeah...i can believe it might not happen to everyone all the time, but i'd be surprised if it won't happen enough to be a blocker, so i'm +1 for now at least
16:57:34 <lruzicka2> I do not have any issues in VM, F31
16:57:35 <cmurf> tried again, no crash
16:57:57 <cmurf> but it takes 2 minutes for gnome-software to show anything but status info after being launched if I launch it right away
16:58:06 <lruzicka2> I am trying right now, it is slow, but I could install apps
16:58:34 <cmurf> i'm a weak +1 beta blocker, it really needs to work but I'd like to know more about versions and how to trigger it
16:58:42 <cmurf> i'm up to date as of a day or two ago
16:58:50 <lruzicka2> and I am only getting a very small number of applications to select
16:58:56 <cmurf> same here
16:59:18 <adamw> did you actually check system logs / ps output / systemctl status to see that packagekitd is still running?
16:59:24 <cmurf> yes
16:59:39 <adamw> note btw in f31 abrt doesn't handle c crashes any more so you don't get notifications on crashes usually...
16:59:47 <adamw> at least, seems that way to me.
17:00:03 <cmurf> i'm looking at ps aux, top, and journalctl -f
17:00:07 <adamw> oh, and you actually have libdnf 0.35.1 installed? and you've restarted packagekit since it got installed?
17:00:10 <cmurf> it's def running and hasn't crashed
17:00:12 <lruzicka2> Ssl in my case
17:00:34 <adamw> (or rebooted)
17:00:42 <cmurf> i have libdnf 0.35.1 and i've restarted at least three times since it was updated
17:01:01 <adamw> okay
17:01:02 <cmurf> s/restarted/rebooted
17:01:02 <adamw> interesting
17:01:06 <lruzicka2> I have libdnf 0.35.1 and I have restarted
17:01:19 <lruzicka2> packagekit reports Ssl in ps auc
17:01:21 <lruzicka2> aux
17:01:29 <cmurf> there's a bunch of stuff going on between all these pieces, could be a race
17:01:39 <adamw> it's not a race exactly
17:01:46 <cmurf> flatpak, repos, the rpm fusion stuff
17:01:51 <cmurf> which i did not add
17:01:56 <adamw> it's just threading within gnome-software/packagekit that can cause it, i think
17:02:01 <cmurf> *shrug*
17:02:02 <adamw> anyway
17:02:16 <adamw> so, i mean, we can punt and get lots of people to try and see how common it is, i guess
17:02:25 <lruzicka2> yeah, +1 punt
17:02:32 <cmurf> we have the votes to make it a blocker and also do a needinfo
17:02:46 <adamw> but i'd feel worried about releasing beta knowing it at least happens every time to me and openqa
17:02:48 <cmurf> as reported it's got sufficient brokenness for that and it has to work
17:02:52 <adamw> so i dunno.
17:03:03 <cmurf> needinfo + punt then
17:03:11 <sgallagh> I'm good with +1 blocker now as well
17:03:26 <frantisekz> I'd go for +1 blocker, if it happens in openqa regularly
17:03:31 <cmurf> exactly
17:03:35 <sgallagh> We can always revisit it if new information arrives, but I'd rather assume it's going to be blocking and get people alerted to it faster
17:03:48 <cmurf> just because I'm not having the problem just means it might be more complicated, not that it isn't a blocker
17:04:13 <adamw> ok
17:05:31 <lruzicka2> ok, let's block then
17:05:49 <cmurf> i just wish it crashed for me so i could use my coredumpctl gdb skills
17:06:21 <adamw> proposed #agreed 1727343 and 1727424 - AcceptedBlocker (Beta) - as we currently understand things, these two crashes have the same basic cause and break GNOME Software and Cockpit package installation when they occur. They do not seem to happen to everyone (timing is involved somehow) but on current information we think they're significant enough to violate "The installed system must be able appropriately to install, remove, and update software
17:06:21 <adamw> with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)"
17:06:31 <adamw> cmurf: you don't need to, we already basically know the cause
17:06:32 <adamw> grr, too long
17:06:57 <adamw> proposed #agreed 1727343 and 1727424 - AcceptedBlocker (Beta) - as we currently understand things, these two crashes have the same basic cause and break GNOME Software and Cockpit package installation when they occur. They do not seem to happen to everyone (timing is involved somehow) but on current information we think they're significant enough to violate "The installed system must be able appropriately to install software with the default
17:06:57 <adamw> tool for the relevant software type in all release-blocking desktops"
17:06:59 <adamw> grr
17:07:16 <adamw> proposed #agreed 1727343 and 1727424 - AcceptedBlocker (Beta) - as we currently understand things, these two crashes have the same basic cause and break GNOME Software and Cockpit package installation when they occur. They do not seem to happen 100% of the time but on current information we think they're significant enough to violate "The installed system must be able appropriately to install software with the default tool for the relevant
17:07:16 <adamw> software type in all release-blocking desktops"
17:07:22 <adamw> oh come on
17:07:25 <frantisekz> does it matter? coremodule will be able to parse that :)
17:07:37 * cmurf cackles
17:07:47 <adamw> if you don't fit it in one line the meetbot log is messed up
17:07:50 <coremodule> lol
17:07:52 <adamw> the second line doesn't go into the log
17:07:53 <lruzicka2> adamw, where in openqa does this fail? I cannot find it.
17:08:08 <adamw> lruzicka: desktop_update_graphical for Workstation live, and realmd_join_cockpit
17:08:13 <lruzicka2> adamw, in upgrade tests?
17:08:13 <adamw> https://openqa.fedoraproject.org/tests/421130#next_previous
17:08:33 <adamw> https://openqa.fedoraproject.org/tests/421098#next_previous
17:08:46 <adamw> see both tests failed every run since 0704.n.1
17:09:04 <adamw> proposed #agreed 1727343 and 1727424 - AcceptedBlocker (Beta) - AFAWCS, these two crashes have the same basic cause and break GNOME Software and Cockpit package installation when they occur. They do not seem to happen 100% of the time but on current information we think they're significant enough to violate "The installed system must be able appropriately to install software with the default tool for the relevant software type in all
17:09:04 <adamw> release-blocking desktops"
17:09:08 <adamw> ok i quit
17:09:10 <frantisekz> :D
17:09:14 <lruzicka2> adamw, yeah, it timed outed
17:09:25 <adamw> proposed #agreed 1727343 and 1727424 - AcceptedBlocker (Beta) - AFAWCS, these two crashes have the same basic cause and break GNOME Software and Cockpit package installation. They do not seem to happen 100% of the time but on current information we think they're significant enough to violate "The installed system must be able appropriately to install software with the default tool for the relevant software type in all release-blocking desktops"
17:09:27 <adamw> yay
17:09:29 <adamw> there we go
17:09:32 <frantisekz> wohooo
17:09:49 <adamw> lruzicka: if you look at the logs you'll find a crash from packagekitd in every one
17:10:05 <frantisekz> ack
17:10:10 <kparal> ack
17:10:10 <lruzicka2> adamw, I believe you, but first look looks like time-out
17:10:14 <cmurf> ack
17:10:16 <lruzicka2> ack
17:10:44 <adamw> lruzicka: yes, it times out because gnome software is waiting for packagekit and packagekit isn't doing anything because it crashed :)
17:10:49 <adamw> lruzicka: https://openqa.fedoraproject.org/tests/421130/file/desktop_update_graphical-coredump.tar.gz
17:11:39 <adamw> i guess arguably there's a gnome software bug there too - it should notice packagekit blew up and say 'uhhhh something is wrong here' rather than just spin forever
17:11:53 <lruzicka2> adamw, yeah, that is true
17:11:56 <adamw> #agreed 1727343 and 1727424 - AcceptedBlocker (Beta) - AFAWCS, these two crashes have the same basic cause and break GNOME Software and Cockpit package installation. They do not seem to happen 100% of the time but on current information we think they're significant enough to violate "The installed system must be able appropriately to install software with the default tool for the relevant software type in all release-blocking desktops"
17:15:49 <adamw> #topic (1657125) group remove: keep mandatory pkgs of other installed groups
17:15:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1657125
17:15:49 <adamw> #info Proposed Blocker, spin-kickstarts, ASSIGNED
17:15:56 <frantisekz> I don't think this deserves a blocker, it was broken for a really long time (bug report mentions fc21)
17:17:07 <lruzicka2> but it might deserve a fix
17:17:09 <cmurf> egads
17:17:18 <frantisekz> also, there seems to be no criterion we would base blocking this on
17:18:01 <cmurf> i'm -1 blocker
17:18:13 <frantisekz> -1
17:19:06 <cmurf> plus i don't think it should be a release criteria per se, there should be a policy for handling this first
17:19:26 <cmurf> and then maybe there'd be a criterion (maybe not)
17:19:28 <coremodule> I am also -1 blocker
17:21:13 <lruzicka2> -1 blocker but fix if possible
17:22:08 <kparal> I don't think this is Beta blocker, not completely sure about Final, but I lean towards -1. It doesn't prevent the distribution to function well, just the remove operation more risky than it should be (if you don't pay attention or you don't know exactly what you're doing). That's unfortunate, but probably not release blocking
17:22:26 <adamw> ok, sounds like enough -1 votes
17:23:29 <adamw> proposed #agreed 1657125 - RejectedBlocker (Beta) - this is established behaviour and we don't believe it violates any of the criteria as it stands.
17:23:37 <frantisekz> ack
17:23:43 <cmurf> ack
17:24:09 <lruzicka2> ack
17:24:14 <coremodule> ack
17:25:49 <kparal> ack
17:26:24 <adamw> #agreed 1657125 - RejectedBlocker (Beta) - this is established behaviour and we don't believe it violates any of the criteria as it stands.
17:26:32 <adamw> #topic (1715699) LiveOS boot, journalctl is missing many early messages
17:26:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1715699
17:26:32 <adamw> #info Proposed Blocker, systemd, NEW
17:27:01 <cmurf> summary in comment 12
17:27:17 <cmurf> skip all the stream of consciousness murphy debugging comments
17:28:42 <coremodule> hmmm
17:29:15 <lruzicka2> early logs is a nice to have thing
17:29:40 <cmurf> option, needinfo the systemd maintainer and punt
17:29:48 <kparal> cmurf: this is happening also on installed systems or just live images?
17:29:53 <adamw> i mean, for debugging you can just set the journal target to console or a serial terminal, no?
17:29:55 <cmurf> only LiveOS
17:30:29 <cmurf> there's a bunch of stuff that only ever goes into the journal, i've tried a bunch of different ways to get this info and haven't succeeded
17:31:07 <adamw> i mean systemd.journald.forward_to_console=1
17:31:10 <adamw> tried that>?
17:31:13 <cmurf> maybe if the kernel log buffer is set to something crazy like 16x bigger than default, it's possible to forward the journal into kernel messages, and get everything by dmesg
17:31:16 <cmurf> i did
17:31:28 <adamw> mm
17:31:50 <adamw> i'm kinda inclined to -1 on this tbh
17:31:54 <cmurf> but i should retest that with a much bigger kernel buffer
17:32:25 <cmurf> it's so incredibly verbose that the 256K buffer we have almost immediately drops messages
17:32:55 <adamw> especially if this is not new in f31 i don't see any point in blocking on it
17:33:08 <cmurf> it is new in f30
17:34:12 <cmurf> had i known about it then i'd have proposed it then
17:35:42 <lruzicka2> cmurf, how do you think this could be fixed?
17:36:13 <adamw> do we know what changed? is the change that /var/log/messages didn't exist before, or systemd didn't use it before, or it was bigger, or whaty?
17:39:31 <adamw> bueller? bueller!?
17:41:38 <adamw> okay. well. as things stand, i'm still -1
17:41:40 <adamw> any other formal votes?
17:41:50 <frantisekz> -1 for beta
17:41:54 <kparal> probably -1 atm
17:41:58 <coremodule> -1 from me
17:42:13 <lruzicka2> I dont know
17:42:33 <cmurf> i'm not sure
17:43:12 <adamw> proposed #agreed 1715699 - RejectedBlocker (Beta) - as this bug is currently understood we do not believe it breaks the release criteria, it's just an unfortunate issue. The system logging function is present and does broadly work. This can be re-considered if further information or a different justification arises
17:43:28 <coremodule> ack
17:43:29 <lruzicka2> ack
17:43:39 <kparal> ack
17:44:09 <frantisekz> ack
17:44:17 <adamw> #agreed 1715699 - RejectedBlocker (Beta) - as this bug is currently understood we do not believe it breaks the release criteria, it's just an unfortunate issue. The system logging function is present and does broadly work. This can be re-considered if further information or a different justification arises
17:44:30 <cmurf> a big part of being unable to get information on that bug is because of the bug
17:45:00 <cmurf> i can't look at assembly as being a cause
17:45:15 <cmurf> none of the assembly is available, it's all purged
17:45:35 <adamw> then you need to find a way to get at the messages. this shouldn't be impossible...but it still doesn't make the bug a blocker
17:45:48 <adamw> patch systemd to put the logs somewhere else and recompile
17:45:55 <adamw> patch it to dump out the info you need some other way
17:45:57 <adamw> there's lots of options
17:47:07 <adamw> #topic proposed Final blockers
17:47:15 <adamw> #info let's skip proposed Beta FE as we're still 6 weeks out from freeze date
17:47:34 <adamw> first one is fixed already, i'll close it
17:47:45 <adamw> #topic (1713485) ext3 partitions get remounted as read-only due to journal error ("journal block not found"..."Detected aborted journal")
17:47:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1713485
17:47:45 <adamw> #info Proposed Blocker, kernel, NEW
17:47:57 <adamw> hmm i think this might be fixed too...let me see...
17:49:24 <adamw> yeah, test's passed every compose since 0524.n.1
17:49:31 <adamw> #info this appears to have been fixed in May, we will close it
17:50:58 <adamw> #topic Open floor
17:51:27 <adamw> so, any other business, folks?
17:52:32 <frantisekz> I guess not, thanks adamw for leading this
17:53:08 <coremodule> thanks for hosting the meeting adamw
17:53:55 <adamw> alrighty folks
17:53:58 <adamw> thanks for coming out
17:54:22 <lruzicka2> thank you, have a nice time
17:54:44 <kparal> thanks, cheers
17:55:08 <adamw> #endmeeting