16:00:02 <roshi> #startmeeting F23-blocker-review
16:00:02 <zodbot> Meeting started Mon Oct  5 16:00:02 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:02 <roshi> #meetingname F23-blocker-review
16:00:02 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:00:02 <roshi> #topic Roll Call
16:00:07 <adamw> ahoyhoy
16:00:12 <roshi> who's around for some blocker review?
16:00:16 * kparal is here
16:00:19 <roshi> o/ adamw kparal
16:00:26 <roshi> #chair adamw kparal
16:00:26 <zodbot> Current chairs: adamw kparal roshi
16:01:22 <roshi> danofsatx: satellit_e sgallagh ?
16:01:44 <sgallagh> I'm here-ish
16:01:50 <sgallagh> /me needs to grab something to eat
16:03:28 * roshi gives people some time to show up
16:03:40 <garretraziel> :-)
16:03:43 * garretraziel is here
16:03:53 <roshi> #chair garretraziel
16:03:53 <zodbot> Current chairs: adamw garretraziel kparal roshi
16:05:14 <roshi> I guess we can move forward
16:05:17 <roshi> #topic Introduction
16:05:17 <roshi> Why are we here?
16:05:17 <roshi> #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:05:21 <roshi> #info We'll be following the process outlined at:
16:05:23 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:26 <roshi> #info The bugs up for review today are available at:
16:05:28 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:31 <roshi> #info The criteria for release blocking bugs can be found at:
16:05:33 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:05:36 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:05:39 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:05:56 <roshi> well, we've got 12 proposals to grind through
16:06:18 <roshi> #topic (1183880) wrongly permits deletion of shared EFI System partition
16:06:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1183880
16:06:24 <roshi> #info Proposed Blocker, anaconda, POST
16:07:32 <adamw> so this is a fairly controversial one
16:07:50 <adamw> it was previously accepted as a blocker, the anaconda team has asked us to re-consideri t.
16:07:51 <roshi> yeah
16:08:15 <adamw> they noted that it doesn't really meet the criterion it was accepted under, and suggested they don't think it ought to be a blocker on merit.
16:08:39 <adamw> i posted a link to the previous discussion in the bug, for reference.
16:09:05 * roshi is reading
16:09:07 <adamw> personally having played with it to work on a patch for it i do think it's kinda bad, but i'd be OK with a -1 mainly on the basis that it's not a regression
16:09:58 <adamw> there's also a video i posted to hopefully make the impact of the bug clear - https://www.youtube.com/watch?v=PcUd4K0iM6c
16:12:43 <sgallagh> Just watched the video
16:13:23 <sgallagh> So, I'd have to fall very slightly on the side of "this is custom partitioning, you are supposed to know what you're doing". The misleading message about what you are deleting is unfortunate, but I don't think I'd block on it.
16:13:58 <danofsatx> sorry, can't participate today
16:14:42 <adamw> to play devil's advocate I have a small issue with the 'you have to know what you're doing' argument which is that the ESP is basically firmware process crap. real world experience suggests that the kind of people who think they know what they're doing - and actually DO know about partition tables and filesystems and LVM and RAID and etc - don't necessarily know about the ESP.
16:15:01 <adamw> but i'm not married to that one, it's just an unfortunate fact.
16:15:09 <sgallagh> /me nods
16:15:41 <sgallagh> adamw: This one feels to me like another of those "we'd probably hedge at Go/No-Go" bugs
16:15:48 <roshi> I think the real bug, is the assumption that fedora owns /boot/efi
16:15:57 <adamw> sgallagh: yeah, that's kinda where i come on it too, if we found it on the tuesday we'd probably be looking for ways to make it not a blocker
16:16:09 <roshi> i'm afraid so
16:16:16 <adamw> roshi: eh, it's more complex than that
16:16:32 <roshi> for sure - but that's a faulty assumption in the first place
16:16:50 <roshi> /boot/efi is supposed to be a shared partition, right?
16:17:06 <adamw> roshi: partitions can appear multiple times, their appearing in one bucket is not an indication that that bucket "owns" them (which is another reason i'm not a fan of the 'delete them all' button - my patch avoids deleting any shared partitions). so in theory, the ESP in my video should appear twice, once in Fedora's bucket, once in a bucket labelled 'Windows'
16:17:08 * roshi votes to just always list /boot/efi outside the Fedora root
16:17:24 <adamw> roshi: that was one of the options we had in a long discussion in #anaconda
16:17:31 <adamw> but let's not rehash that here, we're just here to decide on blockeriness
16:18:25 <roshi> my purist brain says blocker, but the jaded practical brain in me says we'll just dodge it at go no-go and I doubt it'll get worked on in the mean time, so what's the point?
16:19:17 <roshi> votes?
16:19:27 <sgallagh> Yeah, this really doesn't seem like a bug worth burning goodwill over
16:19:38 <cmurf> +1 surprise
16:19:47 <roshi> I guess I'll go -1
16:19:51 <sgallagh> -1 blocker
16:20:56 <roshi> adamw: kparal garretraziel ?
16:21:03 <cmurf> the video makes it stunningly obviously a blocker
16:21:16 <kparal> sorry, I was distracted, didn't follow the discussion
16:21:25 <cmurf> if the argument is that it’s not a blocker on the basis of regressions then metric f tons of bugs are no longer blockers
16:21:26 <adamw> roshi: we already have two somewhat-viable fixes for it, fwiw.
16:21:42 <garretraziel> I'm -1 blocker
16:22:16 <garretraziel> it's inconvenient, but I can see that we would probably discarded it on go-nogo
16:22:29 <cmurf> ok well then we have no standards
16:22:41 <roshi> cmurf: it's in custom partitioning, it does exactly what it says it's going to do, I always thought it was known that dual boot will mess up some of your partitions and you need to be able to fix them
16:22:56 <roshi> that last one was just in general
16:23:02 <roshi> not anaconda specific
16:24:00 <adamw> roshi: not...really, if you do this same thing on a BIOS system, both OSes will boot when you're done.
16:24:12 <cmurf> adamw: oh so it’s a regression
16:24:15 <adamw> cmurf: no.
16:24:26 <cmurf> adamw: it’s a matter of perspective
16:24:28 <adamw> 'regression' would mean doing this same thing (on a UEFI system) in a previous Fedora wroked.
16:24:35 <dlehman> this could also happen with swap, btw
16:24:43 <adamw> lots of things are matters of perspective, but the definition of 'regression' is not.
16:24:46 <cmurf> adamw: i get your logic, i just happen to disagree, it’s more a regression than not
16:24:55 <dlehman> perhaps not such a total failure, but still a shared device
16:25:15 <adamw> dlehman: do swaps get associated with OS roots?
16:25:22 <dlehman> cmurf: a regression from which release?
16:25:25 <adamw> dlehman: i thought they always showed under 'unknown' as we can't really tell what OS c reated them
16:25:26 <dlehman> adamw: yes
16:25:29 <adamw> huh
16:25:36 <dlehman> if they're in /etc/fstab they're listed
16:25:48 <adamw> oh, right.
16:25:57 <adamw> well, anyhow, seems like we have some votes.
16:26:01 * adamw is somewhere around a -0.5.
16:26:05 <cmurf> dlehman: all, in the context that the same behavior on BIOS systems does not result in an unbootable system where on UEFI it does because the user is wrongly provided visible access to what is essentially an MBR gap
16:26:28 <dlehman> you're trying to use poetic license, and it doesn't work here
16:26:44 <dlehman> in F22 this exact behavior existed. same in F21, ...
16:26:54 <cmurf> it’s still wrong, it was a regression then too
16:27:24 <cmurf> I filed that bug under F22 and it was categorically rejected as notabug
16:27:31 <cmurf> twice
16:27:43 * roshi takes a look at the fixes
16:27:54 <adamw> cmurf: there is no point arguing about the definition of 'regression' because that's not going to get you anywhere even if you win
16:27:59 <adamw> the word 'regression' is not the important thing here
16:28:09 * linuxmodder late
16:28:26 <adamw> if you somehow win that argument and we say 'a regression is what you think it is', no-one is going to change their mind about whether the bug is a blocker, because they're not deciding that on the basis of the precise definition of the word 'regression'
16:29:03 <cmurf> adamw: words have meaning, I didn’t bring up “not a regression” logic as an argument why it’s not a blocker; but once introduced into the logical arguing, yes it’s relevant. You want to tak it off the table now? Fine.
16:29:27 <adamw> cmurf: when i brought it up, i meant that the fact the bug happens exactly the same in F21 and F22 is significant
16:29:52 <adamw> you're still wrong about the definition of 'regression', but the point is that *even if you were right it doesn't matter*
16:30:11 <linuxmodder> installer  iirc  has option to  mount not format ESP tho
16:30:27 <cmurf> adamw: I understand that logic. I’m using BIOS as my reference for what is regressive. What is the reference is subjective.
16:30:57 <adamw> linuxmodder: sure, you *can* do this properly (in various ways). the bug is about the fact that the installer makes it unfortunately easy to choose a bad approach.
16:31:25 <linuxmodder> adamw,  wasn't someone working on a  custom efi  thing for  anaconda?
16:31:43 <linuxmodder> or  making multiple ESP entries
16:32:03 <linuxmodder> or maybe I misread that commit  request
16:32:06 <adamw> linuxmodder: i don't know what you mean, but probably! you can do all sorts of things in custom partitioning, some of which even make sense. that doesn't seem relevant here
16:32:27 <linuxmodder> this commit  was  the auto NOT custom
16:32:35 * linuxmodder looks for the link
16:32:47 <adamw> so that makes it even less relevant, because we're discussing whether a bug on the custom path is a blocker
16:32:59 <adamw> srsly can we please stay on topic here and make a decision? /me has other things to do before he dies
16:33:43 <sgallagh> I think the decision was made fifteen minutes ago
16:33:50 * roshi tallies votes
16:33:52 <sgallagh> The rest has been fillibuster.
16:34:15 <roshi> -3.5/+1
16:34:44 <adamw> are we +1 FE?
16:34:46 <linuxmodder> if its only  for custom I'd be  -1
16:34:55 <adamw> since there are fixes proposed.
16:34:56 <sgallagh> +1 FE most assuredly
16:35:00 <adamw> +1 FE from me.
16:35:02 <roshi> yeah, +1 FE for sure
16:35:07 <linuxmodder> +1FE -1 for the block
16:35:20 <garretraziel> + FE
16:36:32 <roshi> proposed #agreed - 1183880 - RejectedBlocker AcceptedFreezeException Final - While we don't consider this bug to be a blocker, we do think getting a fix in would alleviate some confusion and potential for errors when users attempt to do a dual boot.
16:37:16 <adamw> ack
16:37:18 <linuxmodder> ack
16:37:20 <garretraziel> ack
16:37:26 <cmurf> Basically on principle you guys are saying that things that are not version regressive can arbitrarily be blocker bugs based on a pile of excuses that have absolutely nothing to do with the blocker critieria. This is so logically inconsistent it surprises even me.
16:38:08 <linuxmodder> cmurf,  not even close
16:38:21 <roshi> cmurf: I don't think it violates the dual boot criteria
16:38:47 <linuxmodder> if it were on auto I *might* see a  dual boot  block
16:38:50 <roshi> that criteria says 'into free space' - not into 'recently deleted space'
16:38:51 * kparal is sorry but currently afk
16:38:57 <sgallagh> cmurf: I think you need to go somewhere else and cool off for a while. Your comments are no longer constructive.
16:39:17 <roshi> but we have the acks and need to move through the rest of the bugs
16:39:26 <roshi> #agreed - 1183880 - RejectedBlocker AcceptedFreezeException Final - While we don't consider this bug to be a blocker, we do think getting a fix in would alleviate some confusion and potential for errors when users attempt to do a dual boot.
16:39:32 <roshi> #topic (1268764) AttributeError: 'str' object has no attribute 'busid'
16:39:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1268764
16:39:38 <roshi> #info Proposed Blocker, anaconda, NEW
16:40:47 * linuxmodder stays out on lack of  sec arch knowledge
16:42:08 <sgallagh> Secondary arch is by definition non-blocking
16:42:11 <sgallagh> -1 blocker
16:42:34 * adamw reads
16:43:18 <adamw> yup, -1, I can be +1 FE if the fix is safe.
16:43:30 <roshi> yep
16:43:38 <roshi> -1, +1 FE
16:44:34 <roshi> proposed #agreed - 1268764 - RejectedBlocker AcceptedFreezeException Final - Because this only fails on a secondary arch, it's not a blocker. However, we'd gladly consider a fix during freeze.
16:44:34 <sgallagh> I'd prefer to withhold FE judgement for now.
16:44:53 <sgallagh> Changes to this level of the stack in blivet might be too risky during Freeze
16:45:30 <adamw> FE grants the possibility for a fix to be taken, it doesn't require it
16:45:33 <adamw> and this does sound like a bad bug
16:45:58 <linuxmodder> i'd be  +1fe on  a safe  fix
16:46:15 <roshi> and I said we'd "consider" it - so if the fix causes issues we deny it
16:46:26 <sgallagh> Fair enough. +1 FE
16:46:31 <roshi> acks/nakcs?
16:46:38 <sgallagh> ack
16:46:39 <linuxmodder> ack +1fe  from me
16:46:49 <roshi> #agreed - 1268764 - RejectedBlocker AcceptedFreezeException Final - Because this only fails on a secondary arch, it's not a blocker. However, we'd gladly consider a fix during freeze.
16:46:53 <roshi> #topic (1267312) muon-discover not showing any packages
16:46:56 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1267312
16:46:58 <roshi> #info Proposed Blocker, appstream, ON_QA
16:48:14 <adamw> hmm - https://bugzilla.redhat.com/show_bug.cgi?id=1267312#c5
16:48:30 * adamw is not a fan of having 'tentative plans' post-beta.
16:49:03 <linuxmodder> same ^
16:49:07 <roshi> yeah
16:49:24 <linuxmodder> its all or  nothing in beta as i see it especially  this close a  freeze
16:50:14 <roshi> so GUI package managers in KDE are all borked, if I read dans comment right?
16:50:57 <linuxmodder> that's how I also read it
16:51:10 <adamw> well, 'broken beyond repair' is putting it rather strongly
16:51:27 <adamw> basically it's missing package group support, which it's been missing for a couple of releases and is not considered release blocking.
16:51:44 <linuxmodder> danofsatx,   ping  your bug on review
16:51:53 <adamw> i'd be inclined to punt on this and ask KDE team to firm up their plans PDQ.
16:52:13 <roshi> they'll assure us it'll be RSN :p
16:52:17 <roshi> that works for me
16:52:33 <linuxmodder> +1 for a punt
16:52:37 <roshi> votes for punt while KDE team shores up plans?
16:52:59 <garretraziel> +1 punt
16:53:01 <roshi> +1 punt
16:53:50 <roshi> proposed #agreed - 1267312 - Punt Final - We'd like to stall deciding this bugs status until the KDE folks can firm up their plans.
16:54:01 <adamw> ack
16:55:00 <garretraziel> ack
16:55:01 <roshi> ack/nack/patch?
16:55:09 <roshi> #agreed - 1267312 - Punt Final - We'd like to stall deciding this bugs status until the KDE folks can firm up their plans.
16:55:13 <roshi> #topic (1244175) distro-sync removes orphaned packages in certain cases (kernel update)
16:55:16 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1244175
16:55:19 <roshi> #info Proposed Blocker, dnf, NEW
16:55:24 * kparal is back, right on time :)
16:56:16 <kparal> I think fesco helped us a bit here, by ruling they want distro-sync in system-upgrade
16:56:40 <kparal> ah, and I'm talking about a different bug
16:56:46 <kparal> ignore me
16:57:49 <adamw> +1, sure
16:58:04 <adamw> since the intent is that dnf-system-upgrade will use distro-sync mode it seems to meet the criteria
16:58:20 <roshi> makes sense to me
16:58:24 <roshi> +1
16:59:00 <kparal> +1 from me as well
16:59:03 <linuxmodder> not sure i get all the fedup bits  but  +1  here
16:59:13 <roshi> proposed #agreed - 1244175 - AcceptedBlocker Final - This bug is a clear violation of the following Beta criterion: "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)."
16:59:24 <linuxmodder> ack
16:59:28 <kparal> ack
16:59:32 <garretraziel> ack
16:59:37 <roshi> #agreed - 1244175 - AcceptedBlocker Final - This bug is a clear violation of the following Beta criterion: "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)."
16:59:42 <roshi> #topic (1260989) system upgrade using distro-sync fails - dnf tries to remove all kernels
16:59:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1260989
16:59:47 <roshi> #info Proposed Blocker, dnf, NEW
17:00:02 <roshi> oh, who wants to secretarialize?
17:00:31 * adamw will pick it up
17:00:36 <kparal> this might have the same root cause as the previous bug
17:00:48 <roshi> thanks adamw
17:00:49 <adamw> well, we can dupe them later if necessary
17:01:03 <linuxmodder> given the  possible connection to last one  id be +1
17:01:27 <kparal> this effectively blocks distro-sync from working, at the moment
17:02:11 <kparal> unless you do a clever workaround - install f23 kernel on f22 and run the upgrade while booting from it
17:02:19 <linuxmodder> thats a  clear voilation isn't it?
17:02:21 <adamw> that seems absurd
17:02:24 <adamw> so yeah, seems +1y.
17:02:34 <kparal> +1
17:02:53 * linuxmodder runs the  24 kernels but  agrees that would be absurd for the avg user
17:03:01 <roshi> +1
17:03:13 * linuxmodder already was +1
17:03:17 <garretraziel> +1
17:04:21 <roshi> proposed #agreed - 1260989 - AcceptedBlocker Final - This bug violates the FESCo ruling on upgrade behavior: "Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them as part of the upgrade or aborting."
17:04:36 <roshi> whee, extra carriage return
17:04:59 <linuxmodder> ack
17:05:00 <kparal> ack
17:05:04 <garretraziel> ack
17:05:06 <roshi> proposed #agreed - 1260989 - AcceptedBlocker Final - This bug violates the FESCo ruling on upgrade behavior: "Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them as part of the upgrade or aborting." Because of this, the release process is blocked and needs to be fixed.
17:05:23 <kparal> ack again
17:05:46 <adamw> acky ack ack
17:05:50 <roshi> #agreed - 1260989 - AcceptedBlocker Final - This bug violates the FESCo ruling on upgrade behavior: "Upgrades use distro-sync by default. On resulting conflicts, the user is presented with the list of problematic packages and the choice of removing them as part of the upgrade or aborting." Because of this, the release process is blocked and needs to be fixed.
17:05:59 <roshi> #topic (1268612) upgrade silently fails if /usr/bin/plymouth does not exist
17:06:03 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1268612
17:06:05 <roshi> #info Proposed Blocker, dnf-plugin-system-upgrade, POST
17:07:28 <kparal> dnf is missing a dependency it seems
17:07:37 <roshi> how did plymouth get uninstalled?
17:07:46 <kparal> people might uninstall it
17:07:52 <kparal> it adds 1 sec to boot time
17:07:59 <roshi> ...
17:08:07 <roshi> fair enough I guess
17:08:07 <kparal> but dependency will not cut it, because it will not regenerate initrd
17:08:18 <kparal> I wonder how to fix this properly
17:08:42 <adamw> i don't think dnf system upgrade should require plymouth
17:08:50 <adamw> it's only using it to print a nice status screen
17:08:53 <kparal> oh, it has a patch already
17:08:57 <linuxmodder> 1 sec really  if people are  that anal on boot time delay  they have bigger issues imo
17:09:02 <kparal> adamw: yes, you're right
17:09:05 <adamw> it's a fairly recently added feature, i guess it's just missing a conidtional to say 'if there's no plymouth, skip the status screen'
17:09:21 <kparal> easy fix, then. great
17:09:30 * adamw not really sure this merits a blocker, unless the failure is somehow destructive
17:09:34 <adamw> we could fix it post-release and no-one'd die.
17:09:59 <linuxmodder> seems edge case-ish at  any rate
17:10:12 <linuxmodder> +1 for a  Fe but not a  block
17:10:29 <kparal> I'm fine with -1 blocker +1 fe
17:10:35 <kparal> there's no data loss
17:10:54 <roshi> works for me
17:10:57 <kparal> it's edge case and can be fixed post-release
17:11:00 <adamw> yup
17:12:54 <roshi> proposed #agreed - 1268612 - RejectedBlocker AcceptedFreezeException Final - Because this bug doesn't cause any data loss or real damage to the system, it's not considered a blocker. But, we would gladly consider a fix during freeze.
17:13:05 <garretraziel> ack
17:13:21 <kparal> I'd also mention it's quite uncommon. but ack
17:14:07 <adamw> ack
17:14:15 <roshi> #agreed - 1268612 - RejectedBlocker AcceptedFreezeException Final - Because this bug doesn't cause any data loss or real damage to the system, it's not considered a blocker. But, we would gladly consider a fix during freeze.
17:14:27 <roshi> #topic (1268802) updates-testing is still enabled for Fedora 23
17:14:27 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1268802
17:14:27 <roshi> #info Proposed Blocker, fedora-repos, NEW
17:14:38 <kparal> I wasn't sure whether to propose this as a blocker
17:14:42 <linuxmodder> i'd also think if you are  knowledgable enough to do that (or  stupid too without researching issues that may ensue) you get what you get
17:14:43 <linuxmodder> ack
17:14:44 <kparal> I'm still a QA rookie
17:14:57 <linuxmodder> def not common
17:14:58 <kparal> or maybe it's dementia
17:15:20 <kparal> it might be an automatic blocker
17:15:25 <linuxmodder> seems logical to  turn off at this  point
17:15:40 <linuxmodder> especially if  blocking composes
17:15:41 <adamw> it's on someone's schedule, it doesn't usually need a blocker bug
17:15:53 <adamw> doesn't ahve anything to do with composes
17:16:05 <kparal> we have to have it in RC1, don't we?
17:16:11 <adamw> yeah, sure, in that sense.
17:16:41 <kparal> do whatever you see fit with it
17:17:05 <kparal> since it's filed, I'd say +1
17:17:26 <linuxmodder> ditto
17:17:40 <adamw> yeah, since the bug's there +1, but for the record in future it's usually fine to just handle this informally with releng/fpm
17:17:54 <linuxmodder> noted
17:18:00 <linuxmodder> fpm ?
17:18:03 <adamw> fedora program manager
17:18:08 <linuxmodder> ah
17:18:39 <roshi> proposed #agreed - 1268802 - AcceptedBlocker Final - This is something that needs to be fixed by release time. It's probably on a schedule somewhere, and in the future we'll just reach out to releng or the fpm to get it resolved.
17:18:53 <kparal> ack
17:19:12 <garretraziel> ack
17:19:41 <adamw> ack
17:19:47 <roshi> #agreed - 1268802 - AcceptedBlocker Final - This is something that needs to be fixed by release time. It's probably on a schedule somewhere, and in the future we'll just reach out to releng or the fpm to get it resolved.
17:20:04 <adamw> calling it 'fixed' is a bit inaccurate, but w/e
17:20:16 <roshi> this == the bug :p
17:20:18 <roshi> #topic (1264012) liveusb-creator doesn't create bootable Live i686 image in default cp mode
17:20:21 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1264012
17:20:23 <roshi> #info Proposed Blocker, liveusb-creator, NEW
17:21:57 <adamw> eh, /me still not hugely sold on this one, but could go either way
17:22:14 <kparal> I don't remember ever touching this issue, so I proposed it just to be safe
17:22:50 <roshi> I'm still -1 on this, since it works on F22
17:23:04 <kparal> we require latest spin-kickstarts, but we don't explicitly say whether our tools need to be able to create bootable media of the final product
17:23:06 <roshi> if you're doing this from F23, you obviously have some other means of installing it
17:23:22 <kparal> roshi: so I wonder where's the line, what if you doesn't?
17:23:34 <kparal> how many of the tools can be broken on F23?
17:23:34 <roshi> how'd you get F23 in the first place?
17:23:41 <kparal> roshi: upgrade
17:23:46 <linuxmodder> being the defualt  method id be  +1 fe on a sane  fix
17:23:53 <kparal> and then you want to install on a different computer, so you create a bootable usb
17:23:59 <kparal> try to create
17:24:01 <roshi> ah, I guess so
17:24:24 <adamw> it's a reasonable scenario
17:24:26 * roshi should really work with those tools more - you just can't beat the simplicity of dd, so that's what I always use
17:24:29 <roshi> yeah
17:24:41 <kparal> what if dd was broken on F23?
17:24:45 <adamw> it's just we have such an unfortunate combinatorial explosion here
17:24:51 <kparal> I know
17:24:58 <roshi> if dd was broken, much more of our universe would explode
17:25:01 <kparal> esp. with usb writers
17:25:01 <adamw> luc now has *two* modes so we effectively have four tools, across something like five OSes?
17:25:02 <roshi> dd is a core tool
17:25:18 <adamw> so when one square on that bingo sheet is checked i'm like, eh
17:25:50 <kparal> otoh we removed liveusb-creator from the officially recommended methods, did we?
17:26:18 <Southern_Gentlem> ?? do the livecd-tools work like livecd-iso-to-disk?
17:26:33 <adamw> i guess we should note that 1263988 is coming up
17:26:39 <adamw> kparal: i think it's still in there.
17:26:39 <kparal> it seems we didn't
17:26:50 * kparal looking at https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Using_liveusb-creator_.28Windows_and_Fedora.2C_graphical.2C_non-destructive.29
17:27:21 <kparal> "The liveusb-creator method is less reliable and cannot write non-live images, but it is graphical, supports data persistence and non-destructive writing, and is easily available for Windows, OS X and Fedora. "
17:27:31 <kparal> :)
17:28:11 <linuxmodder> work for  me
17:28:12 <linuxmodder> 32 and 64  bios and efi
17:28:29 <adamw> i'll note we have a whole thicket of things that i suspect are all basically the same syslinux bug
17:28:35 <adamw> 1263988 , 1264012 , 1241159 , 1241855 , 1250874
17:28:48 <kparal> even though I don't like it, I think we should have the same requirements for f23 final as we do for f22 for usb writing. to reduce the testing matrix and increase reliability, we should rather decommission unreliable tools
17:28:48 <linuxmodder> dup fest ?
17:29:10 <roshi> kparal: that makes sense to me, I'm +1 to that
17:29:33 <kparal> in this case, it seems rather syslinux bug, so the tool itself might not be to blame
17:29:34 <linuxmodder> +1 to kparal  idea
17:29:56 <roshi> I was just seeing this as something that could be fixed in a 0-day or with updates and forgetting that people upgrade their machines pre-release
17:31:01 <kparal> what I'm not saying is that we need more fields in our usb testing matrix :)
17:31:08 <roshi> haha
17:31:09 <roshi> yeah
17:31:24 <linuxmodder> matrix sprawl is  fun ;)
17:31:40 <roshi> votes?
17:32:00 <linuxmodder> punt from me
17:33:30 * adamw really doesn't know.
17:33:35 <roshi> me either
17:33:54 <adamw> maybe punt to find out more about exactly how tricky this is going to be to fix?
17:33:58 <kparal> well, in that case we can afford to let it slip and discuss it for the next release
17:34:01 <roshi> it doesn't strictly violate the criteria, but I'd like to see it fixed under kparals logic
17:34:02 <adamw> <pjones> I bet they are; I've seen it but not investigated
17:34:08 <linuxmodder> if we  note it as unreliable due toa  known bug  i'd be  -1
17:34:17 <roshi> +1 punt
17:34:33 <roshi> there's also the chance that the syslinux bug gets fixed and this goes away, right?
17:34:48 <linuxmodder> hopefully
17:34:57 <kparal> roshi: this question will come again some time :)
17:35:29 <kparal> let's punt it
17:35:39 <linuxmodder> stil +1 punt with a  possible reach out to  syslinux gang  on a  fix
17:36:04 <adamw> roshi: well, i mean, the *only* way this is likely to go away is if the syslinux bug gets fixed, aiui.
17:36:11 <adamw> (i guess that's a guess, but it seems that way)
17:36:29 <kparal> I think this should be covered by our criteria, but I'm not fight hard for it. I'd also be OK if we decided that "only dd has to work" or something similar
17:36:30 <roshi> proposed #agreed - 1264012 - Punt Final - We're going to wait on some more information before we decide the status of this bug.
17:36:44 <linuxmodder> short of some hack like  is  presently in  gnome hostname  thing
17:36:53 <linuxmodder> ack
17:37:36 <kparal> ack
17:38:03 <roshi> #agreed - 1264012 - Punt Final - We're going to wait on some more information before we decide the status of this bug.
17:38:19 <roshi> #topic (1267949) certain plymouth themes don't indicate system upgrade progress properly, PC can look frozen
17:38:22 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1267949
17:38:25 <roshi> #info Proposed Blocker, plymouth, NEW
17:39:22 <kparal> this is another plymouth edge case, this time unfortunately there's a possibility of data loss. at least I almost corrupted by system due to it, which would have quite annoyed me
17:39:36 <kparal> plymouth segfaults with the spinner theme
17:39:56 <kparal> no progress, no VT, just black screen, the PC seems frozen
17:40:08 <linuxmodder> +1fe  on the edge case  nature of it
17:40:09 <kparal> but it's upgrading the system in the background
17:40:33 <kparal> sorry, VTs are working
17:40:52 <kparal> if you happen to known about them and it occurs to you
17:41:09 <kparal> it almost didn't to me, I thought it hanged during boot
17:41:22 * adamw finding it a bit difficult to care about non-standard plymouth themes that aren't the hot dog.
17:41:35 <halfline> maybe as a workaround the system upgrade process should force the plymouth theme back to stock
17:41:37 <kparal> adamw: hot dog is working fine
17:41:44 <linuxmodder> so if it were  -hot-dog you'd care eh?
17:42:03 <adamw> absolutely.
17:42:08 <kparal> halfline: hey, have you figured a good way to ensure that?
17:42:25 <linuxmodder> comical admitedly  but  not best one ouyt imo
17:43:03 <adamw> halfline: clearly it should force the plymouth theme to beefy.
17:43:10 * roshi has never messed with plymouth themes
17:43:21 <adamw> it should then spawn a worm which finds all other fedora/RHEL systems on the network and sets their themes to beefy too.
17:43:44 <halfline> kparal: well what i mean is maybe the system update dnf plugin should run plymouth-set-default-theme --rebuild-initd charge before starting
17:43:48 <kparal> I think it would be fine from QA standpoint if system-upgrade simply contained a list of blacklisted themes and refused to work
17:44:13 <halfline> nothing's full proof though
17:44:19 <halfline> since there may be other grub entries
17:44:21 <kparal> halfline: hmm, yes, that should be good enough
17:44:25 <halfline> running older plymouths or different themes
17:44:26 <roshi> so this only causes confusion to people futzing with their plymouth themes?
17:44:46 <kparal> roshi: some people change wallpapers, I change boot themes :)
17:45:08 * roshi never sees his wallpapers...
17:45:12 <roshi> so I just stopped
17:45:12 <adamw> kparal: you realize this kind of thing is why we have the isolation unit
17:45:22 <kparal> yes, I know. I've tried to be ill
17:45:37 <kparal> I cured too fast
17:45:45 <halfline> to be fair, spinner is the nicest plymouth theme
17:45:50 <kparal> also, I wanted to play steam games with opengl 4
17:46:03 <roshi> I didn't even know that was themed and easy to mess with...
17:46:04 <kparal> halfline: that's why I use it :)
17:46:09 * roshi adds it to his list
17:46:26 <halfline> i've actually tried to make spinner the default in fedora a couple of times
17:46:36 <halfline> but people get crotchety
17:47:06 <kparal> halfline: do you think it would be hard to fix the theme?
17:47:16 <halfline> probably not
17:47:25 <halfline> but getting the fixes deployed to everyone might be more of a challenge
17:47:45 <halfline> since we don't generally rebuild the initrd in plymouth updates
17:47:52 <kparal> I see. we can still use the blacklist, but wwoods might not like maintaining it
17:48:40 <halfline> i think rebuilding the initrd once as part of the dnf upgrade process is a little gentler than rebuilding it every time there's a plymouth update. granted i rarely do plymouth updates either
17:48:46 <halfline> so maybe it doesn't actually matter in practice
17:48:48 <kparal> one additional theme ('script') if affected, but not as severely. just the graphical progress is broken, but you can switch to text one easily
17:48:49 <linuxmodder> spinner is  sweet
17:48:50 <linuxmodder> lol
17:49:00 <linuxmodder> how so halfline
17:49:12 <halfline> how so what?
17:50:43 <kparal> personally, I'd include to +1 here, but any simple solution or workaround is fine here (like the blacklist)
17:50:47 <kparal> *incline
17:51:09 * adamw suspects it fails the 'last blocker at the go/no-go meeting' test
17:51:29 <adamw> so i'm a weak -1, but i wouldn't hate +1.
17:51:33 <kparal> should I reply or consider myself isolated and shut up?
17:51:41 <adamw> did anyone else vote?
17:52:05 <roshi> I got distracted looking at plymouth themes
17:52:12 <kparal> :D
17:52:19 <roshi> and I don't really know how to vote on this one...
17:52:23 <kparal> roshi: go hot dog
17:52:28 <roshi> that's my thought
17:52:43 <kparal> never heard of 'mustard indicates progress'?
17:52:52 <roshi> oh, I've heard of that
17:52:52 <kparal> now you know
17:53:04 <roshi> my home town is the internet - I've heard things
17:53:47 <kparal> any other votes?
17:53:55 <kparal> we're going to get all fired this way
17:54:23 <linuxmodder> not a  deal breaker but a nice to have i guiess
17:54:31 <roshi> I guess I'd be -1 Blocker and +1 FE
17:54:34 <garretraziel> I'm -1
17:54:41 <roshi> document in CommonBugs
17:54:46 <garretraziel> -1 blocker I mean
17:54:57 <kparal> traitors! all right then
17:54:57 <linuxmodder> -1 Block +1 ffe here too
17:55:05 <roshi> if you're futzing with plymouth themes, you probably know to try other vts if something seems bricked
17:55:22 <kparal> well the issue is that you don't know you must not restart
17:55:30 <linuxmodder> not sure I'd call it  common tho roshi
17:55:36 <kparal> as I say, I almost corrupted my own home system
17:55:39 <linuxmodder> but as a cya  ok
17:55:41 <kparal> and I'm fairly experienced :)
17:56:03 <linuxmodder> experience can be  more deadly than  ignorance
17:56:05 <roshi> lol, I suppose that's true :p
17:56:15 <adamw> i thought it was Internet Wisdom that you never forcibly interrupt any 'upgrade' process unless absolutely unavoidable
17:56:29 <kparal> if you know it's happening
17:56:37 <roshi> my first steps are always: check selinux, check another vt, take a drink
17:56:48 <roshi> follow those simple rules, you'll be fine
17:57:08 <linuxmodder> if its  background update or  like a  multi user  instance started on another  systemwide  acct  could be  problematic
17:57:11 <adamw> those are in reverse order, right?
17:57:31 <roshi> adamw: you should start this process already in the process of drinking
17:57:46 <linuxmodder> checking selinux after a stiff drink may not be  advised ;)
17:58:07 <roshi> not advised, but medically required - it's what keeps your eyes from bleeding
17:58:09 <linuxmodder> but your box not mine
17:58:10 <roshi> pretty sure
17:58:31 <linuxmodder> 200+ context tags yeah likely
17:58:47 <roshi> proposed #agreed - 1267949 - RejectedBlocker AcceptedFreezeException Final - This bug doesn't violate any criterion, but it would be good to get fixed. We'll consider a fix during freeze for theme handling.
17:58:48 <adamw> so is anyone changing their vote?
17:58:48 <adamw> ack
17:58:56 <garretraziel> ack
17:59:12 <roshi> #agreed - 1267949 - RejectedBlocker AcceptedFreezeException Final - This bug doesn't violate any criterion, but it would be good to get fixed. We'll consider a fix during freeze for theme handling.
17:59:16 <roshi> #topic (1266673) TypeError: Argument 0 does not allow None as a value
17:59:19 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1266673
17:59:21 <roshi> #info Proposed Blocker, python-blivet, NEW
18:01:38 <roshi> btrfs bug, huh?
18:01:40 <kparal> halfline: if you managed to find some time to actually fix the theme, it would be very appreciated. I'm afraid wwoods will not safe-guard system-upgrade against this issue on his own
18:02:10 <adamw> interpreting an existing btrfs layout, looks like
18:02:22 * adamw finds the criterion
18:03:00 <roshi> I like btrfs just because I like butter, and it sounds like a wonder filesystem full of butter - does that mean there's something wrong with me?
18:03:14 <adamw> beta - "When using the custom partitioning flow, the installer must be able to:
18:03:14 <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 "
18:03:23 <halfline> kparal: working on a rhel 7.2 issue at the moment but fixing the theme is on my radar
18:03:38 <adamw> roshi: for a long time, btrfs functionality in the installer was hidden - you had to pass a kernel param to turn it on
18:03:48 <adamw> roshi: for quite a long time, that param was 'icantbelieveitsnotbtr'
18:03:55 <adamw> (or something like that)
18:04:00 * roshi is so very happy right now
18:04:54 <roshi> looks like a clear +1 to me
18:04:56 <linuxmodder> re: btrfs bug  seems to meet  block params  seems to be  derping on an existing layout
18:05:07 <linuxmodder> +1 here too
18:05:08 <adamw> roshi: https://github.com/rhinstaller/anaconda/commit/30e96b4857422948d1586c6ed69e5f8f67960f05
18:05:14 <adamw> +1
18:05:54 <linuxmodder> lordy  13  was SOO long ago
18:06:54 <roshi> proposed #agreed - 1266673 - AcceptedBlocker Final - This bug is a clear violation of the following Beta criterion: "...the installer must be able to: 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 pa
18:07:00 <roshi> rtitions..."
18:07:26 <adamw> cut it down a bit
18:08:17 <roshi> proposed #agreed - 1266673 - AcceptedBlocker Final - This bug is a clear violation of the following Beta criterion: "...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..."
18:08:29 <garretraziel> ack
18:08:31 <linuxmodder> ack
18:09:16 <roshi> #agreed - 1266673 - AcceptedBlocker Final - This bug is a clear violation of the following Beta criterion: "...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..."
18:09:21 <roshi> #topic (1263988) livecd-iso-to-disk doesn't create bootable usb drive
18:09:24 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263988
18:09:26 <roshi> #info Proposed Blocker, syslinux, NEW
18:10:21 <adamw> i suspect this is the same as the luc one
18:10:25 <adamw> so we should probably do the same thing
18:10:32 <linuxmodder> -1  if  nto efi  the  --reset-mbr is not needed and if it is  efi  he is missing  --efi
18:10:35 <roshi> yeah
18:10:57 <roshi> except luc worked with 64 bit, just not 32, right?
18:11:23 <linuxmodder> have the  reporter  give  results  WITH  --efi  or   without  --reset-mbr if using  bios
18:11:30 <linuxmodder> roshi,  correct
18:11:54 <linuxmodder> Southern_Gentlem, and I use  lcd-i-t-d regualtrly
18:11:57 <roshi> looks like kparal just copypasta'd his comments between those two bugs :p
18:12:02 <linuxmodder> er,regularly
18:12:13 <kparal> linuxmodder: what? --reset-mbr should make sure it works on bios systems
18:12:21 <kparal> without it, it's quite likely it won't work
18:12:34 <linuxmodder> if had no issues without on bios
18:12:41 <linuxmodder> ive*
18:13:00 <Southern_Gentlem> kparal,  me things the young one has had his coffee today
18:13:15 <linuxmodder> not a coffee drinker lol
18:13:16 <kparal> in comment 0 I believe Lukas is talking about BIOS system
18:13:16 <Southern_Gentlem> i always use --reset-mbr
18:13:44 <adamw> --reset-mbr is usually a good idea and the docs recommend it.
18:14:17 <cmurf> pretty sure litd won’t proceed without —reset-mbr if there isn’t already code in LBA 0, even on UEFI. It’s a confusing requirement.
18:14:21 <Southern_Gentlem> and that resets the mbr on the usbkey not the resulting install from said key IIRC
18:14:23 <kparal> I'm quite certain this whole bug is about bios systems
18:14:47 <kparal> I remember testing it with Lukas
18:15:37 <adamw> efi systems boot via grub.
18:15:47 <adamw> so yes, it seems logical, if we're blaming syslinux, that it will only affect BIOS.
18:16:20 <kparal> so, to clear the confusion, we're talking about bios systems here
18:16:45 <cmurf> i agree with c7
18:16:46 <kparal> and since we punted the previous usb bug, we should probably punt this one as well. unless our opinion changed in the mentime
18:17:26 <linuxmodder> using luc as a  possible  dump im +1  punting
18:18:01 <roshi> yeah +1 punt
18:18:38 <roshi> proposed #agreed - 1263988 - Punt Final - We'd like to find out more regarding this and other usb writing bugs. Postponing blocker decision until then.
18:18:43 <garretraziel> ack
18:18:52 <linuxmodder> ack
18:18:58 <adamw> ack
18:19:37 <kparal> ack
18:20:32 <roshi> #agreed - 1263988 - Punt Final - We'd like to find out more regarding this and other usb writing bugs. Postponing blocker decision until then.
18:20:43 <roshi> #topic (1263208) it's not possible to log in again shortly after log out (20 seconds)
18:20:46 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1263208
18:20:48 <roshi> #info Proposed Blocker, systemd, NEW
18:21:01 <kparal> I almost filed a duplicate today
18:21:16 <cmurf> I’ve seen this also
18:21:17 <linuxmodder> dups abound
18:21:23 <kparal> I still need to test the proposed fix
18:22:24 <cmurf> it could be documented and fixed with an update
18:23:07 <roshi> -1 blocker +1 FE
18:23:22 <cmurf> 20 seconds is a long time, I might be convinced of a user’s exasperation and doing a hard reset, but my inclination is +1 FE and not blocking
18:23:40 <adamw> with kparal's note I'm willing to be +1 to this
18:23:40 <kparal> I'm more concerned about the security issue than this one itself, but I couldn't reproduce it easily
18:23:53 <adamw> even if it's not easily reproducible, it seems worrying
18:24:03 <kparal> I have managed to hit it at least 4 times
18:24:12 <kparal> when I started recording it, it went awat
18:24:16 <kparal> heisenbug
18:24:19 <adamw> hehe
18:24:31 <roshi> lol
18:24:45 <linuxmodder> +1 fe
18:24:51 <kparal> please note that it's not certain that the security issue is related to this or will be fixed by this
18:24:55 <kparal> but I wanted to mention it
18:25:04 <cmurf> +1 FE  0 block
18:25:11 <kparal> I certainly haven't seen it before
18:26:07 <adamw> let's say +0.5
18:26:16 <roshi> hrm
18:26:39 <roshi> 20 seconds isn't that long, but the potential for being able to log in as someone is a tad worrying
18:26:53 <roshi> if something like this were happening with ssh, I might be worried
18:27:13 * linuxmodder thinks autologin on anything other than live media is  bad idea
18:27:17 <kparal> I wouldn't expect ssh to be affected
18:27:20 <roshi> this vuln is right smack in the middle of meat widget land though
18:27:38 <kparal> but who knows
18:27:47 <roshi> someone has to physically be at your machine to exploit this
18:27:59 <roshi> we can punt to the security team and see what they think?
18:28:07 * roshi doesn't see it as a big issue though
18:28:11 <roshi> even from a security standpoint
18:28:16 <kparal> first I'd have to be able to at least gather some logs
18:28:48 <kparal> I can try again tomorrow, I should get lucky again, it was not a one-time thing
18:29:01 <roshi> punt for more log gathering?
18:29:08 <roshi> TC1 updated, and you see this, right?
18:29:21 <kparal> let's vote on the core issue, and I can repropose if I can demonstrate the security issue
18:29:21 <roshi> I have some backups and stuff to do, but then I can test this as well
18:29:35 <roshi> core issue: -1 blocker, +1 FE
18:30:36 <linuxmodder> core issue  +1 fe
18:30:37 <kparal> I'd personally be +0.5 on the core issue, but I'm fine with just FE
18:31:07 <roshi> adamw: ?
18:31:28 <roshi> cmurf: ?
18:31:37 <cmurf> ?
18:31:37 <kparal> one issue I forgot to mention - mouse cursor disappears in VM after logout
18:31:44 <adamw> that's filed already i think?
18:31:47 <kparal> haven't tested bare machine yet
18:31:58 * adamw a bit undecided on the core bug
18:32:08 <kparal> well this issue is recurring, but this time it happens only after log out, not after reboot
18:32:19 <cmurf> what’s the question?
18:32:21 <kparal> (speaking of mouse cursor)
18:32:29 <kparal> but sorry for going off-topic
18:32:40 <adamw> cmurf: what's our vote on the straightforward 'can't log in for 20 seconds' part of the bug, disregarding the possible security part
18:32:54 <cmurf> I’m still +1FE 0 block
18:33:13 <adamw> i guess i can be -1, but it's a crappy bug.
18:33:35 <cmurf> well it’s gonna get fixed in an update yes?
18:34:10 <kparal> hopefully
18:34:21 <kparal> nothing is certain if we don't block on it :)
18:34:21 <roshi> proposed #agreed - 1263208 - RejectedBlocker AcceptedFreezeException Final - While this bug is an annoyance, it's not severe enough to say logout/login is "not working." This can be fixed in an update or we'd consider a fix for this during freeze.
18:34:40 <kparal> ack
18:34:41 <linuxmodder> ack
18:34:43 <adamw> ack
18:34:43 <garretraziel> ack
18:35:59 <roshi> #agreed - 1263208 - RejectedBlocker AcceptedFreezeException Final - While this bug is an annoyance, it's not severe enough to say logout/login is "not working." This can be fixed in an update or we'd consider a fix for this during freeze.
18:36:09 <roshi> that's all of them
18:36:13 <roshi> no proposed FE's
18:36:17 <cmurf> I would change my vote if the security team finds that there is a vuln or exploit here.
18:36:23 <roshi> same here
18:36:40 <linuxmodder> +1 on security sig  finding issue
18:36:42 <cmurf> So maybe we need to ping them on this bug
18:36:52 <roshi> but it seems like someone needs physical access for a 20 second window
18:37:04 <roshi> the setup would have to be perfect - at which point, I think you have bigger issues
18:37:17 <adamw> roshi: which isn't particularly unlikely in an office, though the usual thing to do i guess is lock screen, not log out.
18:37:29 <cmurf> yeah well coffee shop, log out and walk away for 1 minute, oh nice evil maid!
18:37:33 <linuxmodder> if the attacker is  pre-mediated and  /or  able to phys acc  you DO have  bigger  issues
18:37:34 <kparal> roshi: I actually don't know how long the attack window is. I just know it worked after _waiting 20 seconds_
18:38:04 <roshi> yeah, exactly
18:38:10 <cmurf> it’s really unlikely, someone would have to know about this particular problem and know it’s on this particular computer etc
18:38:35 <roshi> you have to log out, then try to log in within 20 seconds, lose your mind at a *20* second lag and walk away in a huff
18:38:42 <roshi> then someone has to come click your name
18:38:54 <adamw> do we actually know any of those things?
18:39:06 <roshi> after 20 seconds the login works
18:39:08 <adamw> i.e. do we know there have to be failed login attempts?
18:39:13 <adamw> anyway
18:39:18 <adamw> let's not play Security Spitball
18:39:23 <adamw> we've got 20 minutes left on the time window
18:39:24 <roshi> that's how it seemed to me
18:39:30 <kparal> that's the only way I reproduced it. can't say it can't be done otherwise
18:39:33 <roshi> and we're done with the blockers
18:39:39 <kparal> \o/
18:39:45 <cmurf> 20 minutes early?
18:39:47 <cmurf> never
18:39:48 <cmurf> ever
18:39:51 <cmurf> EVER
18:39:54 <roshi> there's nothing left to do, unless people want to go through accepted blockers - but I think we could hold off on that today
18:40:04 <roshi> and go test stuff
18:40:16 <kparal> find more blockers
18:40:17 <roshi> #topic Open Floor
18:40:22 <roshi> anyone have anything else?
18:40:57 <kparal> not here
18:41:05 <linuxmodder> nor here
18:41:34 <adamw> any FEs?
18:41:36 * roshi sets the fuse...
18:41:39 <roshi> none proposed
18:41:55 <adamw> ok then
18:42:00 <roshi> 3...
18:42:10 <roshi> thanks for coming folks :)
18:43:46 <kparal> thanks
18:44:20 <roshi> 2,,,
18:44:23 <adamw> thanks for running roshi
18:45:19 <roshi> np
18:45:25 * roshi is a meeting jockey...
18:45:28 <roshi> 1...
18:45:35 <roshi> thanks for secretarializing :)
18:45:40 <roshi> #endmeeting