16:00:01 <adamw> #startmeeting F25-blocker-review
16:00:01 <zodbot> Meeting started Mon Aug 29 16:00:01 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:01 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:01 <adamw> #meetingname F25-blocker-review
16:00:02 <adamw> #topic Roll Call
16:00:02 <zodbot> The meeting name has been set to 'f25-blocker-review'
16:00:07 <adamw> dang it, one second out!
16:00:09 * kparal is here this time
16:00:18 * pschindl is here
16:00:21 * pwhalen is here
16:01:00 <sgallagh> .hello sgallagh
16:01:01 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:22 <adamw> morning folks
16:01:24 <adamw> anyone else?
16:01:31 <mboddu> .hello mohanboddu
16:01:32 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
16:01:34 <dgilmore> hola
16:01:47 <coremodule> Good morning adamw.
16:01:53 * coremodule is here.
16:02:05 <adamw> whew, finally, some smart people showed up
16:02:06 <adamw> i mean uh
16:02:13 <adamw> :P
16:02:18 <adamw> #chair dgilmore coremodule
16:02:18 <zodbot> Current chairs: adamw coremodule dgilmore
16:02:28 <adamw> #topic Introduction
16:02:28 <adamw> Why are we here?
16:02:28 <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:02:28 <adamw> #info We'll be following the process outlined at:
16:02:30 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:02:30 <adamw> #info The bugs up for review today are available at:
16:02:32 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:02:34 <adamw> #info The criteria for release blocking bugs can be found at:
16:02:38 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria
16:02:40 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria
16:02:42 <adamw> #link https://fedoraproject.org/wiki/Fedora_25_Final_Release_Criteria
16:02:50 <adamw> so we have:
16:02:51 <adamw> #info 4 Proposed Blockers
16:03:01 <adamw> #info 0 Everything Else (for Beta)
16:03:10 <adamw> we also have:
16:03:17 <adamw> #info 5 Proposed Blockers (for Final)
16:03:38 <adamw> who wants to secretarialize?
16:03:46 <coremodule> I'll do it!
16:04:15 <kparal> coremodule to the rescue!
16:04:19 <adamw> #info coremodule will secretarialize
16:04:20 <adamw> thanks
16:04:22 <kparal> coremodule++
16:04:23 <zodbot> kparal: Karma for coremodule changed to 1 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:04:40 <adamw> alrighty, so let's go right in with the beta proposed blockers
16:04:40 <adamw> #topic (1369786) Autopart fails on installation from live usb created by l-i-t-d
16:04:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1369786
16:04:41 <adamw> #info Proposed Blocker, anaconda, NEW
16:04:55 <adamw> seems pretty +1ish, litd is still a supported method
16:05:18 <kparal> +1
16:05:30 <pschindl> +1
16:05:57 <pwhalen> +1
16:06:04 <kparal> bcl maintains it, right? does he know he doesn't need to fix it if we make this method unsupported? hint hint :)
16:06:05 <sgallagh> +1
16:06:39 * kparal would love reduction in the number of supported usb writing methods
16:06:54 <pschindl> also +1
16:07:31 <adamw> proposed #agreed 1369786 - AcceptedBlocker (Beta) - clear violation of "All release-blocking images must boot in their supported configurations. This criterion differs from the similar Alpha criterion only in that it requires all supported methods of writing a Fedora USB stick to work, not just any single one" and "The installer must be able to complete an installation to a single disk using automatic partitioning."
16:07:39 <dgilmore> ack
16:07:48 <coremodule> ack
16:07:48 <adamw> kparal: i think the bug is actually more likely in anaconda than litd...well, we'll see i guess
16:07:49 <pwhalen> ack
16:07:54 <mboddu> ack
16:07:59 <adamw> #agreed 1369786 - AcceptedBlocker (Beta) - clear violation of "All release-blocking images must boot in their supported configurations. This criterion differs from the similar Alpha criterion only in that it requires all supported methods of writing a Fedora USB stick to work, not just any single one" and "The installer must be able to complete an installation to a single disk using automatic partitioning."
16:08:09 <dgilmore> though do we want to continue supporting a tool not supported by its upstream
16:08:21 <adamw> dgilmore: who said it wasn't?
16:09:59 <adamw> *shrug*
16:10:00 <adamw> #topic (1366793) Nothing obsoletes retired dnf-langpacks packages, breaks upgrade from Fedora 23 to 25+
16:10:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366793
16:10:00 <adamw> #info Proposed Blocker, dnf, ASSIGNED
16:10:12 <adamw> so, we've been punting on this for a while waiting on guidance from above
16:10:18 <adamw> the ticket i filed for FPC has been kicked up to fesco
16:10:28 <dgilmore> adamw: it comes from livecd-tools right?
16:10:48 <adamw> dgilmore: sure. bcl never said livecd-tools as a whole was unsupported, only livecd-creator .
16:11:00 <dgilmore> +1 to 1366793
16:11:03 <sgallagh> adamw: FESCo doesn't have a good answer for the general question, but the specific case of dnf-langpacks we recommended should just get Obsoleted by DNF
16:11:11 <sgallagh> Also, +1 blocker
16:11:38 <adamw> sgallagh: what's the fesco ticket # ?
16:11:56 <adamw> got it
16:11:56 <sgallagh> .fesco 1620
16:11:59 <zodbot> sgallagh: #1620 (Decide what to do when package is retired and nothing replaces it directly) – FESCo - https://fedorahosted.org/fesco/ticket/1620
16:12:02 <adamw> #info the FPC ticket we filed on this - https://fedorahosted.org/fpc/ticket/645 - has been kicked to FESCo - https://fedorahosted.org/fesco/ticket/1620
16:12:58 <adamw> so i really would like a policy here, but in the absence of one, and given the criteria, i'm probably +1 .
16:13:06 <kparal> +1
16:13:49 <adamw> proposed #agreed 1366793 - AcceptedBlocker (Beta) - the lack of a clear policy here makes the decision somewhat difficult, but in the absence of a policy we hold this to be a violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed."
16:14:26 <kparal> ack
16:14:27 <pschindl> ack
16:14:31 <mboddu> ack
16:14:37 <coremodule> ack
16:14:57 <sgallagh> ack
16:15:24 <dgilmore> ack
16:15:36 <adamw> #agreed 1366793 - AcceptedBlocker (Beta) - the lack of a clear policy here makes the decision somewhat difficult, but in the absence of a policy we hold this to be a violation of "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed."
16:15:58 <adamw> #topic (1369492) mouse cursor coordinates are incorrect in VM under wayland, makes cursor unusable
16:15:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1369492
16:15:59 <adamw> #info Proposed Blocker, mutter, NEW
16:16:03 <adamw> good news, this one is getting fixed
16:16:16 <adamw> i'm definitely +1, it makes workstation basically unusable in a VM.
16:16:24 <dgilmore> +1 also
16:16:35 <pwhalen> +1
16:16:43 <mboddu> +1
16:16:59 <sgallagh> +1
16:17:08 <pschindl> +1
16:17:23 <kparal> +1
16:17:42 <coremodule> +1
16:18:56 <adamw> proposed #agreed 1369492 - AcceptedBlocker (Beta) - clearly violates "The release must be able host virtual guest instances of the same release." combined with multiple desktop criteria
16:19:02 <dgilmore> ack
16:19:09 <kparal> ack
16:19:17 <pwhalen> ack
16:19:30 <adamw> #agreed 1369492 - AcceptedBlocker (Beta) - clearly violates "The release must be able host virtual guest instances of the same release." combined with multiple desktop criteria
16:19:38 <adamw> #topic (1026119) fails to unmount encrypted filesystem (/dev/mapper/luks-partition) containing /var/log on every shutdown
16:19:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1026119
16:19:38 <adamw> #info Proposed Blocker, systemd, NEW
16:19:47 <adamw> i had a quick look into this one this morning, so far as I can tell, i'm -1
16:20:01 <sgallagh> I agree, this is a real edge case. -1
16:20:14 <adamw> point: it's been around two years and no-one's dead. point: it seemingly only affects you if you have /var as a separate partition *and* it's encrypted. point: according to lennart, it's cosmetic.
16:20:51 <sgallagh> Yeah, it's that last one that sold me. If it was actually losing data on unmount or something, I might hesitate.
16:20:54 <sgallagh> But it doesn't seem to be
16:21:11 <cmurf> but is the fs dirty as a result?
16:21:18 <cmurf> no data loss just means nothing was writing at the time
16:21:30 <dgilmore> -1
16:21:36 <kparal> adamw: where does lennart claim what you wrote?
16:21:42 <adamw> in the github ticket
16:21:46 <kparal> ok
16:22:14 <cmurf> i wouldn't call unclean umount cosmetic, I'd call it sloppy, but it's probably not a blocker
16:22:17 <adamw> https://github.com/systemd/systemd/issues/867#issuecomment-148349919
16:22:33 <adamw> cmurf: "all you see is the EBUSY error messages during shutdown, but the file system will be unmounted during the final killing spree, so all should be good"
16:22:52 <cmurf> that's good news, so it's just noise
16:23:25 <cmurf> i wonder why this happens with encrypted var and not home/
16:23:25 <adamw> is anyone +1 ?
16:23:28 <cmurf> ?
16:23:29 <kparal> it's not ideal to unmount uncleanly, but based on lennart's assessment, seems -1 blocker to me
16:23:33 <adamw> cmurf: because journal does not write to /home .
16:23:35 <coremodule> Negative, -1 blocker here.
16:23:44 <sgallagh> kparal: I don't think it's actually unmounting uncleanly, from lennart's comment
16:23:47 <cmurf> oh so journald is holding it up
16:23:56 <adamw> although it seems it used to affect /home too...the behaviour does seem to have changed a bit over time, reading between the lines some
16:23:58 <sgallagh> I think it's basically being held open until journald exits, at which time it unmounts
16:24:19 <cmurf> if it affects /home i'll get more paranoid
16:24:50 <cmurf> but workstation WG wants to get to LUKS for everything by default one of these days
16:24:59 <adamw> proposed #agreed 1026119 - RejectedBlocker (Beta) - based on all available information this affects only a corner case (encrypted separate /var partition) and even when encountered appears not to have serious consequences
16:25:17 <sgallagh> ack
16:25:43 <kparal> ack
16:25:51 <coremodule> ack
16:26:17 <adamw> #agreed 1026119 - RejectedBlocker (Beta) - based on all available information this affects only a corner case (encrypted separate /var partition) and even when encountered appears not to have serious consequences
16:26:39 <cmurf> bit weird that it matters when dm is involved...
16:26:49 <cmurf> s/matters/happens
16:26:52 <adamw> #info moving on to proposed Final blockers
16:26:58 <adamw> #topic (1370118) Some fonts are missing on the netinst and dvd
16:26:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370118
16:26:58 <adamw> #info Proposed Blocker, anaconda, NEW
16:27:34 <cmurf> if they're required for properly rendering the installer, +1
16:27:41 <adamw> +1 if they're 'sufficiently complete'
16:27:49 <adamw> oh yeah they are, or else they wouldn't be shown. +1
16:28:11 <kparal> +1
16:28:12 <coremodule> +1 here.
16:28:16 <mboddu> +1
16:28:29 <pwhalen> +1
16:28:35 <sgallagh> +1, assuming unblocking means either fixing the display or removing the offending languages
16:29:14 <adamw> proposed #agreed 1370118 - AcceptedBlocker (Final) - clear violation of "The installer must correctly display all sufficiently complete translations available for use."
16:29:29 <sgallagh> ack
16:29:33 <coremodule> ack
16:30:06 <pwhalen> ack
16:30:23 <mboddu> ack
16:30:44 <adamw> #agreed 1370118 - AcceptedBlocker (Final) - clear violation of "The installer must correctly display all sufficiently complete translations available for use."
16:30:52 <adamw> #topic (1370889) libgweather "Failed to get METAR data: 404 Not Found"
16:30:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370889
16:30:52 <adamw> #info Proposed Blocker, libgweather, MODIFIED
16:31:16 <adamw> seems reasonable, +1
16:31:56 <sgallagh> Is gnome-weather installed by default?
16:32:04 * kparal boots f25 vm to check it
16:32:28 <sgallagh> /me can verify that it's not working right now on his system
16:32:39 <adamw> yeah, i'm pretty sure it is
16:33:03 <adamw> yeah, it's in @gnome-desktop .
16:33:06 <sgallagh> Yeah, confirmed.
16:33:08 <sgallagh> OK, +1
16:33:19 <kparal> it is, and it does not show forecast
16:33:21 <kparal> +1
16:33:32 <handsome_pirate> +1
16:33:33 <pwhalen> +1
16:34:25 <adamw> proposed #agreed 1370889 - AcceptedBlocker (Final) - this violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" in the case of gnome-weather (this is considered 'basic functionality' of gnome-weather)
16:34:32 <handsome_pirate> ack
16:35:00 <cmurf> ack
16:35:04 <kparal> ack
16:35:11 <adamw> #agreed 1370889 - AcceptedBlocker (Final) - this violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" in the case of gnome-weather (this is considered 'basic functionality' of gnome-weather)
16:35:20 <adamw> #topic (1366004) [abrt] setroubleshoot-server: service.py:647:_message_cb:SystemError: <built-in function isinstance> returned a result with an error set
16:35:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1366004
16:35:20 <adamw> #info Proposed Blocker, setroubleshoot, NEW
16:35:56 <adamw> so this appears at boot time, or what?
16:36:33 <handsome_pirate> huh, I can get ssh over my cell connection, but not http :(
16:36:36 <cmurf> my recollection is I hit it after login, maybe well afer login when it tries to capture something else
16:36:39 <cmurf> and then crashes
16:37:17 <adamw> hmm
16:37:21 <kparal> which would also violate default app functionality
16:37:41 <handsome_pirate> Yeah, I'm feeling +1 on this (page finally loaded
16:37:42 <handsome_pirate> )
16:37:51 <kparal> but it didn't crash for me when I reported selinux bugs
16:37:55 <sgallagh> cmurf: Does ABRT crash handling *any* crash?
16:38:06 <cmurf> no, it doesn't always happen
16:38:18 <cmurf> and it's not user reproducible but I've seen it more than once
16:38:53 <cmurf> launch the troubleshooter and it just doesn't launch, get a notification of a crash, try to launch it again and it launches
16:38:54 <adamw> sgallagh: it's setroubleshoot that's crashing, not abrt.
16:39:05 <sgallagh> adamw: Ah, my mistake
16:39:44 <handsome_pirate> still, seems a blocker to me
16:40:07 <cmurf> so there were a bunch of these selinux problems it was capturing and may have still been collecting data at the time I launched the troubleshooter from the notification "sheet" or whatever it's called
16:40:09 <sgallagh> We don't block on every crash, least of all unreproducible ones
16:40:26 <sgallagh> It's a bug and unpleasant, but I'm -1 blocker on it unless more compelling arguments are made.
16:40:32 <cmurf> and it just didn't launch, followed by a different notification for a crash
16:41:37 <adamw> yeah, if it doesn't crash reproducibly and you can get into it by trying a couple of times, i'm probably -1
16:41:52 <sgallagh> Ah, hmm. I just looked at ABRT and see that I've hit this bug too.
16:42:09 <sgallagh> I must have missed the shell notification
16:42:48 <handsome_pirate> Maybe punt until we can figure out how to cleanly reproduce?
16:43:17 <adamw> if you have to explicitly do something to reproduce it, it's not a violation of the criterion cited, by definition.
16:43:29 <adamw> since that criterion says it has to just appear right after boot of the live image or installed systme.
16:44:01 <adamw> but i guess you could argue for the 'basic functionality' criterion.
16:44:03 <cmurf> i'm pretty certain I had to launch the troubleshooter to hit this
16:44:22 <cmurf> i.e. go to the notification for the selinux error, and launch the troubleshooter via the notification
16:44:59 <sgallagh> In my case, it looks like the denial I hit was SELinux trying to access a file *it created* with the wrong SELinux context...
16:45:11 <sgallagh> Which if that's consistent, probably *would* actually happen on every boot.
16:45:22 <cmurf> thing is if there are no selinux denials, no one will hit this ;-)
16:45:25 <sgallagh> Shall I reboot and see if it crashes on me again?
16:45:59 <sgallagh> Of course, it still requires starting the troubleshooter, so *shrug*
16:46:06 <cmurf> huh this is setroubleshoot-server which I think it the daemon, not the user space app?
16:46:11 <cmurf> s/it/is
16:46:17 <sgallagh> Yeah, it's the daemon
16:46:21 <cmurf> soooo
16:46:24 <cmurf> maybe
16:46:41 <cmurf> when the user space app is launched, communicating with the daemon is the problem, hence dbus being implicated in the traceback?
16:47:04 <sgallagh> cmurf: Let's take this elsewhere.
16:47:06 <adamw> we're not trying to fix the bug, just decide whether it's a blocker.
16:47:11 <sgallagh> We don't have to fix the bug in this meeting :)
16:47:16 <sgallagh> I'm still -1 blocker at this time
16:47:16 <adamw> i think i'm still -1 at this point, i can go with punt also.
16:47:18 <cmurf> it seems non-deterministic because i know the user space app does work most of the time
16:47:20 <cmurf> i've used it
16:47:35 <cmurf> it definitely doesn't always crash or i would have nominated as a blocker myself
16:47:49 <cmurf> so i'm -1 or punt for now
16:49:14 <adamw> proposed #agreed 1366004 - RejectedBlocker (Final) - so far this doesn't seem to be a crash on boot (thus does not violate cited criterion) and also doesn't seem reliably reproducible on regular use of the sealert app (thus doesn't violate 'basic functionality' criterion for pre-installed apps). can be reproposed if more details emerge
16:49:46 <kparal> ack
16:50:07 <sgallagh> ack
16:50:55 <coremodule> ack
16:51:07 <adamw> #agreed 1366004 - RejectedBlocker (Final) - so far this doesn't seem to be a crash on boot (thus does not violate cited criterion) and also doesn't seem reliably reproducible on regular use of the sealert app (thus doesn't violate 'basic functionality' criterion for pre-installed apps). can be reproposed if more details emerge
16:51:13 <kparal> adamw: I just proposed 1225184 for Beta
16:51:13 <adamw> #topic (1295031) cannot preview files under wayland/XWayland
16:51:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1295031
16:51:13 <adamw> #info Proposed Blocker, sushi, NEW
16:51:19 <adamw> kparal: ok, we'll circle back later
16:51:57 <adamw> what the hell is this 'sushi' thing?
16:52:04 <cmurf> i'm -1 on this, but more specifically i'm +1 punting it to the WG to decide what they want to do about it
16:52:12 <kparal> adamw: ever tried pressing space in nautilus with some file selected?
16:52:12 <adamw> oh, nautilus uses it
16:52:15 <kparal> quick preview
16:52:20 <adamw> well that information would have been useful in comment #0
16:52:24 <cmurf> haha
16:52:33 <kparal> it does not have its own app icon, but it's a "default app"
16:52:35 <adamw> meh, i'm probably -1 on the selfish basis that i have never done that ever :P
16:52:39 <kparal> or some people might consider it part of nautilus
16:52:45 <kparal> I'm more +1
16:52:47 <adamw> thus doesn't really feel like 'basic functionality' of nautilus to me.
16:52:58 <adamw> but, i can see it either way
16:52:59 <cmurf> they can use X
16:53:29 <cmurf> i'm sure the sushi people will want it to work on wayland, eventually
16:53:33 <kparal> I use it to count directory size quickly
16:53:33 <sgallagh> Is it related to the preview view of images just in the nautilus display, or only the spacebar version?
16:53:56 <kparal> sgallagh: AFAIK you can only invoke it from nautilus
16:54:02 <kparal> or terminal, possibly
16:54:07 <sgallagh> OK, regular previews seem to work okay.
16:54:16 <sgallagh> /me is running F25 Wayland GNOME right now
16:54:16 <kparal> yes, it's not the thumnailer
16:54:30 <kparal> it's a separate window for previewing file
16:54:38 <sgallagh> I'm inclined to say this doesn't hit the "basic functionality of a default app" criteria really.
16:54:47 <sgallagh> I
16:55:00 <sgallagh> 'd be surprised to learn if many people even know about it
16:55:16 <sgallagh> It's only "discoverable" if you happen to come from OSX and know that happens over there...
16:55:34 <cmurf> i never use it on macos
16:55:53 * kparal does not have a strong opinion either way
16:56:08 <coremodule> I didn't know it existed until two minutes ago...
16:56:27 <kparal> yeah, that's why I'm re-evaluating my view
16:56:34 <kparal> I thought people know about it in general
16:57:15 <coremodule> What about an FE?
16:57:24 <cmurf> we're not in freeze
16:57:29 <sgallagh> proposed #agreed 1295031 - RejectedBlocker (Final) This is niche functionality that doesn't quite pass the bar of "basic funcionality" for default-installed applications.
16:57:36 <coremodule> cmurf, right, duh.
16:57:39 <cmurf> they can fix it whenever, and have two opportunities to get it fixed
16:57:58 <kparal> ack
16:58:01 <cmurf> ack
16:58:08 <coremodule> ack
16:58:22 <dgilmore> ack
16:58:43 <sgallagh> (please fix my typo of "functionality" when doing the #agreed)
16:59:35 <sgallagh> Did we lose adamw?
16:59:59 <adamw> no.
17:00:03 <adamw> i was just checking something.
17:00:17 <adamw> jeez, you people are impatient. :P
17:00:32 <adamw> #agreed 1295031 - RejectedBlocker (Final) This is niche functionality that doesn't quite pass the bar of "basic funcionality" for default-installed applications.
17:00:39 <adamw> oh. missed a dash. oh well.
17:00:56 <adamw> #topic (1370136) glibc update corrupts display of a running system
17:00:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1370136
17:00:56 <adamw> #info Proposed Blocker, systemd, POST
17:01:45 <adamw> meh, for Final i find it kinda hard to vote on this one
17:01:51 * adamw would like to just wait for it to go away
17:02:06 <cmurf> me2
17:02:12 <kparal> our last excude was "it's an alpha" :)
17:02:15 <kparal> *excuse
17:02:25 <cmurf> sure so that'll work for beta
17:02:46 <kparal> so why are you undecided?
17:02:52 <kparal> it seems clear +1 for me
17:03:02 <kparal> updates break on many computers, horribly
17:03:17 <cmurf> i think our updating is busted anyway, this is just one more side effect
17:03:20 <kparal> it's enough to have a package that triggers daemon-reexec
17:03:30 <adamw> well, no they don't. the computer behaves a bit weird when you run an update. but the update works. and the computer's fine after a reboot.
17:03:38 <adamw> it just doesn't feel like an awful consequence. but meh
17:03:55 <kparal> all 2 amd cards we tried resulted in an unreadable display
17:03:56 <adamw> if people say +1, i don't mind
17:04:05 <cmurf> i'm -1
17:04:22 <kparal> all KDEs got switched to a VT
17:04:26 <kparal> even on intel
17:04:38 <kparal> and on VMs you see a VT cursor printing all over your session
17:04:52 <kparal> is the "switch to VT and back" excuse good enough for Final?
17:05:06 <kparal> please remember that it doesn't work on AMD
17:05:11 <kparal> at least it didn't for us
17:05:20 <adamw> well, my 'excuse' would be 'just reboot the damn thing'.
17:05:26 <cmurf> exactly
17:05:30 <kparal> and when?
17:05:31 <cmurf> which is what we're supposed to do anyway
17:05:35 <kparal> how long do you wait?
17:05:42 <adamw> till the hard disk light stops blinking...
17:05:42 <kparal> and how do you reboot it safely?
17:05:56 <dgilmore> adamw: to reboot you have to switch to a vt anbd back
17:05:57 <kparal> adamw: hard disk lights do not exist anymore
17:06:02 <kparal> modern times!
17:06:02 <cmurf> it's a good point, doesn't 'dnf update && reboot' work?
17:06:18 <kparal> cmurf: is that a solution we recommend for people using our stable release?
17:06:19 <adamw> cmurf: well, only if you know to do that before you start the update.
17:06:32 <kparal> come one, this is clear +1
17:06:34 <kparal> *on
17:06:37 <adamw> kparal: every system i've got here has one...
17:06:43 <cmurf> whose bug is this?
17:06:51 <kparal> adamw: I'm looking at T450s and it doesn't
17:06:54 <cmurf> what actually changed and what do they have to say about it?
17:06:57 <adamw> we already have a fix for it. that's why it's in POST.
17:06:57 <cmurf> is it fixable?
17:07:13 <kparal> adamw: also, my desktop doesn't have one
17:07:21 <kparal> so I'm current at 0/2
17:07:23 <cmurf> is someone taking ownership of this negative side effect and saying "oops sorry we'll fix it?"
17:07:48 <kparal> yes, systemd patch is posted
17:08:00 <kparal> read comment 19
17:08:35 <cmurf> aha
17:08:50 <cmurf> ok i change my vote +1
17:09:59 * adamw waits for...anyone else
17:10:06 <kparal> anyone else has an opinion?
17:10:57 <sgallagh> I'm still kind of -1. Our official update mechanism should basically avoid this problem because it results in a reboot.
17:11:06 <adamw> sgallagh: that's only workstation
17:11:13 <adamw> kde is also a release blocking package set and has no offline update mechanism
17:11:14 <sgallagh> What do you mean?
17:11:14 <kparal> sgallagh: KDE
17:11:37 <kparal> also, dnf update is still officially supported, isn't it?
17:11:51 <kparal> if it isn't, we should announce it very visibly
17:11:51 <sgallagh> Let me reread the bug. I thought this was only an issue on the major version jump
17:11:55 <cmurf> yeah i mean basically I agree with the idea that dnf updates in-tree are a really bad idea but there's no current solution for that
17:12:21 <sgallagh> Oh this is *every* update of glibc?
17:12:24 <sgallagh> I misread.
17:12:42 <kparal> sgallagh: as long as they execute systemctl daemon-reexec in %post
17:12:50 <kparal> and as long as systemd is not fixed
17:12:50 <sgallagh> That said, I'm still -1, since updating glibc and *not* rebooting is just deeply foolish.
17:12:53 <cmurf> yeah it's not glibc itself, it's the daemon-reexec that happens after glibc gets updated
17:13:10 <cmurf> sgallagh: sure but if you can see anything...
17:13:17 <cmurf> /s/can/can't
17:13:20 <kparal> sgallagh: people are not able to reboot, because it corrupts their screen or throws them into a VT, during the transaction
17:13:41 <kparal> for a moment, think about people who don't know how to switch VTs, even what a VT is
17:14:13 <sgallagh> /me also notes that this is a great example of a counter-argument to the "I've been doing yum update on live systems for years, why do we need offline updates?" cargo-culting...
17:14:21 <cmurf> of course
17:14:27 <cmurf> that was my argument
17:14:40 <kparal> I agree offline upgrades are safer
17:14:45 <kparal> but that's not the point here
17:14:56 <cmurf> but seeing as we don't have rpm-ostree deployed, KDE doesn't do offline updates, and dnf does not have a reboot option by default (which it arguably should)
17:14:57 <sgallagh> Anyway, I think it's an unpleasant bug, but I'm not sure what *specific* criterion it violates.
17:15:04 <kparal> unless we stop supporting live update with dnf, we should block on these things
17:15:29 <kparal> sgallagh: comment 9
17:15:37 <kparal> oh, that's Alpha
17:15:49 <kparal> for Beta onwards, we also have graphical updaters in criteria
17:16:05 <kparal> for GNOME, that's not an issue, for KDE it is
17:16:15 <cmurf> what about server?
17:16:27 <kparal> I proposed it for Final, because it's a conditional case
17:16:29 <cmurf> would it affect vnc
17:16:41 <kparal> cmurf: good question, I don't know
17:16:44 <kparal> can try it
17:16:51 <sgallagh> cmurf: How many servers have AMD GPUs?
17:17:23 <cmurf> well for this bug that matters maybe, but in general, what if this affected intel gpus?
17:17:32 <sgallagh> cmurf: FWIW, I am working in my spare time on offline updates via Cockpit for the Server case.
17:17:40 <sgallagh> But that's obviously not available today
17:18:00 <kparal> sgallagh: please note we have tested a very limited range of cards. it might behave completely differently on different series of gpus
17:18:07 <sgallagh> /me nods
17:18:33 <sgallagh> kparal: My thought is basically: if this was the last thing preventing Final from going out the door, would we slip over it?
17:18:40 <sgallagh> My instinct says "no"
17:19:24 <kparal> I'd vote yes
17:19:27 <cmurf> there is no actual consequence to this vote other than precedent (haha) because there is admission of the problem and there's a fix, and it's going to get pushed before beta freeze anyway
17:19:28 <cmurf> right?
17:19:38 <kparal> but it seems we'll not reach agreement today
17:19:52 <kparal> so probably punt and wait until it resolves itself
17:20:08 <kparal> or is very close to Final go/no-go, more fun then
17:20:19 <adamw> cmurf: well, it's not a slam dunk since the fix is only upstream atm, it kinda depends when there's a new systemd release and stuff
17:20:41 <adamw> kparal makes some good points and i'm a lot closer to a +1
17:21:23 <adamw> but for now we seem kinda split
17:21:24 <cmurf> i think it's problematic to ship KDE where any/all AMD systems appear to face plant on a glibc update
17:21:45 <sgallagh> I would argue to get the release out the door if this was all that was left (and fix it in an update). So I'm going to stick with my -1
17:21:46 <adamw> proposed #agreed 1370136 - punt (delay decision) - we don't have a clear vote on this at present and it's likely to be resolved long before Final in any case, so we're delaying it for now
17:22:00 <cmurf> and at a  point in time where it's plausible the user thinks they have to do a reset, where the update isn't actually finished yet and then get themselves into an even worse situation
17:22:06 <sgallagh> cmurf: As time marches on, it gets more problematic to ship KDE for many reasons.
17:22:15 <cmurf> sure
17:22:17 <cmurf> but in the meantime...
17:22:20 <kparal> ack
17:22:22 <cmurf> ack
17:22:28 <sgallagh> (This is not disparaging to KDE, just that it's hard to keep it up to date with our primary deliverables)
17:22:59 <adamw> sgallagh: if you want to take that tack, the appropriate thing to do is get KDE's status downgraded. it's not appropriate to pretend we still consider KDE a blocking desktop but actually refuse to block on bugs that affect it.
17:23:08 <cmurf> yep
17:25:08 <adamw> only got two acks
17:25:36 <adamw> sgallagh: ack, nack, patch, fold or stick?
17:25:38 <kparal> your ack counts as well ;)
17:26:01 <sgallagh> ack
17:26:58 <adamw> #agreed 1370136 - punt (delay decision) - we don't have a clear vote on this at present and it's likely to be resolved long before Final in any case, so we're delaying it for now
17:27:28 <adamw> #info going back to a newly-proposed Beta blocker
17:27:31 <adamw> #topic (1225184) anaconda does not detect RAID devices
17:27:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1225184
17:27:32 <adamw> #info Proposed Blocker, python-blivet, ASSIGNED
17:27:44 <kparal> you might want to read a summary here: https://fedoraproject.org/wiki/Common_F25_bugs#mdraid-unknown
17:27:55 <kparal> and then at least my last comment
17:28:04 <adamw> kparal: how many times did you try this?
17:28:11 <kparal> it's interesting this has been in F23 and F24 common bugs, but no one proposed it a blocker in the past
17:28:18 <kparal> adamw: once
17:28:27 <kparal> is it a race?
17:28:30 <cmurf> huh
17:29:12 <adamw> kparal: i'm not sure, but i'm pretty sure i've seen a similar thing a few times but it's not been reliably reproducible
17:29:23 <adamw> this is just a 'rough memory' thing, though
17:29:29 <kparal> I can boot the livecd several times over and try
17:29:41 <kparal> I have it installed in a VM
17:30:09 <kparal> if I boot server dvd, I see the devices OK
17:30:43 * kparal now booting Workstation Live a few times
17:30:58 <adamw> kparal: https://bugzilla.redhat.com/show_bug.cgi?id=1219264
17:31:13 <adamw> kparal: what was on the disks you used to create the RAID set? did you wipe them properly before creating it?
17:31:50 <kparal> adamw: yeah, one uninitialized and one clean gpt table
17:32:14 <adamw> sure there's no stale LVM metadata?
17:32:24 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1219264#c18
17:32:50 <kparal> I used gnome-disks to create the gpt table
17:32:52 <adamw> and in fact your comment: https://bugzilla.redhat.com/show_bug.cgi?id=1219264#c22
17:33:00 <kparal> can lvm metadata survive?
17:33:03 <adamw> kparal: did the disk (image) have anything on it before that?
17:33:25 <adamw> in my experience it seems like yes, when it is not explicitly wiped. it's not stored in the same place as the disk label.
17:33:31 <kparal> yeah, standard LVM Fedora installations
17:33:48 <adamw> you can look at the installer logs and see if it seems to be discovering LVM volumes
17:33:55 <kparal> well I can try again with completely clean disks
17:34:07 <cmurf> yeah you have to do a tear down or LVM metadata survives
17:34:19 <cmurf> actually all metadata survives unless its signature is wiped
17:34:56 <cmurf> a new partition only replaces about 6 sectors of data, none of which is where any other metadata exists: LVM, mdadm, file system, LUKS, whatever
17:35:20 <adamw> you can also try running vgdisplay and lvdisplay and stuff
17:35:35 <kparal> cmurf: wipefs -a helps?
17:35:53 <cmurf> yes but you have to do that on each layer
17:36:05 <cmurf> and work your way backward
17:36:34 <cmurf> so wipefs -a the file system, then LUKS, then LVM, then the partitions, then the whole block device
17:36:47 <adamw> i'd probably use lvremove / vgremove / pvremove
17:36:52 <adamw> anyhoo
17:36:54 <cmurf> it's the same
17:37:00 <cmurf> it's just signature erasing
17:37:01 <adamw> delay for more info?
17:37:01 <kparal> this is all insane
17:37:13 <kparal> we can't expect this from our users
17:37:22 <cmurf> well anaconda is supposed to do that
17:37:56 <cmurf> but if you wipefs -a /dev/sda and left a bunch of other metadata on the drive, there's no way anaconda can wipe what it doesn't know is still there and has no way to discover it
17:38:23 <cmurf> there are many many problems i run into due to stale metadata on drives...
17:38:58 <kparal> if you want to wait, I'm running a fresh installation with completely clean disks
17:39:07 <kparal> otherwise I'll update the bug
17:39:33 <adamw> if we assume we're talking about stale metadata, we did explicitly consider that case for blocker status in 1219264 before, and reject it.
17:39:52 <kparal> yeah, I didn't have the impression this is about stale metadata
17:39:55 <kparal> but we'll see soon
17:40:29 <kparal> 70%
17:41:21 <kparal> funny, sometimes your focus is stuck inside a VM and you can't get it unstuck, if you have a different window selected
17:41:31 <kparal> *even if
17:42:52 * kparal booting Live
17:43:48 <kparal> same problem
17:43:50 <kparal> with clean disks
17:44:00 <kparal> freshly baked with qemu-img create
17:44:14 <cmurf> +1 then
17:44:14 <adamw> hmm, ok. seems like a different thing, then.
17:44:24 <adamw> if it's reliably reproducible with clean disks, +1
17:44:30 * adamw will have to try it out too
17:44:34 <cmurf> me4
17:44:45 <kparal> +1
17:45:04 <adamw> sgallagh: still around?
17:45:33 <sgallagh> Sorry, multi-taskin
17:45:55 <sgallagh> I haven't been following this one, so I'll abstain. Sorry.
17:46:04 <cmurf> that is +3
17:46:22 <kparal> we can punt and vote next time, I don't mind
17:46:41 <kparal> you wanted to do more testing anyway
17:47:26 <cmurf> what bug is this i got lost
17:47:34 <cmurf> i ended up on some promise array bug
17:47:42 <adamw> proposed #agreed 1225184 - AcceptedBlocker (Final) - as this is reproducible with clean disk images it seems like a violation of "When using the custom partitioning flow, the installer must be able to:
17:47:42 <adamw> Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" in the case of the live image
17:47:46 <adamw> grr
17:47:52 <cmurf> there it is
17:48:14 <adamw> proposed #agreed 1225184 - AcceptedBlocker (Final) - as this is reproducible with clean disk images it seems like a violation of "When using the custom partitioning flow, the installer must be able to correctly interpret...any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"  in the case of the liv
17:48:14 <adamw> e image
17:48:16 <adamw> sigh
17:48:23 <adamw> proposed #agreed 1225184 - AcceptedBlocker (Final) - as this is reproducible with clean disk images it seems like a violation of "When using the custom partitioning flow, the installer must be able to correctly interpret...any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" for live images
17:48:26 <adamw> there we go.
17:48:33 <cmurf> that's an old bug, Fedora 22
17:48:37 <cmurf> ack
17:48:47 <kparal> ack
17:48:49 <adamw> cmurf: it could actually be not quite the same bug when we look into it in detail.
17:49:19 <adamw> so i suppose it might be better filed as a new one than attached to all this history. but we can deal with details later.
17:49:24 <adamw> #agreed 1225184 - AcceptedBlocker (Final) - as this is reproducible with clean disk images it seems like a violation of "When using the custom partitioning flow, the installer must be able to correctly interpret...any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" for live images
17:49:30 <adamw> alright, that's all the proposals i believe
17:49:34 <adamw> #topic Open floor
17:49:39 <adamw> any other blocker/f25 business?
17:49:55 <cmurf> kparal: so comment 66 is the current reproduce steps?
17:50:04 <cmurf> https://bugzilla.redhat.com/show_bug.cgi?id=1225184#c66
17:50:08 <kparal> cmurf: yes
17:50:13 <cmurf> start clean, install F24, then try to install F25 over that
17:50:15 <kparal> very simple
17:50:23 <kparal> raid 0. yes
17:50:29 <cmurf> ok easy
17:50:31 <kparal> I used standard parts
17:50:35 <kparal> partitions
17:50:42 <cmurf> standard or raid?
17:50:50 <kparal> raid, but without lvm on top
17:50:53 <cmurf> ok
17:51:08 <cmurf> so i think there's this new thing in Fedora 25 installer, where we have LVM raid also
17:51:24 <cmurf> i haven't looked into it because i think custom part is already like, omfg,
17:51:35 <cmurf> but yeah mdadm raid and lvm raid
17:51:41 <cmurf> in one instaler
17:51:57 <kparal> adamw: nothing else from me
17:52:03 <cmurf> me either
17:52:29 <adamw> alrighty, then thanks for coming, folks
17:52:34 * adamw sets fuse
17:52:52 <coremodule> Thanks for hosting adamw.
17:54:42 <kparal> thanks
17:54:44 <adamw> #endmeeting