16:01:33 <adamw> #startmeeting F24-blocker-review
16:01:33 <zodbot> Meeting started Mon May 30 16:01:33 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:33 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:01:35 <adamw> #meetingname F24-blocker-review
16:01:35 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:01:37 <adamw> #topic Roll Call
16:02:11 * coremodule is here
16:02:38 * pwhalen is here
16:03:23 <adamw> hmm, pretty light turnout...
16:03:30 <adamw> it's a holiday somewhere today right?
16:03:43 <coremodule> adamw, That is correct.
16:04:06 <adamw> nb: nirik: ping
16:04:15 * adamw goes to get some breakfast
16:04:44 <kk4ewt> no blockers?
16:05:59 <pwhalen> kk4ewt, we're waiting for folks to join
16:06:29 <cmurf> The cmurfinator is back.
16:09:20 <kk4ewt> holiday in the usa, most people on grill duty
16:10:47 <adamw> sorry folks
16:10:58 <adamw> i'm on medical duty today so i might pop in and out a bit like that
16:11:01 <adamw> lemme chair some people
16:11:10 <adamw> #chair pwhalen coremodule cmurf
16:11:10 <zodbot> Current chairs: adamw cmurf coremodule pwhalen
16:11:18 <kk4ewt> .hello jbwillia
16:11:19 <zodbot> kk4ewt: jbwillia 'Ben Williams' <vaioof@yahoo.com>
16:11:30 <adamw> kk4ewt: no offence intended, i just grabbed the first names i saw =)
16:11:34 <adamw> i know who you are :P
16:11:40 <kk4ewt> aka Southern_Gentlem
16:12:01 <kk4ewt> wasnt sure you knew this nick
16:12:02 <adamw> ok, so we kinda have to do some review today even with a small turnout, because we're hitting freeze this week
16:12:07 <adamw> it's your old one right?
16:12:29 <kk4ewt> this is my home nick SG is at work
16:13:09 <adamw> ah k
16:13:10 <adamw> #topic Introduction
16:13:10 <adamw> Why are we here?
16:13:10 <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:13:11 <adamw> #info We'll be following the process outlined at:
16:13:11 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:13:13 <adamw> #info The bugs up for review today are available at:
16:13:15 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:13:17 <adamw> #info The criteria for release blocking bugs can be found at:
16:13:19 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:13:21 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:13:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:13:25 <adamw> any volunteers to secretarialize?
16:13:28 * coremodule has secretary duty covered.
16:13:34 <adamw> thanks!
16:13:38 <adamw> #info coremodule will chair
16:13:42 <coremodule> adamw, No problem!
16:14:02 <adamw> we have:
16:14:02 <adamw> #info 4 Proposed Blockers
16:14:02 <adamw> #info 5 Accepted Blockers
16:14:02 <adamw> #info 5 Proposed Freeze Exceptions
16:14:04 <adamw> #info 1 Accepted Freeze Exceptions
16:14:14 <adamw> so without further ado, let's roll into the proposed blockers
16:14:27 <adamw> again, sorry if i have to disappear for a couple of minutes now and again, if it gets too long, someone else move things along :)
16:14:37 <adamw> without further ado, diving into the proposed blockers:
16:14:37 <adamw> #topic (1337731) Live image compose fails with dnf 1.1.9
16:14:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1337731
16:14:38 <adamw> #info Proposed Blocker, anaconda, MODIFIED
16:14:59 <cmurf> +1 blocker
16:15:03 <cmurf> already discussed
16:15:09 <adamw> well, the update was unpushed for f24 this week
16:15:12 <cmurf> oh
16:15:21 <cmurf> well i have it on f24
16:15:23 <cmurf> somehow
16:15:28 <adamw> from u-t while it was out
16:15:53 <cmurf> i thought i had that disabled on this machine, huh
16:15:57 <adamw> we'd need dgilmore around to be 100% clear on whether or not it affects composes at this point though
16:15:58 <cmurf> oh it's the f23 server that got it
16:16:03 <cmurf> froms stable
16:16:30 <adamw> ah
16:16:42 <kk4ewt> +1 FE +1 blocker anaconda
16:16:43 <adamw> yeah, one issue with unpushing it on f24 is now the upgrade path is broken :/
16:17:15 <adamw> dgilmore was complaining about it breaking stuff last night, but he didn't specify whether he was talking f24 or rawhide
16:17:37 <cmurf> skip
16:17:39 <cmurf> ?
16:17:56 <adamw> hum, let me just check today's f24 nightly compose and see what happened
16:19:24 <adamw> looks like today's f24 workstation and kde lives both failed on the lorax bug, but didn't hit this one
16:19:46 <adamw> so i think we can say for now that this isn't a blocker due to being unpushed
16:20:09 <cmurf> ok
16:20:34 <cmurf> is there a way to just vote to make it automatically a blocker if it does somehow get pushed so we don't have to come back to it?
16:20:51 <adamw> nothing magic, no, it'd just be text...the freeze is tomorrow so i think we're fairly safe
16:20:58 <cmurf> ok
16:20:59 <adamw> after that it *can't* get pushed without our approval
16:21:37 <adamw> proposed #agreed 1337731 - RejectedBlocker - this would be a blocker, but the update has now been unpushed and the freeze is tomorrow, so it will not be necessary to track this as a blocker
16:21:48 <cmurf> ack
16:21:50 <pwhalen> ack
16:22:00 <adamw> this *does* mean we probably now have a 0-day blocker for 'fixing the dnf upgrade path', though.
16:22:00 <coremodule> ack
16:22:10 <adamw> #agreed 1337731 - RejectedBlocker - this would be a blocker, but the update has now been unpushed and the freeze is tomorrow, so it will not be necessary to track this as a blocker
16:22:29 <adamw> #topic (1337336) gnome-software shows updates but "Restart & Install" button doesn't install them
16:22:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1337336
16:22:29 <adamw> #info Proposed Blocker, gnome-software, ON_QA
16:22:38 <adamw> so this is one we punted on for more info last week
16:22:59 <cmurf> i haven't hit this
16:23:09 <coremodule> rhughes pushed an update to gnome-software (3.20.2-1.fc24) last week that fixed this and a Bodhi push later last week. So far as I know, it's gone stable and it works.
16:24:06 <coremodule> Let me rephrase: so far as I know, it's gone stable. I know it works because I've tested it.
16:24:11 <cmurf> I did my update two weeks ago, on the test day, and didn't hit it
16:24:49 <coremodule> cmurf, Did you have only "OS Updates" in the "Updates" queue?
16:25:10 <cmurf> I had only the Fedora 24 upgrade option in the Updates tab.
16:26:38 <coremodule> Did you go F23 to F24?
16:26:46 <adamw> it seems like we nailed this down quite well, right?
16:26:53 <cmurf> coremodule: yes
16:26:59 <coremodule> cmurf, Ah, gotcha.
16:27:06 <cmurf> This bug reads like it's F24 updates only, nothing to do with F23.
16:27:15 <adamw> yes.
16:27:23 <coremodule> adamw, Yes, I think so.
16:27:32 <cmurf> nice, then I'm a moron, carry on!
16:27:52 <coremodule> cmurf, :P
16:27:54 <adamw> so, it's pretty borderline
16:28:11 <cmurf> Well if it's no longer reproducible, it doesn't seem to be a blocker.
16:28:22 <adamw> so in case anyone missed it, the status is this: if the only thing in the updates list is the 'OS Update' entry, the update will fail
16:28:30 <adamw> it is reproducible, perfectly so
16:28:30 <cmurf> ohh
16:28:36 <adamw> until the update is pushed stable
16:28:46 <adamw> if anything else is in the updates list, the update will succeed
16:29:01 <adamw> so on the one hand eventually your update probably *is* going to work, on the other hand it's a pretty bad look when it doesn't
16:29:16 <adamw> easiest thing might be just to punt and say it's about to get resolved anyway so we refuse to make up our minds :P
16:29:18 <cmurf> what version?
16:29:24 <cmurf> 3.20.3-1 ?
16:29:34 <cmurf> That's today's gnome-software
16:29:37 <coremodule> cmurf, 3.20.1
16:29:41 <pwhalen> heh, +1 punt then
16:29:54 <cmurf> well 3.20.1 has been around since april 26
16:30:09 <cmurf> sorry april 13
16:30:52 <coremodule> cmurf, Whops, looks like 3.20.2-2. My bad.
16:31:21 <coremodule> adamw, If we punt this another week, will the update get pushed stable in time for freeze?
16:31:55 <cmurf> 3.20.2-2 isn't listed in bodhi at all
16:31:57 <adamw> it's already submitted for stable
16:32:05 <adamw> 3.20.3-1 is
16:32:05 <adamw> https://bodhi.fedoraproject.org/updates/FEDORA-2016-2be09c9861
16:32:07 <coremodule> 3.20.3-1 should be.
16:32:16 <cmurf> 3.20.3-1 is in bodhi
16:32:27 <adamw> it's already submitted for stable, so it should go in the next push
16:32:30 <cmurf> when i search for gnome-software in bodhi I get ass tons of other things
16:32:36 <adamw> i guess we could give it an acceptedfe just in case it doesn't get pushed somehow
16:32:42 <cmurf> wh is flatpak in the search results? and yelp-xls?
16:32:58 <adamw> cmurf: if you just type gnome-software into the search box then wait (don't hit enter) you'll get a drop-down of matching packages
16:33:06 <cmurf> that's what I did
16:33:08 <adamw> you can click on gnome-software in that list and see only updates for the package
16:33:12 <cmurf> that's what i did
16:33:22 <adamw> oph
16:33:27 <adamw> you're seeing updates with multiple packages
16:33:30 <cmurf> yes
16:33:32 <adamw> that flatpak one has gnome-software in it too
16:33:44 <adamw> flatpak is the new name for xdg-app
16:33:56 <cmurf> yeah i know but I don't understand the listing, it's so cluttered
16:34:20 <adamw> anyhooo
16:34:22 <coremodule> +1 FE just in case sounds good.
16:34:23 <cmurf> there's gnome-software 3.20.3-1 2 days old, and then 3.18.2 7 months old
16:34:31 <cmurf> nothing in between
16:35:26 <adamw> proposed #agreed 1337336 - AcceptedFreezeException - it's very difficult to decide whether this is a blocker, and as the fix is already queued for stable we decided not to waste time arguing over it. We are granting it a freeze exception just in case it somehow doesn't get pushed stable before the freeze kicks in, but it should
16:35:44 <coremodule> ack
16:35:51 <kk4ewt> ack
16:36:37 <cmurf> ack
16:36:41 <adamw> #agreed 1337336 - AcceptedFreezeException - it's very difficult to decide whether this is a blocker, and as the fix is already queued for stable we decided not to waste time arguing over it. We are granting it a freeze exception just in case it somehow doesn't get pushed stable before the freeze kicks in, but it should
16:36:47 <adamw> #topic (1337582) Fails to start with "Cannot read MSR_ERROR_CONTROL from /dev/cpu/0/msr" when running in VM on Xeon E5-2450 host
16:36:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1337582
16:36:47 <adamw> #info Proposed Blocker, mcelog, NEW
16:37:51 * satellit joining late
16:37:53 <adamw> so i've been trying to get some input from the maintainer on this, but it's kinda radio silence
16:38:14 <adamw> i did some digging into it upstream and it does seem fairly limited in terms of the range of CPUs it affects, and it also seems to only affect VMs running on the system
16:38:26 <cmurf> interesting
16:38:44 <cmurf> the criteria doesn't distinguish between baremetal and VM
16:38:53 <adamw> cmurf: the criterion is basically a polish criterion
16:39:07 <adamw> the idea is not to ship with a service that never starts properly for anyone because that looks like we don't know what the hell we're doing
16:39:07 <cmurf> i'd be more concerned if this were baremetal
16:39:21 <adamw> so i'm probably -1 on this as it's fairly configuration-specific
16:39:25 <cmurf> sure but that it's only failing in VM's meh
16:39:28 <adamw> right
16:39:35 <adamw> not sure if it's worth an FE
16:39:46 <adamw> on the one hand i think i know how to fix it, on the other is it really worth bothering with fixing on the media? meh
16:40:19 <cmurf> add it to your, i really don't want to do that other thing so i'll do this thing, pile
16:40:35 <pwhalen> right, -1 blocker .. can be fixed with an update
16:40:53 <cmurf> i'm definitely -1
16:41:03 <kk4ewt> -1 blocker
16:41:56 <adamw> proposed #agreed 1337582 - RejectedBlocker RejectedFreezeException - further investigation seems to confirm that this is quite hardware-specific, so as the criterion in question is a 'polish' criterion the impact is not broad enough to constitute a violation. It's also not significant enough to be worth breaking the freeze to try and fix
16:42:20 <cmurf> ack'd
16:42:27 <coremodule> ack
16:42:46 <pwhalen> ack
16:42:50 <kk4ewt> ack
16:42:50 <adamw> #agreed 1337582 - RejectedBlocker RejectedFreezeException - further investigation seems to confirm that this is quite hardware-specific, so as the criterion in question is a 'polish' criterion the impact is not broad enough to constitute a violation. It's also not significant enough to be worth breaking the freeze to try and fix
16:42:59 <adamw> #topic (1334960) ValueError: plural forms expression could be dangerous
16:42:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1334960
16:42:59 <adamw> #info Proposed Blocker, python-blivet, NEW
16:44:09 <adamw> so this is a new one, seems to be a translation issue
16:44:10 <cmurf> how about FE?
16:44:24 <coremodule> langtable?
16:44:38 <cmurf> It affects Lithuanian but how far does the scope extend?
16:45:21 <adamw> by my reading it's likely fairly specific
16:45:33 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1334960#c14 suggests it's an error in the lithuanian translation po file itself
16:46:05 <cmurf> I think this is an FE not a blocker *shrug*
16:46:12 <adamw> lemme see if bcl's around to check in with
16:46:19 <adamw> assuming it's limited to lithuanian i'd agree, yep
16:48:22 <kk4ewt> can we skip for more info for now and pick this up down the list
16:49:18 <adamw> we can do that, or just reject it and it can be re-proposed if we're wrong...
16:49:24 <adamw> i think i'll vote -1/+1
16:49:52 <cmurf> -1 blocker, +1 FE
16:50:06 <pwhalen> wfm, -1/+1
16:50:19 <coremodule> -1 blocker
16:50:36 <kk4ewt> +fe -blocker for now
16:50:56 <coremodule> Do we have user statistics regionally?
16:51:11 <adamw> proposed #agreed 1334960 - RejectedBlocker AcceptedFreezeException - we believe this affects only Lithuanian, and by itself that's not a big enough locale to consider release blocking, but of course it's worth a freeze exception to fix. The bug can be re-proposed as a blocker if it affects more locales
16:51:13 <coremodule> To see how many users we have that use the Lithuanian translation?
16:51:22 <cmurf> do we have statics globally?
16:51:46 <adamw> coremodule: i think someone dug out some numbers a while back. the top locales are the obvious ones - NA, western Europe, Russia, China i think
16:51:59 <pwhalen> ack
16:52:06 <cmurf> ack'achoo
16:52:07 <adamw> i dunno if we have them easily available though
16:52:09 <kk4ewt> ack
16:52:14 <adamw> and it'd be a bad day to try and find out, it seems :/
16:52:16 <adamw> mattdm would likely know
16:52:21 <adamw> #agreed 1334960 - RejectedBlocker AcceptedFreezeException - we believe this affects only Lithuanian, and by itself that's not a big enough locale to consider release blocking, but of course it's worth a freeze exception to fix. The bug can be re-proposed as a blocker if it affects more locales
16:52:26 <coremodule> adamw, Alright, just curious. If I find 'em, I'll post em on the QA side.
16:52:28 <coremodule> ack
16:52:31 <adamw> thanks
16:52:40 <adamw> #info that's all the proposed blockers for now
16:52:51 <adamw> let's do the proposed FEs, since freeze is tomorrow
16:52:56 <adamw> #info moving on to proposed FEs
16:52:58 <cmurf> yes
16:53:02 <adamw> #topic (1330820) blivet.errors.DeviceError: ('cannot replace active format', 'sde1')
16:53:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1330820
16:53:03 <adamw> #info Proposed Freeze Exceptions, anaconda, POST
16:53:30 <kk4ewt> +1
16:53:49 <cmurf> +1 FE
16:54:01 <cmurf> so adamw hit this bug with firmware raid?
16:54:25 <cmurf> but originally it was due to a USB stick that was already mounted?
16:54:39 <adamw> so bcl proposed this one
16:54:46 <adamw> yeah, it seems there are some different ways to hit it
16:54:49 <adamw> but i'm gonna trust bcl
16:54:51 <pwhalen> +1 FE
16:54:56 <cmurf> i love bugs that do that
16:55:43 <adamw> the change basically adds a check for whether any partition on a disk selected for install is currently mounted and displays an error if so...
16:55:49 <adamw> i think that *should* be safe
16:55:56 <cmurf> you think you're dialing a new phone number, but "yep, it's me again"
16:56:00 <adamw> i wouldn't wanna take it the day before release, but i think it's OK now
16:56:30 <cmurf> well FE approval is contingent on a tested fix
16:56:34 <adamw> proposed #agreed 1330820 - AcceptedFreezeException - this would save some people from encountering a crash during install so it seems worthy of a freeze exception early in the freeze period
16:56:39 <cmurf> if it's not considered sufficiently tested... revert
16:56:55 <cmurf> ack
16:56:57 <pwhalen> ack
16:57:01 <kk4ewt> ack
16:57:13 <coremodule> ack
16:57:32 <adamw> #agreed 1330820 - AcceptedFreezeException - this would save some people from encountering a crash during install so it seems worthy of a freeze exception early in the freeze period
16:58:05 <adamw> #topic (1317275) [abrt] gnome-software: gs_plugin_loader_get_updates_async(): gnome-software killed by SIGSEGV
16:58:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1317275
16:58:05 <adamw> #info Proposed Freeze Exceptions, gnome-software, NEW
16:58:17 <cmurf> -1 blocker
16:58:22 <cmurf> oops -1 fe
16:58:27 <cmurf> no new information
16:58:30 <cmurf> no reproducer
16:58:50 <cmurf> no idea what fix would be needed or the scope or the risk of such fix
16:59:00 <adamw> yeah
16:59:06 <adamw> -1 for now
16:59:12 <kk4ewt> -1
16:59:16 <coremodule> -1
16:59:17 <pwhalen> -1
17:01:19 <adamw> proposed #agreed 1317275 - RejectedFreezeException - there is no info on the actual bug, or the consequences of the crash, or how invasive a fix would be, or even any clear reproducer. it's impossible to grant a freeze exception in this case. If more information comes out, the decision can be re-considered
17:01:51 <pwhalen> ack
17:02:00 <kk4ewt> ack
17:02:44 <coremodule> ack
17:03:08 <adamw> #agreed 1317275 - RejectedFreezeException - there is no info on the actual bug, or the consequences of the crash, or how invasive a fix would be, or even any clear reproducer. it's impossible to grant a freeze exception in this case. If more information comes out, the decision can be re-considered
17:03:17 <adamw> #topic (1331120) Add support for running --make-ostree-live with --no-virt (and inside mock)
17:03:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331120
17:03:18 <adamw> #info Proposed Freeze Exceptions, lorax, POST
17:03:37 <cmurf> is FE still needed? last update was apr 27. If the enhancements for lorax and anaconda aren't ready, my concern is getting it tested by ostree users sooner than later. What could this break if anything?
17:04:18 <cmurf> i'm probably +1 FE, but it seems like doing a certain activity in a crosswind
17:04:24 <adamw> hmm, this is kind of a big change
17:04:37 <adamw> i think there's a bit of a process conflict between us and anaconda here that kinda needs solving
17:04:45 <coremodule> cmurf, landing an airplane?
17:04:48 <cmurf> seems like an enhancement rather than a fix
17:04:48 <adamw> they seem to want to apply a freeze to anaconda pretty much from beta all the way to final
17:05:06 <cmurf> coremodule: that's easy once you get the hang of it, the other thing can almost always be fouled up
17:05:14 <adamw> so they're submitting FE requests really early and not merging things to anaconda's f24 branch unless we approve the FE
17:05:20 <adamw> but we don't do FE review until the freeze is close
17:05:26 <cmurf> right
17:05:27 <cmurf> odd
17:05:27 <adamw> because that's not how the official freeze process works
17:05:28 <coremodule> cmurf, Low-level wind shear.
17:05:44 <cmurf> i stay away from that shit
17:06:02 <cmurf> just add power though :-D
17:06:17 <kk4ewt> well if lorax is borked then there is no compose
17:06:25 <kk4ewt> +1 FE
17:06:26 <cmurf> yeah seems late
17:06:30 <adamw> so...idea: we accept this for now but ask bcl not to land it unless he's very confident it's OK, and try to figure something out with them for future cycles
17:06:30 <cmurf> I'm waffling now
17:06:43 <cmurf> fair idea
17:08:15 <adamw> so that's a reluctant +1 for me
17:08:47 <cmurf> reluctant +1 from me as well
17:09:02 <pwhalen> yea, +1 FE
17:09:57 <adamw> proposed #agreed 1331120 - AcceptedFreezeException - we're willing to accept this as a convenience for the compose process and due to the misunderstanding between anaconda team and blocker review group about how the FE process works, but will ask bcl not to land it unless he's very confident in it, and work with anaconda team to improve this process in future
17:10:53 <kk4ewt> ack
17:10:54 <cmurf> ack
17:10:59 <pwhalen> ack
17:11:00 <coremodule> ack
17:11:25 <adamw> #agreed 1331120 - AcceptedFreezeException - we're willing to accept this as a convenience for the compose process and due to the misunderstanding between anaconda team and blocker review group about how the FE process works, but will ask bcl not to land it unless he's very confident in it, and work with anaconda team to improve this process in future
17:11:56 <adamw> #topic (1331869) i686 images are about 400MB larger than x86_64 images
17:11:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331869
17:11:57 <adamw> #info Proposed Freeze Exceptions, lorax, POST
17:12:34 <cmurf> this is a read, so somehow i686 rootfs squashes less than x86_64
17:12:49 <cmurf> the FE request is to drop the unneeded initramfs in the squashfs.img
17:12:54 <cmurf> seems safe, it's not used so i'm +1 FE
17:13:21 <kk4ewt> we already have a FE for loarx do we need another
17:13:52 <kk4ewt> ?
17:14:42 <cmurf> well if we want i686 to drop 40MB in size basically for free, yes
17:14:42 <adamw> yeah, we don't grant them by *package*, we grant them by *bug*
17:14:49 <adamw> i'm kinda -1 on this
17:14:59 <cmurf> explain
17:15:04 <pwhalen> +1 FE .. squashfs size has been a problem at times for systems with less memory (like arm)
17:15:07 <adamw> 40MB saving on i686 image size is pretty small beans for the changes involved
17:15:18 <cmurf> true...
17:15:26 <cmurf> it's not even 1%
17:15:26 <adamw> hmm, if it affects memory usage too that makes the calculation a bit different i guess?
17:15:28 <kk4ewt> 40 or 400
17:15:40 <cmurf> the initramfs is 40
17:15:47 <kk4ewt> -1
17:15:52 <pwhalen> pretty small, but every little bit helps
17:16:18 <kk4ewt> i am going to trust pwhalen on this +1 FE
17:17:08 <adamw> will this even affect ARM images?
17:17:42 <cmurf> not having an initramfs in rootfs is totally inconsequential, both the hostonly and nohostonly get built at install time anyway
17:18:07 <cmurf> actually... does anyone remember if that nohostonly bug got fixed?
17:18:36 <pwhalen> my understanding, was that it drops the initrd from the squashfs.. so this would affect the netinstalls
17:19:03 <cmurf> no that initrd is elsewhere it's not in the rootfs.img
17:19:39 <adamw> i'd find it a lot easier to vote if bruno and bcl were around to discuss the impact :/
17:19:42 <pwhalen> hrm, was going by this "<cmurf> the FE request is to drop the unneeded initramfs in the squashfs.img"
17:19:49 <cmurf> it's on the ISO 9660 / el torito portion of the media
17:19:52 <adamw> maybe we could punt it and try to vote in-bug?
17:20:12 <cmurf> yes but the bootloader does not read the rootfs
17:20:58 <cmurf> it reads the kernel and initramfs from the iso 9660 part, then that initramfs loopback mounts squashfs, then loopback mounts rootfs, then starts up
17:21:21 <cmurf> that's my understanding here is that there's an initrd in the rootfs.img that really isn't necessary for anybody
17:21:31 <cmurf> it's an artifact of live image builds i guess
17:22:09 <cmurf> we can also punt
17:22:26 <cmurf> because it's a tiny amount and bruno is already saying he'll have to chop other things because 40M isn't enough
17:22:59 <adamw> proposed #agreed 1331869 - punt (delay decision) - it's not clear exactly what benefits this brings (if it's only a small size saving for live images, or more than that) and what the potential dangers are, and relevant folks aren't around at present to inform. we will try to gather information and vote in-bug
17:23:25 <kk4ewt> ack delay
17:23:25 <coremodule> Yes, ack
17:23:25 <cmurf> ack
17:23:40 <pwhalen> ack
17:23:41 <adamw> #agreed 1331869 - punt (delay decision) - it's not clear exactly what benefits this brings (if it's only a small size saving for live images, or more than that) and what the potential dangers are, and relevant folks aren't around at present to inform. we will try to gather information and vote in-bug
17:24:11 <adamw> coremodule: could you throw a couple of needinfos at the bug when secretarializing, ask bcl and bruno what the benefit of this would be and how safe the fix is? thanks
17:24:29 <coremodule> adamw, Sure, consider it done.
17:24:35 <adamw> #topic (1331091) The stored screen's resolution isn't always retrieved
17:24:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1331091
17:24:35 <adamw> #info Proposed Freeze Exceptions, plasma-workspace, NEW
17:25:02 <cmurf> looks like it's a problem that upstream is aware of but unclear if they have a fix
17:25:07 <cmurf> i didn't go look at the upstream bug
17:25:39 <adamw> meh, i'm gonna say -1 on this since it's mostly going to affect installed systems and thus can reasonably be fixed with an update
17:25:45 <adamw> i don't see much benefit to fixing this for the live
17:26:05 <cmurf> right it's annoying but isn't causing a major functionality problem
17:26:11 <cmurf> and fixable with an update
17:26:31 <coremodule> Agreed.
17:26:31 <cmurf> and there appears to be a workaround
17:26:34 <kk4ewt> -1 for now need more info
17:26:39 <cmurf> -1 FE
17:26:46 <pwhalen> -1
17:26:48 <coremodule> -1
17:28:10 <adamw> proposed #agreed 1331091 - RejectedFreezeException - this will mostly affect installed systems and can be sufficiently fixed with an update, there is no great benefit to fixing it in the release media
17:28:29 <coremodule> ack
17:28:35 <kk4ewt> ack
17:28:35 <cmurf> ackaman
17:29:01 <adamw> #agreed 1331091 - RejectedFreezeException - this will mostly affect installed systems and can be sufficiently fixed with an update, there is no great benefit to fixing it in the release media
17:29:09 <adamw> i'm surprised you haven't used ackbar yet
17:29:17 <cmurf> as in admiral?
17:29:21 <cmurf> that's a trap
17:29:23 <adamw> indeed
17:29:24 <adamw> =)
17:29:31 <adamw> #info that's all the proposed FEs
17:29:59 <adamw> looking through the accepted blockers...
17:30:07 <adamw> #info quick accepted blocker summary:
17:30:11 <cmurf> yes
17:30:18 <adamw> #info pjones is working on 1320273
17:30:22 <cmurf> 1318045 concerns me
17:30:32 <cmurf> 1320273 can always just be reverted
17:30:35 <adamw> #info adamw worked out 1333998 and fixes are pending anaconda and systemd-side
17:30:46 <cmurf> ok good
17:30:46 <adamw> #info selinux and freeipa folks are working on 1333106
17:31:04 <cmurf> yep
17:31:25 <adamw> #info 1318045 still needs someone to pin down exactly why the initramfs is missing vconsole.conf, adamw will look into it this week if no-one else does
17:31:59 <adamw> the kde one...maybe we should make that a topic
17:31:59 <adamw> #topic (1293167) [abrt] kf5-kinit: qt_message_fatal(): kdeinit5 killed by SIGABRT
17:32:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1293167
17:32:00 <adamw> #info Accepted Blocker, kf5-kinit, NEW
17:32:10 <adamw> so i'm becoming less and less convinced this ought to be a blocker...
17:32:35 <cmurf> yeah
17:33:10 <cmurf> in some sense this is really up to them, and what sort of ui/ux they want.
17:33:21 <cmurf> it's not good behavior, BUT, is it a blocker?
17:33:47 <adamw> maybe we should ask the brno folks to re-test and see if they confirm or deny viorel's reading of it
17:33:59 <kk4ewt> well it would be a blocker for kde which is a primary blocker
17:34:02 <adamw> i'd probably be -1 if this was specific to KVM with qxl, i'd be OK with just documenting that
17:34:17 <cmurf> yep
17:34:27 <cmurf> in that case it's conditional and fixable with an update
17:35:25 <adamw> it was never a completely clear criteria violation anyway, it's already conditional on using user switching (which isn't actually mentioned in the criteria or covered in the test case)
17:35:36 <cmurf> good point
17:36:11 <adamw> proposal: kick this back to proposed blocker and ask brno folks to re-test
17:36:20 <cmurf> I'd support changing this to FE from blocker now; or ask for clarification from KDE folks.
17:36:22 <kk4ewt> +1 kick
17:37:20 <cmurf> It sounds like there's not much in the way of resources to fix it anyway; so if there's a slim but real chance they aren't going to get it fixed anyway, no point in it being a blocker.
17:37:23 <adamw> proposed #agreed 1293167 - revert to proposed blocker and ask for further testing from kparal / pschindl, this bug seems to have a more limited impact than was first thought
17:37:35 <cmurf> ack
17:37:36 <kk4ewt> +1 kick more info before FE
17:37:37 <kk4ewt> ack
17:38:28 <adamw> coremodule: WDYT?
17:38:53 * cmurf caught him napping 25min ago
17:39:09 <coremodule> Sure, more testing can't hurt. +1 kick for now.
17:39:11 <pwhalen> +1 kick, ack
17:39:23 <adamw> #agreed 1293167 - revert to proposed blocker and ask for further testing from kparal / pschindl, this bug seems to have a more limited impact than was first thought
17:39:34 <pwhalen> sorry, SIG-nature
17:39:44 <adamw> coremodule: there's no super-established process for this kinda change, just write a sensible comment and drop the AcceptedBlocker from the whiteboard
17:40:00 <coremodule> adamw, Gotcha, I can do that.
17:40:06 <adamw> thanks
17:40:13 <adamw> welp, that's everything
17:40:30 <adamw> now i think about it a bit harder the f23 to f24 dnf upgrade path shouldn't be a major problem since dnf-system-upgrade does distro-sync by default now
17:40:36 <adamw> so i can't think of anything else to cover
17:40:38 <adamw> #topic Open floor
17:40:41 <adamw> anyone else have anything?
17:40:58 <coremodule> Nothing here.
17:41:00 <adamw> of course, my usual call for folks to cover the remaining validation tests :)
17:41:21 <cmurf> ship it!
17:41:49 <kk4ewt> will try to help test more over the next couple of weeks i wnt isos for Southeast Linuxfest on the weekend before release
17:42:01 <adamw> thanks a lot
17:42:03 <cmurf> adamw what about gnome-software upgrades running into the dnf upgrade path issue?
17:42:21 <adamw> cmurf: i think that path should be using distro-sync too, but it'd be worth checking
17:44:02 <cmurf> i've got an f23 tree I can get dnf 1.1.9 on, then do the graphical upgrade and see
17:44:34 <cmurf> however, hughsie's copr repo doesn't work anymore so i'm not sure what version of that I should use on f23 to make a valid test.
17:44:58 <cmurf> HUH maybe it doesn't work because I'm now on f24...hmm :-)
17:45:07 <adamw> seems likely :)
17:45:09 <cmurf> if i go back to f23 it might still be working
17:45:24 <cmurf> ok well that's an easy test to do
17:46:12 <cmurf> Alles in Ordnung.
17:47:07 <cmurf> ok that it?
17:47:20 <adamw> that's all i've got
17:47:57 <cmurf> super
17:47:59 <cmurf> bye
17:48:11 <adamw> thanks for coming everyone!
17:48:16 <adamw> seems like we're done here
17:48:20 <adamw> return to your homes and go about your business
17:48:22 <adamw> #endmeeting