16:03:34 <roshi> #startmeeting F21-blocker-review
16:03:34 <zodbot> Meeting started Wed Oct 22 16:03:34 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:34 <roshi> #meetingname F21-blocker-review
16:03:34 <zodbot> The meeting name has been set to 'f21-blocker-review'
16:03:35 <roshi> #topic Roll Call
16:03:44 <roshi> who's around?
16:03:48 * kparal is here
16:04:23 * jskladan lurks
16:04:39 * roshi is here, obviously
16:04:53 <roshi> #chair kparal jskladan adamw
16:04:53 <zodbot> Current chairs: adamw jskladan kparal roshi
16:05:19 <roshi> danofsatx: you here?
16:05:26 <danofsatx> sorry, yup
16:05:38 <roshi> nothing to be sorry about :)
16:05:43 <adamw> ahoy
16:05:50 <adamw> sgallagh: blocker review starting
16:05:56 <danofsatx> building purchase requests on outdated Core2Duos takes a lot of my time....
16:05:58 <sgallagh> ahoy
16:06:20 * sgallagh sneaks out to microwave some popcorn^H lunch first
16:06:31 * agrimm lurks
16:07:06 <roshi> sorry for the late announcement :(
16:07:10 <roshi> #topic Introduction
16:07:11 <roshi> Why are we here?
16:07:11 <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:07:15 <roshi> #info We'll be following the process outlined at:
16:07:15 * jsmith joins a bit late
16:07:17 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:19 <roshi> #info The bugs up for review today are available at:
16:07:22 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:25 <roshi> #info The criteria for release blocking bugs can be found at:
16:07:27 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria
16:07:30 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria
16:07:33 <roshi> #link https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria
16:07:50 <roshi> well, 9 blockers to look through
16:07:56 * jskladan yay!
16:08:00 <roshi> first up:
16:08:01 <roshi> #topic (1155014) DeviceCreateError: ("'NoneType' object has no attribute 'name'", 'fedora-pool00')
16:08:04 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155014
16:08:07 <roshi> #info Proposed Blocker, anaconda, POST
16:08:09 <roshi> +1 blocker for me
16:08:44 * roshi has been trying to look at the blockers *before* the meeting
16:09:02 <sgallagh> +1
16:09:08 <kparal> +1
16:09:25 <kparal> roshi: there should be a badge for that!
16:09:49 <roshi> good idea kparal :)
16:09:55 <sgallagh> I've been squishing them, does that count?
16:09:56 <adamw> i was too, but didn't reach this one yet
16:10:22 <adamw> god, why does this break whenever I turn my fing back?
16:10:26 <adamw> i tested it for alpha and it was fine
16:10:55 <roshi> proposed #agreed - 1155014 - AcceptedBlocker - This bug is a clear violation of the Beta Guided partitioning criteria.
16:10:57 <adamw> nack
16:11:02 <adamw> the criterion cited does not cover this.
16:11:14 <roshi> eh?
16:11:14 <adamw> filesystem selection isn't in guided any more, it's in custom.
16:11:20 <roshi> ah
16:11:49 <roshi> proposed #agreed - 1155014 - AcceptedBlocker - This bug is a clear violation of the Beta custom partitioning criteria: "Complete an installation using any combination of disk configuration options it allows the user to select"
16:11:53 <roshi> better?
16:12:04 <adamw> no, because that's not a custom criterion. :)
16:12:41 <adamw> the custom criterion is at https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Custom_partitioning , just go copy/paste it...
16:12:43 * roshi needs more coffee
16:13:06 <adamw> we would actually have a slight bit of wiggle room here as it doesn't *say* thinp, only 'LVM', but I'd be inclined to take it.
16:13:44 * jreznik will join you later
16:14:04 <roshi> proposed #agreed - 1155014 - AcceptedBlocker - This bug is a clear violation of the Beta custom partitioning criteria: "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..."
16:14:17 <roshi> (so much for me getting us off to a fast start...)
16:14:56 <adamw> still no
16:14:59 <adamw> one more strike...
16:15:04 <adamw> "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions "
16:15:12 <adamw> the one you cited is interpreting existing, not creating new.
16:15:35 <roshi> .fire roshi
16:15:35 <zodbot> adamw fires roshi
16:15:51 <jsmith> I've never seen anyone get fired before...
16:15:54 * jsmith blinks
16:16:03 <adamw> jsmith: you don't hang around with me much, do you? :)
16:16:13 <roshi> proposed #agreed - 1155014 - AcceptedBlocker - This bug is a clear violation of the Beta custom partitioning criteria: "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes..."
16:16:16 <jsmith> adamw: Obviously not, or you'd have fired me too!
16:16:17 <roshi> there
16:16:32 <roshi> .fire jsmith for not hanging around enough to be fired before :p
16:16:32 <zodbot> adamw fires jsmith for not hanging around enough to be fired before :p
16:16:47 <roshi> it's a rite of passage jsmith - welcome to the club
16:17:02 <jsmith> I'm honored...
16:17:27 <roshi> :)
16:17:30 <kparal> can I ack already?
16:17:30 <roshi> ack/nack/patch?
16:17:36 <kparal> ack
16:17:42 <adamw> ack
16:17:43 <jskladan> ack
16:17:52 <roshi> #agreed - 1155014 - AcceptedBlocker - This bug is a clear violation of the Beta custom partitioning criteria: "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes..."
16:18:03 <roshi> #topic (1155633) anaconda doesn't use "url --mirrorlist" option from kickstart, uses stage2 instead
16:18:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155633
16:18:08 <roshi> #info Proposed Blocker, anaconda, NEW
16:18:44 <adamw> i'm currently on this one
16:18:53 <adamw> it sounds somewhat weird...
16:19:15 <roshi> is anything wrong in the ks?
16:19:21 * roshi hasn't used them much
16:19:23 <adamw> i've tested that just booting bare kernel/initrd and passing 'stage2' on the cmdline works as expected (downloads stage2 then defaults to 'closest mirror' for the repo)
16:19:33 <adamw> i'm now testing a ks similar to the reporter (with mirrorlist)
16:19:35 <kparal> jsedlak forgot to attach log files, oh my
16:19:49 <adamw> just waiting for the stage2 download
16:20:08 <kparal> he actually said he saw an error also with netinst and the same kickstart
16:20:46 <jsmith> Yeah, that does sound weird
16:20:57 <kparal> which would hit that criterion
16:21:05 <adamw> he doesn't list a package group in his kickstart
16:21:08 <adamw> solely 'chrony'
16:21:22 * sgallagh had a hard crash. Which one are we on now?
16:21:24 <adamw> i just tried an install with https://www.happyassassin.net/ks/base-net.ks and it seems to be running fine
16:21:37 <adamw> "Installing linux-firmware (7/252?"
16:21:59 <kparal> in that case, let's reject and ask him to test more and append logs
16:22:08 <adamw> that's booted from bare kernel/initramfs, with inst.stage2=https://dl.fedoraproject.org/pub/alt/stage/21_Beta_TC4/Server/x86_64/os/images/pxeboot/ inst.ks=https://www.happyassassin.net/ks/base-net.ks
16:22:10 <adamw> so...can't reproduce
16:22:16 <roshi> -1
16:22:27 <adamw> i can test with his kickstart very quickly
16:22:30 <kparal> adamw: well actually, that location contains valid yum metadata
16:22:35 <kparal> the point is, our doesn't
16:23:10 <kparal> and as inst.stage2 is defined, it should not look for that metadata
16:23:23 <adamw> kparal: ooh, i see. missed that bit. are you sure inst.stage2 doesn't expect a repo?
16:23:50 <kparal> the current anaconda documentation seems to be here: https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt
16:24:06 <adamw> yes
16:24:09 <kparal> (really, they point to git to this file from http://fedoraproject.org/wiki/Anaconda_Boot_Options)
16:24:19 <kparal> === inst.stage2 ===
16:24:19 <kparal> This specifies the location to fetch only the installer runtime image;
16:24:19 <kparal> packages will be ignored. Otherwise the same as <<inst.repo,`inst.repo`>>.
16:24:20 <adamw> to me, "Otherwise the same as <<inst.repo,`inst.repo`>> implies "must be a repo"
16:24:33 <kparal> well, "packages will be ignored"
16:24:36 <adamw> it says packages will be ignored, not that it's OK for it not to include metadata
16:25:00 <adamw> does the internal repo have a .treeinfo file?
16:25:08 <danofsatx> ok, PRs done. Now what are we doing over here? oh yeah...blockers
16:25:08 <kparal> I think the point of stage2 is to have only stage2 image mirrored, but pull packages from net
16:25:33 <kparal> adamw: should it be in os/ ?
16:25:37 <adamw> kparal: yes
16:25:40 <kparal> it is not there
16:25:41 <adamw> https://dl.fedoraproject.org/pub/alt/stage/21_Beta_TC4/Server/x86_64/os/.treeinfo
16:25:52 <adamw> well it's definitely going to need at least that, because that's how anaconda knows where stage2 is
16:26:11 <kparal> it was succesfull in downloading it :)
16:26:25 <kparal> otherwise it wouldn't have booted at all
16:26:41 <kparal> but got it, that might be a problem
16:26:42 <adamw> oh, hm, it seems to have a fallback, yeah
16:26:55 <adamw> dracut/anaconda-netroot.sh
16:27:53 <adamw> oh man, looking at that file just gave me some unpleasant f...16...? flashback. the nfs hack from then is still around, hah.
16:28:08 <adamw> so...i guess i can be persuaded this should work, but i'm probably -1 on it being a blocker
16:28:26 <adamw> the basic use case (boot from bare kernel, point it at a typical location for stage2) works
16:28:36 <kparal> I'm unhappy about the lack of information there, I'd rather punt
16:28:58 * adamw dislikes not explicitly making a decision before release...
16:29:12 <kparal> in that case, -1, because it worked for you
16:29:33 <roshi> I'm a -1 since we're so close to release, if further info crops up we can repropose it for final
16:29:48 <kparal> sounds good to me
16:29:49 <adamw> yeah, i think -1-but-ok-to-repropose-with-more-data is good
16:30:21 <roshi> proposed #agreed - 1155633 - RejectedBlocker - We were unable to reproduce this bug. If more information can be provided, please re-propose for Final.
16:30:55 <jsmith> AACK
16:31:03 <danofsatx> ack
16:31:04 <jskladan> ack
16:31:08 <kparal> ack
16:31:23 <roshi> #agreed - 1155633 - RejectedBlocker - We were unable to reproduce this bug. If more information can be provided, please re-propose for Final.
16:31:37 <roshi> way to get into the moment there jsmith :p
16:31:51 <roshi> #topic (1155334) [abrt] bind: gssapi_destroy_signverify_ctx(): named killed by SIGBUS
16:31:54 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155334
16:31:56 <roshi> #info Proposed Blocker, bind, NEW
16:32:03 <jsmith> roshi: The internet on this flight is terrible, so I'm having pretty good latency :-(
16:32:09 <adamw> is anyone secretary-izing?
16:32:18 <roshi> not yet
16:32:21 <roshi> volunteers?
16:32:22 <sgallagh> roshi: Actually, MODIFIED, not NEW anymore :)
16:32:43 <sgallagh> pspacek and I tracked it down and fixed it this morning.
16:32:44 <adamw> i can do it
16:32:48 <sgallagh> It's pretty serious
16:32:57 <roshi> so I see, blockerbugs must not have updated in time when I yanked the text
16:33:03 <roshi> thanks adamw
16:34:03 <roshi> +1
16:34:11 <roshi> pretty clear violation, imo
16:34:15 <danofsatx> sgallagh: wow, that was quick. What was the problem (if you know)?
16:34:45 <sgallagh> danofsatx: Basically a typo :-/
16:34:48 <adamw> +1, it basically makes freeipa useless
16:34:49 <kparal> +1
16:34:51 <danofsatx> heh
16:34:56 <danofsatx> oh yeah, +1
16:34:58 <adamw> sgallagh: haha! i've infected you with the 'basicallys'
16:35:10 <jreznik_pp> thozza is sick but he will take a look tomorrow, just heads up
16:35:27 <sgallagh> jreznik_pp: Take a look at what?
16:36:02 <roshi> proposed #agreed - 1155334 - This is a clear violation of the Domain controller role Beta criteria: " Multiple clients must be able to enrol and unenrol in the domain"
16:36:21 <danofsatx> shouldn't it be disenrol?
16:36:29 <adamw> possibly?
16:36:30 <danofsatx> er, disenroll
16:36:38 <adamw> that and the other bits of that criterion, yeah
16:36:39 <adamw> ack
16:36:43 <danofsatx> there are two l's in it
16:36:52 <kparal> ack
16:36:52 <danofsatx> i think...
16:36:55 <jskladan> ack
16:37:03 <roshi> enroll has two lls
16:37:10 <sgallagh> I usually say "join" and "part" myself
16:37:14 <roshi> #agreed - 1155334 - This is a clear violation of the Domain controller role Beta criteria: " Multiple clients must be able to enrol and unenrol in the domain..."
16:37:30 <danofsatx> http://grammarist.com/spelling/enrol-enroll/
16:37:32 <sgallagh> (Well, 'join to' and 'part from')
16:37:35 * dustymabe lurks
16:37:50 <roshi> welcome dustymabe :)
16:38:08 <danofsatx> arrogant Americans again, I guess ;)
16:38:22 <roshi> #topic (1146580) Mislabelled /usr/sbin, /usr/bin after fedup
16:38:23 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1146580
16:38:23 <roshi> #info Proposed Blocker, fedup-dracut, ASSIGNED
16:38:44 <dustymabe> roshi: thanks. starting to get hungry so I may run out and grab lunch and eat it while i lurk
16:38:48 <jsmith> Sounds like a blocker to me...
16:40:16 <adamw> we were still waiting for details on *exactly* what breaks here, which is why it's sitting undetermined
16:40:27 <adamw> unfortunately the other fedup fixes didn't land yesterday so we didn't get more testing on this
16:40:53 <adamw> " The first thing I hit was libvirt over ssh hitting problems; but then I relabelled /sbin and /usr/bin"
16:41:01 <adamw> if he hadn't done that i strongly suspect he'd have hit much worse problems pretty fast.
16:41:28 <sgallagh> Yeah, I agree
16:41:33 <sgallagh> +1 blocker
16:41:43 <dustymabe> +1
16:41:48 <danofsatx> +1
16:41:54 <adamw> still, one thing that occurs to me is that we require people to explicitly provide the fedup location prior to stable release
16:42:40 <adamw> and we do seem to get builds in https://dl.fedoraproject.org/pub/fedora/linux/development/21/x86_64/os/images/pxeboot/ , which i guess are generated nightly?
16:42:57 <adamw> it's just a bit questionable whether we actually need to have this fixed in the frozen beta.
16:43:12 <adamw> it'll only actually affect someone running fedup against the upgrade.img in the frozen beta tree.
16:44:30 <roshi> proposed #agreed - 1146580 - AcceptedBlocker - This bug violates the upgrade requirements Beta criteria: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ... Upgraded system requirements: The upgraded system must meet all release criteria."
16:44:54 <adamw> i guess i could ack that...but i'd like to remind myself exactly what fedup does if you don't pass instrepo...
16:46:10 <kparal> it uses some mirrormanager link
16:46:20 <kparal> which points to the latest public milestone
16:46:26 <kparal> Alpha Beta or Final
16:46:37 <kparal> of course provided fedora infra set it up
16:46:56 <kparal> they could point it to some TC compose as well, I assume
16:47:15 <adamw> mm
16:47:21 <kparal> but I don't know if there were some F21 changes
16:47:30 <adamw> i guess ack for now, we can fudge at go/no-go meeting if necessary/appropriate
16:47:30 <kparal> I'm saying what I remember from F20
16:47:38 <adamw> yeah, that's kinda what i wanted to check
16:47:55 <kparal> ack
16:48:13 * satellit late - listening
16:48:29 <adamw> mirrorurl = mirrorlist('fedora-install-$releasever')
16:49:07 <kparal> doesn't work yet at all: mirrors.fedoraproject.org/mirrorlist?repo=fedora-install-21&arch=x86_64
16:49:16 <kparal> damn firefox, add http
16:49:25 <kparal> but this does: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-install-20&arch=x86_64
16:49:47 <kparal> so I'd say someone forgot to set it up for Alpha
16:49:54 <adamw> https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-install-21&arch=x86_64 isn't set up right now
16:49:55 <adamw> ...yeah
16:50:12 <adamw> or it's just that we don't ever set it up pre-release, don't we always wind up having to pass --instrepo ?
16:50:14 <adamw> anyhow.
16:50:26 <adamw> nirik: can you shed any light?
16:51:02 <kparal> I remember it used to work for F20 Beta
16:51:05 * dustymabe is going to grab lunch. will be back in 20
16:51:20 <kparal> the mirrorlist pointed to F20 Beta dir
16:51:23 <sgallagh> adamw: nirik is out this week
16:51:25 <adamw> oh right
16:51:32 <adamw> .fire nirik
16:51:32 <zodbot> adamw fires nirik
16:51:45 <roshi> see jsmith? it's common :)
16:51:46 <adamw> so let's say ack for now and we can fudge at go/no-go if we want
16:52:17 <roshi> kk
16:52:20 <roshi> #agreed - 1146580 - AcceptedBlocker - This bug violates the upgrade requirements Beta criteria: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed. ... Upgraded system requirements: The upgraded system must meet all release criteria."
16:52:32 <roshi> #topic (1071356) Racy startup of ipa.service, named.service and dirsrv.target
16:52:35 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1071356
16:52:37 <roshi> #info Proposed Blocker, freeipa, NEW
16:53:43 <roshi> adamw: is this the clientside permutation of the earlier bug?
16:54:45 <roshi> ah, c#24
16:55:03 <adamw> i didn't see this one, but then i didn't test many reboots or anything because of the named crash bug
16:55:43 <sgallagh> OK, this is different
16:55:55 <sgallagh> It's irrespective of the named crash
16:56:03 <sgallagh> (we reproduced it after the fix for it)
16:56:10 <roshi> ah
16:56:20 <sgallagh> That being said, it's got a very simple workaround; run 'ipactl restart'
16:56:22 <danofsatx> I'm not seeing this one at all. ipa.service starts just fine (once it's deployed)
16:56:27 <roshi> c25 says the workaround is easy
16:56:36 <roshi> -1 update common bugs?
16:56:44 <sgallagh> That's my recommendation as well
16:56:48 <roshi> -1 *and* update common bugs? rather
16:56:56 <sgallagh> -1 and update common bugs
16:57:12 <danofsatx> -1 and update common bugs
16:57:16 <roshi> can we expect a fix for this for Final?
16:57:29 <sgallagh> (Also, I haven't validated it for certain, but the way we install from rolekit may actually mitigate it as well)
16:57:36 <danofsatx> c25 doesn't give me warm fuzzies, so I'd say no
16:57:54 <sgallagh> roshi: I will push them on it, but I'm not certain.
16:57:57 <adamw> yeah, this seems like the kind of thing that's OK for a beta
16:58:08 <roshi> I read the "today" as not going to get in for Beta go/no-go tomorrow
16:58:23 <sgallagh> Right, that much is certain
16:58:46 <sgallagh> I know enough about how this interacts to say that it's anyone's guess if it's fixed by Final though.
16:58:49 <sgallagh> It's... ugly
16:59:03 <roshi> proposed #agreed - 1071356 - RejectedBlocker - There is a easy to apply fix for this bug so it's not considered blocking. CommonBugs page will be updated with the workaround.
16:59:28 <roshi> s/is a/is an/
16:59:39 <danofsatx> patch (thinking....)
16:59:41 <adamw> sgallagh: burn that bridge when we get to it!
17:00:02 <sgallagh> adamw: My favorite mixed metaphor!
17:00:25 <kparal> I read 'burn that village' and wasn't able to get it...
17:00:37 <roshi> sgallagh: it's the verbal version of how cortez treated ships... it drives us forward :p
17:01:06 <adamw> sgallagh: it's no mixed metaphor, it's a QA SOP
17:01:22 <kparal> danofsatx: is the patch coming, or should we vote?
17:01:23 <roshi> ^ that :)
17:01:43 <danofsatx> vote, my brain ain't working
17:02:06 <kparal> ack
17:02:11 <sgallagh> roshi: My second favorite is "We don't want any loose cannons rocking the boat."
17:02:37 <roshi> People in glass houses sink ships, you know
17:02:52 <roshi> that's a good one, hadn't heard it sgallagh
17:02:57 <roshi> acks?nacks?
17:03:30 <roshi> eh, patch
17:03:41 <sgallagh> patch: "A simple workaround exists for the bug, so it's not considered severe enough to block Beta. The CommonBugs page will be updated with the workaround."
17:03:47 <adamw> ack
17:03:48 <roshi> proposed #agreed - 1071356 - RejectedBlocker - There is an easy to apply workaround for this bug so it's not considered blocking. CommonBugs page will be updated with the workaround.
17:03:53 <roshi> nvm
17:03:56 <jskladan> ack
17:03:57 * adamw acks anything
17:03:59 <kparal> ack
17:04:21 <roshi> proposed #agreed - 1071356 - RejectedBlocker - A simple workaround exists for the bug, so it's not considered severe enough to block Beta. The CommonBugs page will be updated with the workaround.
17:04:26 <roshi> #agreed - 1071356 - RejectedBlocker - A simple workaround exists for the bug, so it's not considered severe enough to block Beta. The CommonBugs page will be updated with the workaround.
17:04:30 <roshi> rather
17:04:33 <danofsatx> why did Bill the Cat suddenly come to mind?
17:04:48 <roshi> there's a cat named Bill?
17:04:49 <roshi> #topic (1155352) Fedora 21 Beta: Roles do not report firewall status via rolectl
17:04:52 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155352
17:04:55 <roshi> #info Proposed Blocker, rolekit, NEW
17:05:01 <roshi> we had a cat named dog once
17:05:19 <danofsatx> https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSfVRuIaX1eQrTUtTzpWqSyiAGmaX-Zi3-vE2WmtqZisLIDS_4hzbz7Xw
17:05:38 <roshi> lol
17:05:55 <sgallagh> roshi: I called a special vote of the Server WG.
17:06:07 <sgallagh> We agreed to strike the violating criteria for F21.
17:06:17 <kparal> if it has not been implemented, is it reasonable to have it as a blocker?
17:06:26 <kparal> I have to say I have no idea what rolectl is
17:06:43 <sgallagh> kparal: It's the CLI for rolekit
17:06:43 <roshi> me either
17:06:52 * jsmith knows what it is!
17:06:57 <sgallagh> Which is the service implementing Server Roles for Fedora Server
17:07:29 <kparal> that didn't enlighten me much :)
17:07:53 <kparal> but I can google for that, no problem
17:08:03 * adamw wishes we'd just not put the criterion in in the first place if it wasn't going to get done, but...
17:08:03 <sgallagh> kparal: 'rolectl deploy --settingsfile=settings.json domaincontroller' will give you a FreeIPA Domain Controller
17:08:08 <sgallagh> (For example)
17:08:30 <adamw> sgallagh: where's the record of said special meeting, so we can link to it here?
17:08:45 <sgallagh> adamw: Look at server@
17:08:50 <sgallagh> Just a sec
17:09:00 <sgallagh> (I also CCed you directly)
17:09:05 <danofsatx> it was a special vote, not a special meeting.
17:09:21 <danofsatx> (If I read that right)
17:09:26 <sgallagh> https://lists.fedoraproject.org/pipermail/server/2014-October/001520.html
17:09:36 <sgallagh> adamw: ^^
17:09:45 <adamw> thanks
17:10:04 <roshi> so, no vote since they don't want that criteria anymore?
17:10:13 <sgallagh> Well, -1 blocker
17:10:26 <sgallagh> "Does not violate any Beta criteria"
17:10:34 <roshi> I figure we'd un-nominate it and be done
17:10:51 <sgallagh> Either way
17:11:39 <roshi> proposed #agreed - 1155352 - RejectedBlocker - Per ServerWG vote [0], this doesn't violate any criteria. \n [0] https://lists.fedoraproject.org/pipermail/server/2014-October/001520.html
17:11:40 <adamw> i can withdraw the nomination
17:11:43 <adamw> no-one needs to vote on that
17:12:00 <roshi> wfm - moving on then
17:12:12 <roshi> #topic (1155301) SELinux denies certmonger dbus requests during FreeIPA deployment with rolekit
17:12:14 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155301
17:12:17 <roshi> #info Proposed Blocker, selinux-policy-targeted, NEW
17:12:21 <danofsatx> +1
17:13:28 <sgallagh> I spoke with mgrepl today, he assigned lvrabec to address this. I haven't seen a build yet, so I don't know if this is likely to make tonight's compose.
17:13:52 <sgallagh> Do we still have a chance of tomorrow night's compose being the Beta, or is that too close to the Go/No-Go?
17:14:15 <roshi> there's a *chance* but would require some heroic testing of the next compose
17:14:34 <kparal> heroic testing is our favorite activity
17:14:55 * roshi wonders if there's any money left in the Fedora Bourbon fund for the occassion...
17:15:49 <sgallagh> How much could an selinux-policy update really break?
17:15:59 <jsmith> roshi: I think I have a drink ticket left over from Flock, if that helps...
17:16:01 <sgallagh> (tongue firmly in cheek)
17:16:08 <jsmith> sgallagh: :-)
17:16:19 <adamw> er
17:16:19 <adamw> we'd have to compose today.
17:16:19 <adamw> go/no-go is tomorrow.
17:16:26 <roshi> yeah
17:16:31 <adamw> i have a mail from mgrepl which seems to indicate that the current selinux-policy build should fix this
17:16:33 <adamw> but it's not very clear
17:16:35 * dustymabe returns
17:16:46 <roshi> if a compose landed today, we could *theoretically* get the testing done for it
17:16:50 <adamw> > oh, I see :) will do! today's the last chance to do RC1 if we have any
17:16:50 <adamw> > hope of signing off on Beta tomorrow, so if you could have an
17:16:50 <adamw> > selinux-policy build with the fixes for the blockers when I wake up
17:16:50 <adamw> > that'd be really good :) thanks!
17:16:52 <adamw> The latest policy build would fine.
17:16:52 <adamw> selinux-policy-3.13.1-88.fc21
17:16:52 <roshi> if the cloud images show up this time
17:16:54 <adamw> <http://koji.fedoraproject.org/koji/buildinfo?buildID=586946>
17:18:54 <adamw> i wasn't very clear when I said 'the blockers', though, so he may not have realized about the freeipa blocker bugs
17:18:54 <adamw> sgallagh: did you get to testing it yet?
17:18:54 <adamw> anyway, +1, i really don't think this is fudge-able. server is part of f21, this is the basic point of server, this is the f21 beta release, it should work.
17:19:09 <sgallagh> adamw: I've been in this meeting and FESCo since that comment
17:19:10 <sgallagh> So no
17:19:25 <adamw> me either
17:19:28 <roshi> +1
17:19:30 <sgallagh> But yeah, +1 blocker
17:19:31 <adamw> lemme fire up an install now
17:19:37 <sgallagh> (and testing it is first on my list after this)
17:19:46 <danofsatx> I'll combine it with the bind update testing in about an hour
17:22:12 <roshi> proposed #agreed - 1155301 - AcceptedBlocker - This bug is a clear violation of the Roles beta criteria: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully started, stopped, brought to a working configuration, and queried."
17:22:36 <sgallagh> Ack
17:22:51 <kparal> ack
17:22:51 <adamw> ack
17:22:55 <danofsatx> ack
17:23:36 * sgallagh has to focus on FESCo for a little while
17:23:45 <sgallagh> ping me if there are direct questions I need to answer, please
17:23:46 <roshi> #agreed - 1155301 - AcceptedBlocker - This bug is a clear violation of the Roles beta criteria: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully started, stopped, brought to a working configuration, and queried."
17:23:51 <roshi> will do sgallagh
17:24:06 <roshi> #topic (1155329) SELinux is preventing named from create access on the file DNS_25 (during FreeIPA deployment via rolekit, F21 Beta TC4)
17:24:09 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155329
17:24:11 <roshi> #info Proposed Blocker, selinux-policy-targeted, NEW
17:24:15 <danofsatx> +1
17:24:44 <roshi> +1
17:25:15 <dustymabe> +1
17:26:42 <roshi> proposed #agreed - 1155329 - AcceptedBlocker - This bug violates the Roles beta criteria: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully started, stopped, brought to a working configuration, and queried."
17:27:17 <adamw> it's a bit hard to be sure if these others actually break deployment
17:27:23 <adamw> since you can't test with enforcing because you hit the other one first
17:27:28 <roshi> yeah
17:27:29 <adamw> but probably safest to accept for now
17:27:30 <adamw> +1
17:27:31 * kparal was about to say the same thing
17:27:42 <kparal> +1
17:27:43 <dustymabe> adamw: yeah. i imagine more information will come once the other one gets fixed?
17:28:26 <adamw> yeah, we can re-vote if one of the others turns out to be trivial or something
17:28:48 <roshi> wfm
17:28:57 <roshi> ack/nack/patch?
17:29:38 <adamw> ack
17:29:45 <danofsatx> ack
17:29:50 <danofsatx> thpppt
17:30:08 <dustymabe> dumb question: whats the difference between +1 and ack in this context ?
17:30:08 <roshi> #agreed - 1155329 - AcceptedBlocker - This bug violates the Roles beta criteria: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully started, stopped, brought to a working configuration, and queried."
17:30:09 <jskladan> ack
17:30:24 <adamw> dustymabe: we vote on whether the bug is a blocker
17:30:33 <adamw> dustymabe: then we ack or nack or patch the 'agree' that explains why
17:30:40 <dustymabe> ahh. got it
17:30:43 <dustymabe> adamw: thanks
17:30:52 <adamw> dustymabe: the vote is set once it's been taken, but sometimes there's a mistake in the text or someone has an improvement or whatever
17:31:03 <roshi> that's it for proposed blockers
17:31:27 <roshi> onto the FEs, unless there's compelling reason to review accepted blockers first
17:33:00 <danofsatx> gotta run. have fun.
17:33:05 <roshi> later danofsatx
17:33:09 <roshi> onto FEs then
17:33:17 <roshi> #topic (1155026) Missing addon results in a traceback when %addon header options are specified
17:33:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155026
17:33:22 <roshi> #info Proposed Freeze Exceptions, anaconda, POST
17:33:24 <adamw> i thought i nominated three selinux freeipas?
17:33:53 <roshi> must not have been pulled in by blocker bugs
17:34:00 * adamw checks
17:34:17 <adamw> oh
17:34:25 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1155304 got closed as a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1155301
17:34:36 <adamw> which seems a bit odd, but i guess mgrepl knows what he's doing
17:34:58 <roshi> so we good to move to FE?
17:35:14 <adamw> sure
17:36:44 * roshi isn't sure if this is worth breaking freeze for
17:37:06 <roshi> seems to only affect kickstarts with the %addon in it
17:37:08 <adamw> roshi: did we vote on https://bugzilla.redhat.com/show_bug.cgi?id=1104682 ?
17:37:56 <roshi> not that I recall
17:38:02 <dustymabe> adamw: I know we did last time. I don't know about today
17:38:13 <dustymabe> last time we decided to leave it until we got more information
17:38:16 <roshi> not today I don't thinkg
17:38:34 <adamw> well, we got extra info
17:38:43 <adamw> to me it sounds like -1 blocker since it seems to require an unusual machine config
17:39:32 <roshi> same here
17:40:10 <roshi> -1
17:40:17 <adamw> roshi: can you change #topic ?
17:40:23 <roshi> yeah
17:40:25 <dustymabe> sounds good to me
17:40:27 <dustymabe> -1
17:40:53 <roshi> #topic (1104682)  DomU boot failure: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-udevd:161]
17:41:54 <roshi> proposed #agreed - 1104682 - RejectedBlocker - This bug is predicated on having a less than common machine config and isn't considered serious enough in light of that to be considered a blocker.
17:42:40 <dustymabe> ack
17:42:46 <adamw> ack
17:42:55 * dustymabe pretends that he knows what he is doing
17:42:56 <roshi> #agreed - 1104682 - RejectedBlocker - This bug is predicated on having a less than common machine config and isn't considered serious enough in light of that to be considered a blocker.
17:43:09 <roshi> then you know what you're doing, dustymabe
17:43:11 <roshi> :p
17:43:24 <roshi> #topic (1155026) Missing addon results in a traceback when %addon header options are specified
17:43:31 <roshi> ok, back to the FE
17:44:16 <roshi> votes?
17:46:22 * adamw finds the url
17:46:32 <adamw> dustymabe: that's what the rest of us are doing too ;)
17:46:40 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1155026
17:46:48 <dustymabe> ok so in for FE we are voting if we are going to allow a change to be made?
17:47:13 <roshi> yeah
17:47:19 <dustymabe> i just searched google.. found this: http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
17:47:21 <roshi> is it worth breaking the freeze to get this fix in
17:47:29 <dustymabe> got it. that's what I thought
17:47:31 <roshi> that's the doc you want :)
17:48:25 <adamw> dustymabe: that's what we're working off, yup :)
17:48:31 <dustymabe> more or less we evaluate the risk of making the change. and determine if risk is worth the reward
17:48:41 <roshi> yup
17:49:09 <adamw> i'm not clear on whether this is affecting our *default* configuration
17:49:09 <roshi> I don't know that this bug is worth breaking freeze for
17:49:24 <adamw> but it doesn't seem like anyone's complained that they got locked out of their install or anything...
17:49:32 <roshi> it struck me as only kickstarts with %addon in it
17:49:39 <adamw> i'd be -1-repropose-with-details or punt, i guess
17:49:52 <roshi> -1 and repropose wfm
17:49:59 <dustymabe> agreed
17:50:02 <dustymabe> -1
17:50:03 <kparal> c2 seems like describing a default install
17:50:27 <roshi> after the kickstart install, is how I read it
17:50:40 <kparal> yeah, that might be right
17:51:10 <adamw> yeah, i read it as "when you hit this bug, this is what happens"
17:51:18 <adamw> but it still didn't quite explain when you do actually hit the bug
17:51:33 <kparal> ok
17:51:51 <roshi> proposed #agreed - 1155026 - RejectedFreezeException - This bug doesn't seem to be hit enough to justify breaking freeze for. If it's more common than we know, please repropose with more information.
17:52:21 <kparal> maybe "more common than just for kickstart installations with %addon specified"?
17:52:30 <adamw> ack either way
17:52:33 <roshi> yeah, that's better
17:52:55 <roshi> #agreed - 1155026 - RejectedFreezeException - This bug doesn't seem to be hit enough to justify breaking freeze for. If it's more common than just for kickstart installations with %addon specified, please repropose with more information.
17:53:12 * roshi counted kparals patch as an ack for the patched version
17:53:22 <dustymabe> ack
17:53:29 <roshi> #topic (1145122) Provide more debug output on errors
17:53:29 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1145122
17:53:29 <roshi> #info Proposed Freeze Exceptions, initial-setup, POST
17:54:12 <roshi> pwhalen: did you get around to testing this?
17:55:42 <pwhalen> roshi, yes. It ran okay on both the KDE and minimal images
17:56:22 <pwhalen> not sure if running it was all that was needed, if so.. ship it
17:56:28 <pwhalen> :)
17:56:49 <adamw> running OK was what i was concerned about'
17:57:06 <roshi> that's what I thought was the reason
17:57:21 <roshi> +1 (moar debugging information is always welcome)
17:57:42 <adamw> i can be +1 to this, though i'd probably make an executive decision not to pull it in if we trry a hero RC1 today/tomorow somehow
17:57:47 <adamw> but if we wind up slipping, sure
17:57:56 <roshi> that works for me
17:58:11 <pwhalen> adamw, that sounds good to me too
17:58:25 <dustymabe> +1
17:59:17 <kparal> sounds good
18:00:42 <roshi> proposed #agreed - 1145122 - AcceptedFreezeException - This fix would be greate to get pulled in. However, only if the Beta release slips so we have time to test it properly.
18:00:49 * roshi wasn't sure the best way to word that one
18:00:51 <kparal> ack
18:00:58 <roshi> s/greate/great
18:01:35 <roshi> pwhalen: could you update the bug that you tested it and all was good from your pov?
18:01:57 <dustymabe> ack
18:02:18 <pwhalen> roshi, will do
18:02:20 <roshi> #agreed - 1145122 - AcceptedFreezeException - This fix would be great to get pulled in. However, only if the Beta release slips so we have time to test it properly.
18:02:23 <roshi> thanks
18:02:31 <roshi> #topic (1149782) liveusb-creator creates non-booting Live USB
18:02:31 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1149782
18:02:31 <roshi> #info Proposed Freeze Exceptions, liveusb-creator, NEW
18:03:02 <roshi> -1 on this one
18:03:10 <roshi> luc works fine on the official releases
18:03:22 <roshi> working on F21 is more of a non-issue and can be fixed with updates
18:03:47 <kparal> maybe we can advice satellit to just dd the stick with zeroes first. I remember I had to do that a few times, before luc started to work. simple reformatting didn't help
18:03:56 <kparal> but in most cases it seems to work
18:04:36 <adamw> it seems luc on f21 has problems because of syslinux 6
18:04:37 <satellit_e> I use gparted to rebuild the mbr to fix it also
18:04:49 <adamw> but yeah, -1, it doesn't need to be fixed in the frozen set
18:06:05 <satellit_e> seems to proble is dd makes formatting that is then incompatable with LUC
18:06:10 <roshi> proposed #agreed - 1149782 - RejectedFreezeException - Liveusb-creator works fine on F20 and F19 and a fix to this on F21 can be supplied via updates, so no need to pull it into the frozen package set.
18:06:56 <dustymabe> ack
18:08:42 <adamw> ack
18:08:53 <roshi> #agreed - 1149782 - RejectedFreezeException - Liveusb-creator works fine on F20 and F19 and a fix to this on F21 can be supplied via updates, so no need to pull it into the frozen package set.
18:09:04 <roshi> #topic (1149610) CVE-2014-7272 sddm: several local privileges escalation issues
18:09:07 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1149610
18:09:10 <roshi> #info Proposed Freeze Exceptions, vulnerability, NEW
18:09:50 <roshi> +1
18:10:53 <dustymabe> +1
18:11:39 <adamw> +1
18:11:58 <roshi> proposed #agreed - 1149610 - AcceptedFreezeException - Please pull this fix into the next compose despite freeze.
18:12:17 <kparal> ack
18:12:56 <adamw> ack
18:13:11 <dustymabe> ack
18:13:16 <roshi> #agreed - 1149610 - AcceptedFreezeException - Please pull this fix into the next compose despite freeze.
18:14:09 <roshi> as for checking on the accepted blockers - looks like we only have 2 NEW ones
18:14:44 <roshi> the SELinux ones...
18:16:33 <roshi> do we need to go over any others adamw ?
18:16:35 <adamw> fedup-dracut and ntfs, too.
18:16:49 <roshi> yeah
18:16:55 <adamw> cmurf and dlehman have been working on ntfs
18:17:02 <adamw> looks like they're getting somewhere
18:17:10 <adamw> i know wwoods has been working on fedup-dracut, not sure of the eta
18:17:18 <adamw> sgallagh is trying to get someone to fix the selinux issues
18:17:26 <adamw> sgallagh: you have a fix for the named crasher already, right?>
18:17:50 <roshi> looks like they're getting the attention they need though, which is good
18:20:44 <adamw> yeah, my next step is to check in with dlehman and wwoods
18:21:55 <roshi> so we can go ahead and end this meeting, from what I can tell
18:22:04 <adamw> yeah, i think we're done here
18:22:12 <roshi> #topic Open Floor
18:22:28 <roshi> anybody have anything they want to bring up before I light this fuse?
18:22:34 <danofsatx-lt> I'm back ;)
18:22:35 <dustymabe> roshi: nope.
18:22:46 <roshi> anything for open floor danofsatx-lt ?
18:22:59 <danofsatx-lt> nope, I don't think so
18:23:01 * roshi sets the fuse
18:24:03 <dustymabe> later guys!
18:24:10 <roshi> later!
18:24:12 <roshi> thanks for coming
18:24:15 <roshi> #endmeeting