16:02:29 <roshi> #startmeeting F21-blocker-review
16:02:29 <zodbot> Meeting started Wed Nov  5 16:02:29 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:29 <roshi> #meetingname F21-blocker-review
16:02:29 <zodbot> The meeting name has been set to 'f21-blocker-review'
16:02:29 <roshi> #topic Roll Call
16:02:38 <roshi> who's around for some blocker reviews?
16:03:09 * kparal is here
16:03:14 * satellit listening
16:03:18 <kparal> let's wait an hour and see who shows up :)
16:03:29 <roshi> tflink is here, just not at his desk yet
16:03:36 <roshi> from getting coffee
16:04:44 <roshi> I'm fine with giving people time - but last hour will split my time between this and cloud WG meeting
16:06:22 <kparal> pschindl should be late, but I don't know whether 16.00 UTC late, or 17.00 UTC late
16:08:07 <roshi> neither do I
16:09:30 <roshi> I don't remember what we did last year with the time change...
16:12:38 <roshi> adamw danofsatx ?
16:12:55 * pschindl is here. Hi all
16:13:02 <danofsatx> yeah, yeah, yeah.....I'm here
16:13:06 <roshi> sweet
16:13:16 <roshi> well, here's some boilerplate
16:13:24 <roshi> #topic Introduction
16:13:25 <roshi> Why are we here?
16:13:25 <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:13:28 <roshi> #info We'll be following the process outlined at:
16:13:31 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:13:33 <roshi> #info The bugs up for review today are available at:
16:13:36 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:13:38 <roshi> #info The criteria for release blocking bugs can be found at:
16:13:41 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
16:13:44 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
16:13:47 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria
16:13:50 <roshi> first of 16
16:13:53 <roshi> #topic (1148618) Saved initramfs contains stage2 image
16:13:55 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1148618
16:13:57 <roshi> #info Proposed Blocker, anaconda, MODIFIED
16:15:32 * roshi looks for potential criteria
16:17:18 <roshi> I could see this as an FE
16:17:31 <roshi> -1 blocker though, since I don't see a criteria this blocks
16:19:28 * kparal is back from a shower
16:20:23 <kparal> what is initramfs-saved.cpio.gz?
16:20:47 <tflink> I think it's a second copy of the initramfs
16:20:57 * roshi isn't entirely sure
16:21:01 <kparal> inside netinst?
16:21:08 <tflink> that's what it sounds like to me
16:21:40 <kparal> -1/+1
16:22:07 <tflink> -1/+1 if it's early enough
16:22:22 <kparal> even though this is quite bad, if 1GB is not enough for text mode installation
16:22:48 <roshi> proposed #agreed - 1148618 - RejectedBlocker AcceptedFreezeException - This bug doesn't clearly violate any criteria but would be good to pull in as an FE if it doesn't get pulled before freeze.
16:22:59 <kparal> ack
16:23:31 <kparal> and the million dollar question, who's secretarializing?
16:23:36 <pschindl> ack
16:23:57 <roshi> that was my next question :)
16:24:01 <kparal> pschindl: I think either you or me :)
16:24:24 <tflink> ack
16:24:26 <danofsatx> ack
16:24:35 <roshi> #agreed - 1148618 - RejectedBlocker AcceptedFreezeException - This bug doesn't clearly violate any criteria but would be good to pull in as an FE if it doesn't get pulled before freeze.
16:24:54 <roshi> #topic (1158533) LVMError: lvactivate failed for home: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/sda1$|","r|/sda2$|","r|/sda3$|","r|/sda$|","r|/sdc1$|","r|/sdc2$|","r|/sdc$|"] }  fedora/home failed
16:24:58 <kparal> pschindl is playing dead, that's quite clever
16:24:59 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1158533
16:25:02 <roshi> #info Proposed Blocker, anaconda, NEW
16:25:07 <roshi> haha
16:25:13 <adamw> oop, sorry. i'm around for a bit but will have to duck out before the end probably
16:25:25 <kparal> adamw: welcome
16:25:43 * pschindl isn't available at the moment. Try to call him later.
16:25:44 <satellit> seems to occur if 2 USB HD with fedora on them plus ssd HD in PC for me
16:26:04 * satellit easy fic unplug one drive
16:26:08 <satellit> fix*
16:26:23 <kparal> pschindl: ok then, I'll do it. damn answer machines
16:26:56 <not_pschindl> :) Hey I see pschindl. He is coming back!
16:27:25 * pschindl ah, did I miss something?
16:28:12 <kparal> after watching https://pschindl.fedorapeople.org/bug1158533.ogv , I'm +1
16:28:25 <roshi> I think he just upped the ante on evading secretarializing
16:28:42 <kparal> the reason is it's quite usual to go back to partitioning spoke
16:28:48 <pschindl> Yeah that video is great. I'm waiting for invitation to oscars :)
16:29:22 <adamw> dlehman was pretty dismissive of at least satellit's case of this, not sure what he thinks about the multi-trip reproducer
16:29:23 <kparal> especially because anaconda provides no useful information about the final layout of the installation. so people are tempted to go back to see whether it is displayed somewhere. and then they just receive the same 'reclaim' dialog again
16:30:00 <kparal> and I myself have changed my mine about destination a few times, realizing I have selected too many/too few disks
16:30:04 <pschindl> I think so too. It happens to me a lot to change my mind. Or I sometimes forget to do something there and I have to visit it again.
16:30:06 <kparal> *mind
16:31:20 <roshi> +1 from me as well
16:31:43 <pschindl> +1
16:32:05 <danofsatx> +1
16:32:47 <adamw> sure, +1 for now, but it'd be good to have anaconda input
16:32:50 <tflink> +1
16:34:10 <roshi> proposed #agreed - 1158533 - AcceptedBlocker - This bug violates the final criteria "The installer must be able to complete an installation using all supported interfaces."
16:34:25 <kparal> ack
16:34:26 <pschindl> ack
16:35:05 <tflink> not sure about that criterion
16:35:27 <roshi> is there a criteria for "have to be able to reset already set things without fear of machine death" criteria?
16:35:38 <kparal> if not, we should create one
16:36:02 <adamw> not exactly, but there's something about errors somewhere.
16:36:29 <kparal> it has to reject invalid operations, but this is not exactly it
16:38:07 <adamw> I'd say it's just a conditional violation of " Complete an installation using any combination of disk configuration options it allows the user to select " in the case you change your mind
16:38:34 <kparal> sounds good
16:38:47 <roshi> yeah, works for me
16:38:54 * roshi patches
16:39:31 <roshi> proposed #agreed - 1158533 - AcceptedBlocker - This bug violates the final criteria "Complete an installation using any combination of disk configuration options it allows the user to select..."
16:40:23 <kparal> ack
16:41:12 <adamw> it's a beta criterion, not final
16:41:26 <roshi> proposed #agreed - 1158533 - AcceptedBlocker - This bug violates the beta criteria "Complete an installation using any combination of disk configuration options it allows the user to select..."
16:41:43 <adamw> criterion is the singular. ;) but ack
16:42:06 <roshi> true
16:42:23 <kparal> ack
16:42:52 <kparal> I can fine tune and add my own mistakes in the bug report
16:43:23 <pschindl> ack
16:43:27 <roshi> #agreed - 1158533 - AcceptedBlocker - This bug violates the beta criteria "Complete an installation using any combination of disk configuration options it allows the user to select..."
16:44:21 <roshi> #topic (1160041) anaconda crashed with OSError: (Errno 4) interrupted system call
16:44:24 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1160041
16:44:27 <roshi> #info Proposed Blocker, anaconda, MODIFIED
16:46:25 <kparal> -1, ask for proper justification and re-propose if suitable
16:46:49 <roshi> yeah
16:46:59 <kparal> there is zero information how to hit it and how often it happens. I haven't seen it
16:47:03 <roshi> I also what to know what an "old, slow machine" is
16:47:26 <roshi> -1 and repropose if there's details
16:49:00 <pschindl> -1
16:49:40 <roshi> proposed #agreed - 1160041 - RejectedBlocker - There isn't enough information as to how repeatable or common this bug is. Please provide more information and repropose.
16:49:55 <kparal> ack
16:50:02 <pschindl> ack
16:50:54 <adamw> ack
16:50:55 <roshi> #agreed - 1160041 - RejectedBlocker - There isn't enough information as to how repeatable or common this bug is. Please provide more information and repropose.
16:51:07 <roshi> #topic (1098735) apper: PackageKit-hif (hawkey) backend missing comps group support
16:51:10 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1098735
16:51:13 <roshi> #info Proposed Blocker, apper, NEW
16:51:34 <adamw> doesn't really violate the criteria as written, not sure if we think this indicates a lack in the criteria...
16:51:51 <adamw> as i read it the remaining issue is some kind of missing groups support in apper
16:52:58 <danofsatx> -1 blocker, +1 FE - but it's not going to make it. The code isn't written yet.
16:54:19 <kparal> I haven't read the whole bug report yet, but isn't hawkey non-default for F21?
16:57:50 <adamw> <heliocastro> adamw: ETA, monday
16:58:00 <adamw> kparal: i think kde may have switched already...
16:58:05 <adamw> rdieter: got any scoop for us on this one?
16:58:39 <rdieter> adamw: nothing more than heliocastro reports
16:59:13 <kparal> rdieter: do you use hawkey as default?
16:59:20 <kparal> for F21
16:59:55 <rdieter> kparal: kinda have to, that's the only backend available now
17:01:48 <kparal> what about yum backend?
17:02:23 <rdieter> kparal: gone
17:03:33 <kparal> rdieter: can you please summarize what does and what doesn't work, and how often it crashes if ever?
17:04:14 <rdieter> kparal: my understanding is ...
17:04:33 <rdieter> there are (essentially) no crashes, installing updates works
17:05:10 <rdieter> primary missing feature now is using apper to browse/install new software
17:05:21 <roshi> brb
17:05:23 <roshi> coffee
17:05:29 <danofsatx> oh, awesome - I wasn't aware heliocastro was this far ahead
17:05:54 <rdieter> danofsatx: he hasn't done anything yet, ^^ is basically the status quo
17:06:08 <rdieter> he's working on the "missing feature" part only
17:06:20 <adamw> i'd probably be -1 blocker / +1 FE from a QA perspective, in a sense it would suck to ship with a release blocking desktop's graphical package installer kinda busted, but then we did it for GNOME In f19 and this isn't really a QA but a development planning issue
17:06:31 <kparal> rdieter: is there a real chance of having this ready in ~ two weeks?
17:06:51 <rdieter> kparal: heliocastro's estimate was that he'd have something testable by next monday
17:07:07 <rdieter> (ie, he'll be doing most of the work over the weekend)
17:07:29 <kparal> if it doesn't work, we can always pre-install gnome Software for KDE spin :P
17:07:41 <kparal> or something like yumex?
17:08:21 <rdieter> updating works (mostly), so having a later update that fixes it is an option too
17:08:43 <rdieter> last I checked, gnome-software didn't work (on kde)
17:09:10 <kparal> it sucks to have no working gui for searching for apps, but I think it's very similar to what we had in past - packagekit-gui wasn't really usable either
17:09:57 <kparal> and there's a difference between a bug and not-implemented functionality
17:10:11 <kparal> so it's a bit harder to justify a blocker here, I think
17:10:50 * kparal 's sense for perfection suffers
17:11:08 <kparal> -1/+1 is probably more reasonable here
17:11:22 <adamw> kparal: this is in a sort of grey area in between the two, but it doesn't really feel like the sort of thing we have a blocker bug process for
17:11:52 <kparal> yeah, it's a bit fuzzy area
17:13:10 <rdieter> if there weren't prospects of getting it fixed soon, i'd holler more loudly in fesco's direction, something about incomplete features...
17:15:40 <roshi> #chair adamw kparal danofsatx
17:15:40 <zodbot> Current chairs: adamw danofsatx kparal roshi
17:15:55 <kparal> roshi: pschindl: votes?
17:16:14 <roshi> -1/+1 seems reasonable to me
17:16:21 <pschindl> -1/+1
17:17:15 <roshi> proposed #agreed - 1098735 - RejectedBlocker AcceptedFreezeException - This bug isn't a clear violation of the criteria but a fix would be considered during freeze.
17:17:25 <pschindl> ack
17:17:26 <kparal> ack
17:18:01 <roshi> #agreed - 1098735 - RejectedBlocker AcceptedFreezeException - This bug isn't a clear violation of the criteria but a fix would be considered during freeze.
17:18:12 <roshi> #topic (1160499) Missing high contrast icon
17:18:12 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1160499
17:18:13 <roshi> #info Proposed Blocker, fedora-logos, NEW
17:18:51 <adamw> this is in the new workstation criteria, i think.
17:19:41 <adamw> because polish criteria worked so well last time!
17:19:45 <adamw> anyway, by the numbers I'm +1
17:21:14 <kparal> if I consider that we do not block on KDE users being able to search for software, but block on a missing high-contrast icon, I wonder...
17:21:50 <kparal> if polish criteria should really block. we usually have more pressing problems than this
17:22:23 <adamw> well, it's the requirements the Workstation folks want for their product, if their requirements turn out to be unrealistic we can revisit them, which is what happened with the old polish criteria
17:22:42 <adamw> turned out when the last blocker was 'Obscure App Everyone Forgot About Has A Fuzzy Icon', amazingly, no-one wanted to slip for a week
17:22:57 <kparal> ok. +1 per criteria. I hope we don't slip because of this
17:23:03 <adamw> but they said they were going to do a proper job of checking and fixing things this time, so hey
17:23:37 <roshi> +1 per the criteria
17:23:45 <pschindl> +1
17:25:22 <roshi> proposed #agreed - 1160499 - AcceptedBlocker - This bug is a clear violation of the Final criterion: All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy.
17:26:24 <pschindl> ack
17:27:17 <kparal> ack
17:27:37 <roshi> #agreed - 1160499 - AcceptedBlocker - This bug is a clear violation of the Final criterion: All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy.
17:27:44 <roshi> #topic (1159292) Machine automatically shutdown during upgrade in less than 15 minutes
17:27:47 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1159292
17:27:50 <roshi> #info Proposed Blocker, fedup-dracut, ASSIGNED
17:28:48 <kparal> +1, should be already fixed
17:28:52 <satellit_e> worked for me yesterday with bios boot f20>21
17:28:56 <roshi> +1 and works for me
17:29:08 <pschindl> +1
17:29:16 <kparal> so close right away?
17:29:41 <kparal> everything is pushed
17:29:55 <kparal> and multiple people verified
17:30:01 <satellit_e> FYI http://wiki.sugarlabs.org/go/Fedora_21#fedup_Updating_f20_desktop_to_f21_workstation
17:30:32 <kparal> adamw: any thought whether to close this or do something else?
17:30:56 <roshi> I say just close it, already fixed
17:32:21 <kparal> alright
17:32:25 <kparal> so let's just move on
17:32:37 <roshi> works for me
17:32:47 <roshi> #topic (1158442) Gnome-initial-setup window doesn't fit to visible with small resolution
17:32:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1158442
17:32:52 <roshi> #info Proposed Blocker, gnome-initial-setup, NEW
17:34:19 <kparal> well, this is going to be fun
17:34:38 <kparal> the question is how low we want to go when it comes to resolution
17:35:07 <kparal> usually safe graphics mode is 1024x768, I don't understand why we receive 800x600 on this computer
17:35:08 <pschindl> This happens to me with nomodeset on UEFI boot
17:35:17 <kparal> it's fairly new, amd graphics
17:35:28 <kparal> pschindl: just with UEFI?
17:35:31 <pschindl> yes
17:35:40 <roshi> I've had issues on tiny (netbooks) before - but low res is best effort support, right?
17:35:57 <kparal> I remember adamw saying something like that
17:36:01 <pschindl> I tested non-uefi boot later and it has 1024x768 or something like that
17:36:06 <kparal> we still need to define where the border is
17:36:20 <kparal> pschindl: and with 1024 it works correctly? is not cropped?
17:36:28 <pschindl> Yes it works.
17:36:42 <kparal> my feeling is that 800x600 is too low to block release on
17:37:18 <pschindl> Also on virtual machines with quite low resolution it works fine. So it has to be smaller than 1024x768.
17:37:30 <kparal> that doesn't mean I'm not unhappy about gnome approach to have non-resizable forms
17:37:52 <kparal> too many negatives :)
17:38:06 <kparal> czenglish
17:38:23 * satellit or yoga pro 2   f21 is very timy
17:38:33 * satellit tiny
17:38:42 <kparal> -1/+1
17:38:49 <roshi> I'm -1 on this
17:39:24 <pschindl> If nobody else saw something like this on other machine I'm -1. But if it happens for more machines with uefi and nomodeset. Than I'd be +1.
17:39:30 <danofsatx> this one is a toughy. I'm +/-1
17:39:42 <danofsatx> so, +0
17:39:55 <adamw> the point for this is hidpi mode
17:39:59 <adamw> which works by scaling
17:40:28 <adamw> so if your real resolution is, say, 2400x1800 and you get a scaling factor of 3, you wind up with effectively 800x600 of 'space' for the app to render bits in
17:41:08 <kparal> does it happen in real life? what would be effective 800x600 space good for?
17:41:08 <adamw> it does seem slightly odd, though, as i didn't think hidpi was meant to kick in in cases like that - it might be worth talking to the GTK+ folks about
17:41:30 <adamw> oh, sorry, i thought this was the anaconda bug (though probably it affects this case too)
17:41:39 <adamw> g-i-s doesn't fit in 1024x768 in a VM for me, fwiw
17:41:44 <adamw> bits of it are off the bottom
17:42:04 <kparal> fortunately the continue buttons are on top :)
17:42:26 * adamw has to run, might counsel a punt + talk to GTK+ about hidpi for 'low-res' issues
17:42:36 <roshi> that works for me
17:43:07 <roshi> votes on punt and get GTK+ feedback?
17:44:47 <kparal> I'm fine with that, I'm just interested who's going to talk to GTK guys
17:45:20 * roshi knows no GTK guys (that he knows of, anyways)
17:46:47 <kparal> pschindl: yet again looking for volunteers
17:47:35 <pschindl> wait a moment. I have to switch to wifi, maybe my conection will get lost forever.
17:47:38 <pschindl> :)
17:47:45 <roshi> lol
17:47:47 <pschindl> OK, I volunteer
17:47:52 <kparal> sigh. let's just punt and scream loudly in the bugzilla
17:48:07 <kparal> rmatos is in CC, he could know
17:48:15 <pschindl> ok
17:48:41 <roshi> proposed #agreed - 1158442 - Punt - We're going to delay a decision on this until we can get more feedback from the GTK+ folks.
17:48:57 <kparal> pschindl: please update this bug and ask Rui for relevant info, thanks
17:49:14 <pschindl> ack
17:49:48 <kparal> ack
17:50:06 <danofsatx> ack thpppt
17:50:45 <roshi> #agreed - 1158442 - Punt - We're going to delay a decision on this until we can get more feedback from the GTK+ folks.
17:51:04 <roshi> #topic (1151429) preedit is visible in gnome-lock-screen for all ibus-m17n input methods
17:51:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1151429
17:51:09 <roshi> #info Proposed Blocker, gnome-shell, NEW
17:53:45 <roshi> +1 for this, but I haven't seen this (or tried to reproduce it)
17:54:33 <kparal> roshi: probably because you don't type in indian languages
17:54:42 <roshi> yeah
17:54:56 <kparal> I'd be +1 in general, but it's quite peculiar that the same bug exists in F20
17:55:18 <kparal> that somewhat diminishes the blocker-ness of this, at least from my POV
17:55:36 <kparal> it seems that nobody cared for a long time
17:56:23 <kparal> I'm torn on this one
17:58:05 <kparal> well, +1. "security"
17:58:13 <kparal> pschindl: thoughts?
17:59:00 <kparal> OTOH, this can be solved with an update
17:59:11 <kparal> so it does not violate the criterion directly
17:59:26 <kparal> "which cannot be satisfactorily resolved by a package update (e.g. issues during installation)."
17:59:43 <kparal> and it's not a big deal on Live
18:00:28 <roshi> true
18:01:02 <kparal> we can also punt this and hope it goes away!
18:01:02 <roshi> haha
18:01:15 <roshi> anyone else got votes?
18:01:15 <kparal> pschindl: don't pretend you're still not here
18:01:26 <pschindl> kparal: I'm thinking
18:01:40 <kparal> oh, apologies
18:01:45 <kparal> please continue
18:01:46 <kparal> ;)
18:02:20 <kparal> let's punt and wait for bigger attendance, I'd say
18:03:13 <pschindl> +1 for punt. But I'm more +1 for blocker. Because it's security problem.
18:05:19 <kparal> roshi: let's punt
18:05:37 <roshi> works for me
18:05:38 <kparal> and if pschindl doesn't come back, we're probably too few to continue
18:06:49 <kparal> I'll ask Mike Fabian how commonly is the input method used
18:06:53 <roshi> proposed #agreed - 1151429 - Punt - We're going to punt on this and wait for more information as this bug has been around since F20.
18:07:07 <pschindl> ack
18:07:43 <danofsatx> ack
18:07:51 <kparal> ack
18:08:05 <roshi> #agreed - 1151429 - Punt - We're going to punt on this and wait for more information as this bug has been around since F20.
18:08:27 <roshi> so, keep going
18:09:00 <roshi> or do we not have people?
18:10:01 <kparal> pschindl: are you staying?
18:11:28 <pschindl> I'm still here. But I have to cook. So I won't be 100% focused on blockers.
18:11:50 <kparal> in that case we seem to not have enough people
18:11:57 * tflink can start paying more attention
18:12:28 <kparal> 50% of pschindl and 50% of tflink could be enough :-)
18:12:37 <roshi> haha
18:12:44 <roshi> well, we can try one more either way
18:12:58 <roshi> #topic (1153676) All GPG-related operations are broken in seahorse
18:13:01 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1153676
18:13:03 <roshi> #info Proposed Blocker, gnupg2, NEW
18:14:41 <pschindl> +1. If they consider this feature to be basic functionality.
18:16:44 <roshi> yeah
18:16:48 <roshi> seems cut and dry to me
18:16:51 <oddshocks> I say +1, considering that's the default GPG frontend, and like pschindl said, GPG is basic stuff
18:17:06 <roshi> yeah
18:17:32 <kparal> "fixing this on the GNOME side is not trivial and sans an unexpected volunteer, it's unlikely we'll be able to do so in the next couple of months."
18:17:45 <kparal> but the same person then proposed it as a blocker. I'm a bit confused
18:17:51 <oddshocks> hmm.
18:18:09 <roshi> proposed #agreed - 1153676 - AcceptedBlocker - This bug is a clear violation of the Basic functioanality final criterion.
18:18:31 * kparal is not sure about that yet
18:18:37 <tflink> +1
18:18:41 <jreznik> yeah, if it's said, target is f22 and proposed as f21 blocker?
18:19:01 <pschindl> Maybe it's the case when it takes months just until the moment it is called to be blocker. Then it is fixed in hours :)
18:19:06 <pschindl> ack
18:19:53 <kparal> I'll ping mcantanzero. he's online
18:20:21 <oddshocks> cool, yeah this seems important to me
18:21:07 <kparal> he's coming
18:21:08 <danofsatx> jreznik: more clarification - is this targeted at F22?
18:21:47 <kparal> mcatanzaro: hi. I'm a bit confused. you're proposing this as a blocker, yet you say "fixing this on the GNOME side is not trivial and sans an unexpected volunteer, it's unlikely we'll be able to do so in the next couple of months."
18:21:51 <jreznik> danofsatx: it's in bug but it's actually in the way fix it or remove gpg
18:22:08 <jreznik> so one resolution could be just disabling gpg
18:22:27 <kparal> mcatanzaro: what is the proposed solution?
18:22:42 <jreznik> and in that case I'm probably +1, as basic functionality is broken and it can be disabled (so it will work, just will miss gpg)
18:23:36 <kparal> mclasen just linked http://pkgs.fedoraproject.org/cgit/seahorse.git/commit/?id=32a5dd3ad58389f9573edea28b66ceb26424db28
18:24:03 <kparal> it seems they forced seahorse to use gnupg 1 instead of gnupg 2
18:24:51 <mcatanzaro> kparal: I haven't tested that path yet, but if it works then no other changes should be needed for the time being.
18:25:03 <mcatanzaro> /s/path/patch
18:25:50 <kparal> mcatanzaro: if it doesn't work, is it realistic to strip seahorse of gnupg functionality in ~ two weeks?
18:26:16 <kparal> or would you rather leave it broken?
18:26:25 <mcatanzaro> kparal: Yes. That would be unfortunate, but better than leaving it broken.
18:26:39 <kparal> ok. if that's doable, I'm +1 blocker
18:26:50 <mcatanzaro> We'd much rather gnupg just hold off on their breaking changes until F22, of course.
18:26:54 <jreznik> yep, +1 blocker
18:27:16 <mcatanzaro> But I bet the gpg2 -> gpg1 patch is sufficient.
18:27:27 <kparal> mcatanzaro: thanks for info
18:27:27 <roshi> so, acks? or should I change it up
18:27:44 <kparal> roshi: patch spelling
18:28:08 <roshi> bah - this is open source wii donte nead no speling
18:28:18 <kparal> ah right
18:28:20 <kparal> ack
18:28:27 <roshi> proposed #agreed - 1153676 - AcceptedBlocker - This bug is a clear violation of the Basic functionality final criterion.
18:28:30 <roshi> there
18:28:39 <kparal> that's a good excuse for my typos, actually
18:28:44 <roshi> lol
18:28:49 <kparal> ack
18:28:51 <tflink> ack
18:29:00 <roshi> #agreed - 1153676 - AcceptedBlocker - This bug is a clear violation of the Basic functionality final criterion.
18:29:06 <danofsatx> ack
18:30:20 <roshi> #topic (964828) EFI: Existing Fedora rendered unbootable after installing Fedora n+1, malformed grub.cfg entries
18:30:23 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=964828
18:30:25 <roshi> #info Proposed Blocker, grub2, NEW
18:30:40 <danofsatx> this sounds like one of my old ones
18:30:43 * danofsatx reads
18:33:15 <roshi> looks like it's...fixed?
18:33:17 <danofsatx> ok, different.
18:33:24 <danofsatx> but it does look fixed.
18:33:35 * danofsatx hasn't tested...is cmurf around?
18:33:54 <kparal> dual linux booting was never supported properly
18:34:01 <kparal> as sad as it sounds
18:34:02 <roshi> yeah
18:34:07 <oddshocks> heh
18:34:19 <roshi> and that's a black hole of things to claim to support, imo
18:34:19 <danofsatx> I know, that's why my bug got tossed.
18:34:36 <danofsatx> but this is a grub error that should be fixed.
18:34:58 <danofsatx> (my bug was a uefi issue, caused by design)
18:34:59 <kparal> there are still avenues how to fix it - use UEFI to boot selected system, or chainload grub
18:35:15 <kparal> I have the latter at home and it works well
18:36:50 <roshi> so, votes?
18:37:05 <roshi> or is it fixed and we can close it?
18:37:24 <kparal> I guess I'm -1 at the moment. if we want to support this behavior, we need to first have the criterion created. and I guess it's going to be quite a debate
18:37:31 <tflink> -1/+0 if it's not already fixed
18:38:14 <roshi> same here
18:38:23 <roshi> -1
18:38:48 <oddshocks> -1 from me
18:39:07 <roshi> proposed #agreed - 964828 - RejectedBlocker - This doesn't violate any specific criteria.
18:39:31 * roshi debates putting something in it about criterion discussion - but that should be done on list
18:39:32 <tflink> ack
18:40:05 <kparal> I'll add some note
18:40:06 <kparal> ack
18:40:11 <roshi> ack
18:40:19 <roshi> #agreed - 964828 - RejectedBlocker - This doesn't violate any specific criteria.
18:40:32 <roshi> #topic (986731) Dual boot of uefi Windows 7 and Fedora 19 fails to boot Windows
18:40:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=986731
18:40:38 <roshi> #info Proposed Blocker, grub2, NEW
18:43:45 <danofsatx> +1
18:45:41 <roshi> +1 it's right in the criteria
18:45:47 <kparal> two EFS bug was present in F20, but should have been fixed
18:46:04 <oddshocks> +1
18:46:09 * kparal still reading
18:48:14 <pschindl> +1
18:48:25 <kparal> so, after reading all of that, it's very unclear who's actually talking about F21
18:48:34 <kparal> and a lot of people say it works for them
18:48:52 <roshi> yeah
18:48:57 <roshi> I htink it could use more testing
18:49:01 <roshi> think, even
18:49:10 <kparal> so I think we should just test it. we have it in installation matrices anyway
18:49:31 <roshi> punt and test?
18:49:37 * roshi will have to do a test install
18:49:53 <kparal> sounds good to me. we should try both 1 ESP and 2 ESP installation
18:50:28 <kparal> let's give #action to me and pschindl
18:50:36 <roshi> proposed #agreed - 986731 - Punt - This requires some more testing to confirm. Will rediscuss at next meeting.
18:50:58 <roshi> #action kparal to test Windows Dual boot
18:51:08 <roshi> #action pschindl to help kparal with testing dual boot
18:51:15 <kparal> that's better :)
18:51:16 <tflink> ack
18:51:19 <kparal> ack
18:51:19 <pschindl> ack
18:51:27 <roshi> #agreed - 986731 - Punt - This requires some more testing to confirm. Will rediscuss at next meeting.
18:51:35 <roshi> and, on a similar note
18:51:36 <roshi> #topic (1144657) UEFI Secure Boot failure to boot Windows, cannot load image
18:51:39 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1144657
18:51:42 <roshi> #info Proposed Blocker, grub2, NEW
18:53:14 <oddshocks> I didn't realize people left secure boot enabled or ever re-enabled it after installing Linux
18:53:44 <roshi> I don't have it enabled
18:53:50 <roshi> but that doesn't mean much :)
18:53:59 * nirik keeps it enabled here, always have.
18:54:11 <tflink> I keep it enabled on all my machines that support it
18:55:08 <tflink> it sounds like this also needs more testing
18:55:17 <oddshocks> TIL
18:55:38 <kparal> I can actually try right now with F20 and Win7
18:56:10 * nirik has no windows here at all. ;)
18:56:37 * kparal trying
18:57:12 <kparal> works
18:57:28 <roshi> so works for you no issues?
18:57:38 <kparal> so I'd say let's retest together with 986731
18:57:44 <kparal> roshi: yes, no issues
18:57:54 <roshi> that's good at least
18:58:00 <kparal> is there an easy way to verify that SB is on inside running Fedora?
18:58:57 <tflink> the easiest way I remember is booting a live install
18:59:36 <kparal> I'd expect kernel to write something to dmesg, but I see no 'secure' string
18:59:47 <kparal> I enabled it in UEFI, though
18:59:51 <kparal> so should be enabled
19:00:07 <roshi> one would think
19:00:40 <kparal> we'll test this with pschindl as well
19:00:53 <roshi> works for me
19:01:12 <tflink> sounds good
19:01:14 <roshi> proposed #agreed - 1144657 - Punt - This requires some more testing to confirm. Will rediscuss at next meeting.
19:01:22 <roshi> #action kparal to test Windows Dual boot
19:01:30 <roshi> #action pschindl to help kparal with testing dual boot
19:01:30 <danofsatx> when you boot a UEFI system, if secure boot is disabled, grub will tell you this.
19:01:41 <pschindl> ack
19:01:56 <kparal> danofsatx: that has been fixed, the message is gone. it was an error
19:01:57 <danofsatx> as it boots - you need to watch. It throws "Booting in insecure mode." up on the screen for 2-3 seconds.
19:02:17 <kparal> it should have never shown up there
19:02:33 <danofsatx> ok, maybe it's the bios doing it. I thought it was grub.
19:02:38 <kparal> and, my monitor is too slow to display that anyway
19:02:44 <kparal> danofsatx: it was shim
19:02:58 <tflink> ack
19:03:03 <kparal> ack
19:03:05 <roshi> #agreed - 1144657 - Punt - This requires some more testing to confirm. Will rediscuss at next meeting.
19:03:22 <roshi> well, we're over time
19:04:13 <danofsatx> yup. late for class. y
19:04:20 <danofsatx> 'all be good now, heah?
19:04:38 <roshi> yep, take it easy danofsatx
19:04:58 <roshi> there are 4 proposed blockers left, I think we got through enough today
19:05:05 <roshi> but can keep going if people are so inclined
19:05:38 * oddshocks doesn't mind
19:06:02 * kparal doesn't feel like it
19:06:15 <roshi> we can end meeting
19:06:22 * oddshocks is cool with that
19:06:22 <roshi> #topic Open Floor
19:06:28 <tflink> kparal: to check for secureboot - https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Secure_Boot
19:06:30 * roshi sets the fuse
19:06:53 * tflink runs away
19:07:15 <roshi> 3...
19:07:29 <robatino> there was discussion in #fedora-qa about whether the time for this meeting should be fixed at 1600 UTC or fixed at local time as in the QA meeting
19:07:31 <kparal> tflink: thanks
19:07:40 <kparal> robatino: ah, good call
19:07:44 <kparal> thoughts?
19:07:52 <robatino> the SOP: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Announcement
19:08:04 <roshi> well, if we keep fixed to local it conflicts with my cloud meeting at 1900
19:08:23 <kparal> adamw is probably the one most affected by the time shift
19:08:28 <robatino> it's confusing in that it refers to EDT, but the announcement should always use the current time zone depending on daylight saving
19:09:18 <kparal> roshi: the cloud meeting sticks to UTC?
19:09:45 <roshi> yeah - afaik
19:09:57 <roshi> I'll ask during this meeting though
19:10:22 <kparal> for us in CZ, it's actually better to stick to UTC in this case, it's 5-8pm instead of 6-9pm
19:10:28 <kparal> but I don't care that much
19:10:45 <kparal> I guess we'll want to ask adamw when he returns
19:10:52 <kparal> I'm fine with both approaches
19:11:40 * tflink also has little opinion on which time
19:12:43 <kparal> roshi: can you discuss with adamw and then choose one version?
19:13:03 <kparal> let's just make sure fedocal and test-announce matches
19:13:03 <roshi> sure
19:13:24 <roshi> I'll link up with adamw and figure something out
19:13:25 <kparal> I can adjust fedocal if you want, I have a lot of experience with its bugs :)
19:13:31 <roshi> probably message test@ too
19:13:44 <kparal> ok
19:13:56 * kparal EOF
19:14:48 <roshi> cool
19:15:00 <roshi> thanks for coming folks! we'll have the time worked out next go around
19:15:09 <roshi> #endmeeting