16:02:59 <adamw> #startmeeting Fedora QA meeting
16:02:59 <zodbot> Meeting started Mon Nov 19 16:02:59 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:01 <adamw> #meetingname fedora-qa
16:03:01 <zodbot> The meeting name has been set to 'fedora-qa'
16:03:03 <adamw> #topic roll call
16:03:05 <adamw> morning folks, how're we diddling?
16:03:09 * tflink is here
16:03:15 * mkrizek is here
16:03:23 * satellit_e listening
16:03:28 <tflink> adamw: as long as you didn't ask who/what :-D
16:03:29 <jreznik> me is here and there
16:03:33 * nirik is lurking
16:03:49 * kparal around
16:04:01 <adamw> tflink: your diddlin' time is your own
16:04:05 * akshayvyas listening
16:04:14 <akshayvyas> what
16:04:21 <akshayvyas> sorry
16:04:33 <akshayvyas> i am here
16:04:39 * dan408_ is somewhat here
16:05:38 <adamw> big group
16:05:42 * adamw invokes more chairs
16:05:49 * tflink runs
16:05:59 * dan408_ throws chair at tflink
16:06:19 <tflink> too late, I already ran :)
16:06:27 <adamw> wow, he's psychic
16:06:30 <adamw> alrighty
16:06:30 * tflink hides in case of another chair
16:06:34 <adamw> #topic previous meeting follow-up
16:06:43 <adamw> and dan ballmer, quit it ;)
16:06:49 <dan408_> ballmer?!?!
16:06:52 <dan408_> wtf!
16:07:04 <adamw> hey, you start throwing chairs, you get called ballmer
16:07:06 <tflink> you never saw the video of him throwing a chair?
16:07:12 <dan408_> no
16:07:14 <dan408_> links or gtfo
16:07:25 * adamw wonders if they switched out all the furniture in his office for bits made out of foam and stuck to the floor before they released win8
16:07:37 <adamw> i don't think there's video of the Chair Incident is there?
16:07:45 <adamw> it was really just hearsay. there's video of the Monkey Dance.
16:07:45 <jreznik> chair incident?
16:07:48 <tflink> the googles will know
16:07:57 <adamw> oh ballmer, such a reliable source of humour
16:07:59 <dan408_> i guess he must be a distant cousin.. i threw a chair at rbergeron in another meeting
16:08:20 <adamw> well now we know who we SHOULD have sent to the secure boot negotiations...
16:08:32 <adamw> dan408: http://www.theregister.co.uk/2005/09/05/chair_chucking/
16:08:47 <dan408_> oh i would throw a lot more than a chair at ballmer
16:08:56 <adamw> alrighty!
16:09:10 <adamw> i left 'previous meeting follow-up' on the agenda though i think there were no action items from the last meeting
16:09:12 <dan408_> wow okay
16:09:16 <adamw> anything to follow up on that wasn't action'ed?
16:09:36 <tflink> has the partitioning stuff been done?
16:09:42 <jreznik> adamw: lol (for that chair article!)
16:09:43 * tflink doesn't remember off hand
16:10:01 <adamw> tflink: the criteria? no. please stop remembering i'm supposed to be doing that. :)
16:10:05 <dan408_> adamw: dont know if this was brought to your attention but there is bug with systemd
16:10:11 <dan408_> let me see if i can find it
16:10:14 <adamw> dan408: we'll get to f18 in a minute
16:10:19 <dan408_> oh ok
16:10:32 <adamw> tflink: i was attempting to quietly slip that one off the agenda, curse you
16:11:02 <dan408_> LOL
16:11:31 <adamw> so anything apart from my deep and ongoing shame to discuss at this point? :P
16:11:51 <tflink> for followup? Nothing I can think of, no
16:12:10 <adamw> alrighty, moving on
16:12:15 * tflink still needs to finish test cases etc. for fedup but that's never been an action item
16:12:20 <tflink> in a meeting
16:12:29 <adamw> #topic Fedora 18 Beta status / mini blocker review
16:12:39 <adamw> shall we knock off the blocker review first?
16:12:51 * jreznik is ok with that
16:13:00 <akshayvyas> sure
16:13:55 <adamw> #chair tflink
16:13:55 <zodbot> Current chairs: adamw tflink
16:13:58 <adamw> you ready to roll?
16:14:12 <tflink> up for review today, we have:
16:14:21 <tflink> #info 4 Proposed Blockers
16:14:28 <tflink> #info 3 Proposed NTH
16:14:38 <tflink> #topic (876789) FormatDestroyError: error wiping old signatures from /dev/md/Volume0_0p2: 1
16:14:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876789
16:14:44 <tflink> #info Proposed Blocker, anaconda, NEW
16:15:32 <adamw> so this is the latest bug in my odyssey of an attempt to try and get a working Intel fw RAID-1 install
16:15:46 <tflink> workaround: don't use raid?
16:15:49 <tflink> :)
16:15:55 <jreznik> adamw: well, I spent the morning with Jes - he was able to install on intel raid...
16:15:56 <adamw> well, schyeah
16:16:01 <adamw> yeah i was just about to note that
16:16:08 <adamw> if Jes is able to do an install now, we might call this fixed-enough-for-beta
16:16:13 <nirik> tflink: don't use fakeraid anyhow. ;)
16:16:18 * tflink just finished a smoke build with this anaconda
16:16:24 <adamw> jreznik: and thanks for that
16:16:30 <dan408_> move it to a f19 NTH
16:16:31 <tflink> there is no raid like fakeraid ...
16:17:05 <jreznik> adamw: follow the sun policy to rule all the bugs out :D as our GSS does :)
16:17:18 <adamw> jreznik: as long as you can find one person it works for, it's fine? :)
16:17:42 <nirik> so whats the difference between his setup and adamw's?
16:17:51 <adamw> nirik: no idea
16:17:51 <jwb> it works?
16:17:55 <jreznik> nirik: that's the question
16:17:57 <adamw> ba-dum tish
16:18:03 <adamw> jwb will be appearing all week, tip your server
16:18:17 <dan408_> omg
16:18:30 <jreznik> in adam's case, wipefs -a /dev/md/Volume0_0 is called, in Jes case wipefs -a /dev/md/IMSM00_0p3
16:18:47 <nirik> huh. might be firmware version?
16:18:53 <adamw> eh? no, that's not right.
16:19:03 <adamw> in my case it's /dev/md/Volume0_0p2
16:19:18 <adamw> which is effectively more or less the same thing, just my array is called Volume0 and Jes' is IMSM00 .
16:19:59 <adamw> that's just a function of the RAID BIOS. mine lets me change the name if I want. I could call it RAIDSUCKS and have RAIDSUCKS_0p2...
16:20:00 <nirik> whats the beta critera? all raid ?
16:20:07 <jreznik> in log, I see Volume0_0
16:20:17 <adamw> 19:16:48,018 INFO program: Running... wipefs -a /dev/md/Volume0_0p2
16:20:18 <adamw> 19:16:48,026 ERR program: wipefs: error: /dev/md/Volume0_0p2: probing initialization failed: Device or resource busy
16:20:24 <adamw> that's my log.
16:20:27 <jreznik> ah, both
16:20:52 <jreznik> and it fails on the second, ok
16:20:59 * jreznik just got confused...
16:20:59 <dan408_> could just be a bug in the package itself
16:20:59 <tflink> nirik: it's written as all RAID but in practice, we don't block for everything
16:21:16 <nirik> "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
16:21:18 <adamw> well, it's written thus: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot "
16:21:19 <adamw> yeah
16:21:29 <adamw> historically we've interpreted that 'capable' quite generously
16:21:34 <adamw> pretty much 'as long as it works for someone it's okay'
16:21:39 <nirik> yeah.
16:21:46 <jreznik> at least we have a report, someone is able to do the install... so we do not know why it does not work for adamw and if it's only adamw's issue (and how many people do want to install on intel hw raid?)
16:21:48 <tflink> it would be nice to have more than 2 data points, though
16:21:53 <adamw> sigh. 'able', not 'capable'. /me goes back to bed
16:21:58 <nirik> I'd be ok with punting this to NTH given that it worked for another person and failing more datapoints.
16:22:15 <adamw> jreznik: it's probably one of the most common forms of RAID, but i'm with nirik - NTH for now
16:22:30 <jreznik> ok
16:22:33 <dan408_> adamw: i can do a test again at work for you today if you want
16:22:42 <akshayvyas> NTH for final??
16:22:51 <adamw> jreznik: the fact it's not trying to do /dev/IMSM00_0 for jes to me suggests that maybe he did an install without wiping the entire array? did he install alongside something else?
16:23:03 <adamw> akshayvyas: no, it'd be NTH for beta.
16:23:06 <nirik> no, NTH for beta
16:23:10 * nirik has lag today. :)
16:23:16 <adamw> dan408: yeah that'd probably be neat
16:23:19 <adamw> thanks
16:23:24 <nirik> ie, if a fix falls from the sky we can look at pulling it in, or... not.
16:23:29 <adamw> dan408: just grab tc9 and try installing to RAID-1 (or hell, RAID-5 or whatever)
16:23:51 <tflink> the working install was with TC9?
16:23:58 * jreznik is pinging Jes
16:24:07 <dan408_> adamw: right but software raid
16:24:12 <dan408_> not hardware
16:24:18 <dan408_> right?
16:24:19 <adamw> dan408: intel firmware
16:24:21 <adamw> if you have it
16:24:26 <dan408_> um
16:24:31 <adamw> actual pure linux softraid seems okay here, i tested that
16:24:47 <dan408_> the hardware raid i tested was Dell SAS 6/ir
16:24:55 <dan408_> finding intel raid will be tough
16:25:00 <adamw> no problem then
16:25:05 <adamw> so is anyone against -1 blocker / +1 nth?
16:25:13 <dan408_> no
16:25:14 <jreznik> well, I'm +1 nth
16:25:24 <dan408_> -1 blocker
16:25:26 <akshayvyas> +1 nth
16:25:28 <tflink> the only thing I can think of is to wait until wednesday to demote from blocker
16:25:30 <dan408_> hardware raid is tested and it works
16:25:31 <brunowolff> If this is tied to specific hardware, don't we want to consider how common this hardware is?
16:25:54 <brunowolff> Perhaps relative to other fakeraid hardware people might be using.
16:25:55 <dan408_> brunowolff: extremely uncommon
16:26:11 <adamw> er, that might be overstating it
16:26:18 <dan408_> okay
16:26:21 <adamw> if you have raid on your motherboard these days it's likely intel
16:26:21 <dan408_> somewhat uncommon
16:26:25 <dan408_> wrong
16:26:29 <tflink> AFAIK, this is the most common BIOS raid right now or one of the more common ones anyways
16:26:35 <adamw> but right now, we don't know how many work and how many don't.
16:26:43 <dan408_> all Dell servers use Dell raid
16:26:48 <tflink> dan408_: most of my machines have some form of intel BIOS raid, I don't see how it's uncommon
16:26:55 <adamw> dan408: sorry, i was thinking consumer hw, you might be right about server.
16:26:55 <tflink> for desktops, not servers
16:26:55 <dan408_> so you'd have to have an intel made motherboard with raid
16:27:04 <dan408_> yeah
16:27:06 <dan408_> desktops
16:27:14 <adamw> dan408: not intel made, just pretty much any consumer board for intel
16:27:16 <dan408_> and how many people install to hardware raid on an intel desktop?
16:27:20 <adamw> mine's Asus.
16:27:22 <tflink> dan408_: a mobo w/ intel chipset and SB, not just intel made
16:27:30 <dan408_> right
16:27:34 <adamw> we have no idea, really. smolt doesn't track that.
16:27:34 <dan408_> that's what i just said
16:27:44 <dan408_> im telling you it's very uncommon
16:27:47 <dan408_> and it's an intel problem
16:28:01 <dan408_> -1 blocker +1 nth
16:28:30 <tflink> dan408_: all of my recent intel machines have intel bios RAID, how is that uncommon
16:28:36 <brunowolff> But since fakeraid is supposed to work, we might really want to know what fraction of fakeraid setups fail rather than what fraction of desktop users are affected.
16:28:42 <tflink> the only one that doesn't is a 10 year old P4 box
16:28:42 <adamw> guys, we're nearly at 30 mins already
16:28:44 <dan408_> tflink: and how often do you use it
16:28:46 <tflink> sorry
16:28:49 <adamw> if no-one wants to make this a blocker, let's just move on
16:29:00 <tflink> are we rejecting blocker?
16:29:03 <adamw> brunowolff: right, but we just don't have data for that, is the problem - not many people are set up to test it
16:29:21 <dan408_> ^which means it's an uncommon setup
16:29:24 <adamw> brunowolff: right now we have one pass one fail, so it's 50/50 =)
16:29:57 <adamw> dan408: well not necessarily, because if you're using it _in production_, you'd need two spare drives and the willingness to fiddle about disconnecting them in order to _test_ it. which is what i have to do and it drives me nuts.,
16:30:15 <brunowolff> My inclination is NTH and not blocker without a better idea of the impact on fakeraid testing.
16:30:15 <dan408_> if you're using it in "production" you're using a server
16:30:17 <adamw> but anyway, we're just kicking the can now.
16:30:23 * tflink will try to get a test done today
16:30:25 <dan408_> if you're using a server you're most likely not using intel raid
16:30:27 <adamw> dan408: i mean, if you're using it for your everyday usage
16:30:36 <dan408_> okay
16:30:37 <dan408_> let's move on
16:30:48 <adamw> yeah, i don't see anyone voting anything but +NTH -blocker.
16:31:00 <tflink> I'm wondering about doing it today but yeah
16:31:06 <adamw> we can always revisit.
16:31:17 <jreznik> yep
16:31:19 <adamw> fwiw, i know dlehman was leaning in that direction too.
16:31:52 <jreznik> ok, proposal!
16:32:23 <tflink> proposed #agreed 876789 - RejectedBlocker - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose
16:32:36 <dan408_> +1
16:32:37 <akshayvyas> ack
16:32:37 <adamw> patch acceptednth
16:32:40 <brunowolff> ack
16:32:40 <dan408_> ack
16:32:41 <nirik> ack
16:32:50 <jreznik> patch, see adamw
16:32:50 <tflink> adamw: it's already accepted NTH
16:32:54 <adamw> oh, it is?
16:33:00 <adamw> i don't see that.
16:33:16 <tflink> damn it, I'm looking at the wrong bug somehow
16:33:19 <jreznik> tflink: on, it isn't
16:33:21 <adamw> heh.
16:33:28 <jreznik> s/on/no :)
16:34:12 * dan408_ throws a chair at adamw
16:34:23 <tflink> proposed #agreed 876789 - RejectedBlocker, AcceptedNTH - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose as a blocker. Accepted as NTH because it can't be fixed with an update and is currently affecting 50% of intel FWRAID installs.
16:34:31 * adamw catches chair, throws it back
16:34:36 <adamw> ack
16:34:38 <jreznik> ack
16:34:42 <adamw> heh, '50%' :)
16:34:54 <tflink> 1 of 2 is 50%
16:35:01 <adamw> technically true!
16:35:13 <tflink> proposed #agreed 876789 - RejectedBlocker, AcceptedNTH - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose as a blocker. Accepted as NTH because it can't be fixed with an update and is currently affecting 50% of reported intel FWRAID installs.
16:35:16 <brunowolff> ack
16:35:20 <jreznik> all two intel hw raid users :)
16:35:24 <tflink> #agreed 876789 - RejectedBlocker, AcceptedNTH - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose as a blocker. Accepted as NTH because it can't be fixed with an update and is currently affecting 50% of reported intel FWRAID installs.
16:35:27 <dan408_> sigh
16:35:37 <tflink> #topic (875278) AttributeError: 'NoneType' object has no attribute 'type'
16:35:39 <adamw> jreznik: testers.
16:35:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875278
16:35:42 <tflink> #info Proposed Blocker, anaconda, ON_QA
16:35:50 <jreznik> adamw: developer and tester :)
16:36:25 <dan408_> this is fixed i believe
16:37:03 <kparal> already accepted as NTH, do we need to discuss blocker atm?
16:37:16 <tflink> we could skip it for now, sure
16:38:01 <tflink> any other thoughts?
16:38:03 <dan408_> skip
16:38:28 <adamw> yeah, since it's nth and the fix is in the new anaconda build, just move on
16:39:03 <tflink> #info this has been accepted as NTH and a fix is in the most recent anaconda build - skipping review for today
16:39:09 <tflink> #topic (877623) fedup does not seem to verify the update source
16:39:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=877623
16:39:10 <tflink> #info Proposed Blocker, fedup, NEW
16:39:15 <tflink> I didn'
16:39:22 <tflink> t realize this was proposed as a blocker
16:39:27 <adamw> surprise!
16:39:31 * tflink isn't sure it's valid, much less a blocker
16:40:01 <adamw> not checking signatures is kinda bad.
16:40:12 <adamw> we only accept that for the DVD installer on the basis that the DVD as a whole is signed.
16:40:29 <nirik> the only way I could see this being a blocking is a pretty broad reading of "The upgraded system must meet all release criteria."
16:40:39 <dan408_> it's fedup with signatures
16:40:48 <adamw> nirik: heh, i hereby award you a black belt in criteria judo
16:40:51 <dan408_> /fedup joke of the day
16:40:56 * adamw wipes away tear
16:40:58 <adamw> he's grown...so much
16:41:00 <tflink> who ever said it isn't checking signatures?
16:41:02 <dan408_> hahaha
16:41:03 <nirik> :)
16:41:09 <adamw> "Also the code does not show any sign of proper cryptographic verification of updates."
16:41:14 <nirik> tflink: the code did. ;)
16:41:14 <tflink> that's the assertion, sure
16:41:18 <tflink> I don't buy it, though
16:41:21 * tflink has seen the code
16:41:26 <adamw> well yeah. i'm taking the face of the report.
16:41:40 <nirik> # TODO check signatures of downloaded packages
16:41:42 <adamw> if you or will said 'no, you're wrong, it DOES check signatures and here's the code', it'd be pretty much a non-issue.
16:41:45 <tflink> I can double check or we can ask will but I'm pretty sure that yum checks the sha256 in the background before downloading stuff
16:41:46 <nirik> https://github.com/wgwoods/fedup/blob/master/fedup/download.py
16:42:05 <jreznik> wwoods: ping, are you around?
16:42:09 <adamw> this might be a case for our newly-minted final criterion, since this is clearly a security issue.
16:42:22 <tflink> yeah, it is checking
16:42:37 <nirik> tflink: oh? where?
16:42:39 <tflink> line 223
16:42:47 <tflink> urlgrab is checking transparently
16:43:22 <nirik> those are the images? not the packages?
16:43:42 * nirik re-reads the bug, perhaps I misunderstood which it was about
16:43:43 <tflink> yeah, those are the initramfs and vmlinuz
16:43:52 <adamw> the report is about checking the *packages*, i believe.
16:44:00 <tflink> I thought it was about the images
16:44:03 <adamw> "Therefore it seems that it is prone to man-in-the-middle attacks or maybe allows to install packages from compromised mirrors without any verification"
16:44:08 <tflink> since the complaint is about my side repo
16:44:24 <nirik> I think they are kinda mixing the two...
16:44:38 <tflink> doesn't yum do checksums by default?
16:44:50 <adamw> yeah, i don't think it's a great report, but it seems kinda the case that if it's not checking signatures of packages before installing them, that's bad. there's a reason we sign them and yum checks the signatures.
16:45:04 <adamw> yum checks GPG signatures by default, but i've no idea if that happens in fedup.
16:45:14 <tflink> fedup uses yum
16:45:15 <nirik> I think it is checking the size or something, but not the gpg sig for sure.
16:45:27 <tflink> punt for more info?
16:45:33 <adamw> yeah, i was gonna say that.
16:45:45 <adamw> 1) ask till to clarify exactly what he thinks ought to be signed/checked, 2) ask will what is being signed/checked.
16:46:08 <jreznik> so called tillwill bug :)
16:46:38 <tflink> proposed #agreed 877623 - This needs more investigation before deciding on blocker status - what does the reporter think should be signed? Are the packages installed during upgrade checked before install?
16:46:49 <nirik> sure, ack
16:46:57 <jreznik> ack
16:47:56 <tflink> anyone else?
16:48:16 <adamw> ack
16:48:39 <tflink> #agreed 877623 - This needs more investigation before deciding on blocker status - what does the reporter think should be signed? Are the packages installed during upgrade checked before install?
16:48:44 <tflink> #topic (877567) Very weird bug gzip decompression bug in "recent" libxml2 versions
16:48:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=877567
16:48:50 <tflink> #info Proposed Blocker, libxml2, ASSIGNED
16:49:11 <tflink> +1 blocker
16:49:46 <tflink> since it messes with releng processes
16:50:29 <nirik> yeah, it's a weird one.
16:50:35 <nirik> +1 blocker here too.
16:50:43 <jreznik> another one from adamw in the bug
16:50:54 * nirik spent much of friday with geppetto doing the heavy lifting tracking this one down.
16:51:00 <jreznik> and sure, it's +1 blocker
16:51:17 <jreznik> nirik: with DV we came with that ugly hack - not checking CRC/len but ...
16:51:28 <adamw> yeah, seems an obv +1.
16:51:53 <nirik> also, it only seems to happen on that repo, so when we push something more to stable it might change...
16:51:54 <tflink> proposed #agreed 877567 - AcceptedBlocker - This prevents F18 composes and literally blocks release - therefore it is accepted as a blocker for F18 beta.
16:52:00 <nirik> ack
16:52:03 <kparal> ack
16:52:11 <mkrizek> ack
16:52:17 <tflink> #agreed 877567 - AcceptedBlocker - This prevents F18 composes and literally blocks release - therefore it is accepted as a blocker for F18 beta.
16:52:41 <tflink> #topic (877576) Dutch translation for anaconda is Polish
16:52:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=877576
16:52:41 <tflink> #info Proposed NTH, anaconda, NEW
16:52:43 <jreznik> nirik: well, so is this reproducible? or just broken for this one?
16:53:11 <nirik> yes, it's happening every day right now, preventing branched from composing.
16:53:28 <tflink> wow, this has been mixed up since january 2011?
16:53:30 <adamw> haha. dutch, polish, what's the difference amirite?
16:53:42 <kparal> we're in the NTH ones now
16:53:58 <tflink> dutch, polish ... it's all greek to me :)
16:54:02 <adamw> eh, there's only 3, we may as well power through em
16:54:03 <adamw> +1 nth
16:54:10 <tflink> +1 nth
16:54:31 <jreznik> +1 nth
16:54:45 <kparal> +1 nth
16:54:54 <tflink> proposed #agreed 877576 - AcceptedNTH - This is not fixable with an update and makes it harder to install using dutch localization. A tested fix would be accepted after freeze.
16:55:12 <adamw> ack
16:55:55 <jreznik> ack
16:56:29 <mkrizek> ack
16:56:41 <tflink> #agreed 877576 - AcceptedNTH - This is not fixable with an update and makes it harder to install using dutch localization. A tested fix would be accepted after freeze.
16:57:20 <adamw> 874753 has already been discussed and stalemate, so do the gnome one?
16:57:50 <tflink> either way, I think there is enough info in 874753 to break stalemate
16:57:57 <adamw> okay.
16:58:08 <tflink> #topic (874753) Can't change keyboard layout in GDM by default
16:58:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874753
16:58:08 <tflink> #info Proposed NTH, control-center, NEW
16:58:24 <adamw> -1 for me. this is basically working as intended. it may not be a great design, but we shouldn't twiddle with it as nth.
16:59:08 <kparal> -1
16:59:10 <tflink> proposed #agreed 874573 - RejectedNTH - This only affects keymaps added post-install and while it is inconvenient, could be fixed with an update.
16:59:13 <tflink> -1
16:59:15 <adamw> ack
16:59:21 <kparal> ack
16:59:22 <jreznik> ack
16:59:22 <dan408_> ack
16:59:23 <adamw> oh yeah, that too.
16:59:23 <nirik> ack
16:59:34 <tflink> #agreed 874573 - RejectedNTH - This only affects keymaps added post-install and while it is inconvenient, could be fixed with an update.
16:59:42 <tflink> #topic (876922) GNOME 3.6.2 as NTH for F18 Beta
16:59:42 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876922
16:59:42 <tflink> #info Proposed NTH, distribution, NEW
17:00:35 <dan408_> +1
17:00:40 <tflink> oy, not so sure about this one
17:00:57 <adamw> what karma do we have?
17:01:04 <tflink> when was it submitted for testing?
17:01:06 * nirik was just going to check that
17:01:13 <adamw> 11-14
17:01:18 <jreznik> it could be huge...
17:01:25 <adamw> has +5 karma, only one -1 which was a bogus report
17:01:26 <nirik> it has +5 karma
17:01:28 <nirik> yeah
17:01:40 <tflink> one day of testing?
17:01:46 <adamw> eh?
17:01:48 <adamw> five days
17:01:52 <tflink> nevermind
17:01:59 * adamw hands tflink a calendar
17:01:59 <tflink> I can't count this morning, apparently
17:02:09 <adamw> we could do smoke builds to check for dependency issues etc
17:02:23 <adamw> i vote +1 contingent on we do test DVD and live first to make sure compose works and is dep complete
17:02:30 <adamw> if that looks okay, go ahead with pulling to main
17:02:31 * nirik is ok with that too.
17:02:33 <dan408_> offtopic: there is an issue with gnome/systemd that i am thinking of proposing as NTH
17:02:35 <adamw> it's a bugfix release
17:03:02 <nirik> we should do so asap tho, so we could pull it in the rc1
17:03:13 <adamw> yeah, we could do that today. i can do a live, tflink can do a dvd.
17:03:35 <adamw> i wouldn't want to take a .0 at this point =) but gnome bugfix releases have a strong track record.
17:03:37 <herlo> don't want to interrupt, but if you are here for the FAmSCo meeting right now, we are meeting in #fedora-meeting-2.
17:03:44 <adamw> sorry herlo, we're nearly done
17:03:49 <herlo> adamw: no worries, we're moved
17:03:53 <jreznik> if testing would go ok, I'm ok too, a little bit scared from this one but...
17:04:01 <tflink> proposed #agreed 876922 - This will be accepted as NTH pending a test of Lives and DVD with the new GNOME builds. If there are no apparent issues, this would be taken past freeze.
17:04:05 <adamw> ack
17:04:07 <dan408_> ack
17:04:33 <brunowolff> ack
17:04:37 <nirik> ack
17:04:39 <tflink> #agreed 876922 - This will be accepted as NTH pending a test of Lives and DVD with the new GNOME builds. If there are no apparent issues, this would be taken past freeze.
17:05:00 <tflink> OK, that's all of the proposed blocker/nth bugs on my list
17:05:39 <adamw> ok
17:05:45 <adamw> thanks tflink
17:05:50 <adamw> #topic Fedora 18 Beta status
17:06:34 <jreznik> tflink: any news on fedup? I don't see packages, neither reply from wwoods (are you around) to mail email...
17:06:39 <adamw> so on general status...we now have two unaddressed blockers by my count
17:06:48 <adamw> 876655 	lorax 	NEW 	Lorax does not support building initramfs for fedup
17:06:57 <adamw> and the libxml2 bug, though that one seems to be getting heavy attention
17:07:12 <adamw> #info two unaddressed blockers, 876655 and 877567
17:07:34 <tflink> jreznik: I'm trying to get that figured out today - I'm a bit confused myself
17:07:47 <tflink> there were EFI issues at one point but I guess those might have been addressed
17:08:23 <tflink> I was still seeing issues with the logs being written to disk but I'm building everything from scratch again this morning and will be re-testing
17:08:27 * nirik hopes for fixes for those and beta in the can before the long weekend.
17:08:46 * dan408_ sees no mention of systemd at all here
17:09:32 <adamw> dan408: what's the systemd problem?
17:09:43 <dan408_> .bug 869998
17:09:45 <zodbot> dan408_: Bug 869998 systemd-logind integration broke "Suspend when closing lid" policy - https://bugzilla.redhat.com/show_bug.cgi?id=869998
17:10:10 <dan408_> please advise. im going to add this to blocker or NTH unless someone tells me otherwise
17:10:16 <adamw> okay? that doesn't exactly seem urgent.
17:10:19 <adamw> why the hell would it be a blocker?
17:10:22 <tflink> I don't think this qualifies as NTH or blocker
17:10:22 <dan408_> it is
17:10:26 <adamw> it's about suspending a laptop with external monitor attached.
17:10:29 <tflink> it can be fixed with an update
17:10:33 <adamw> and yeah.
17:10:39 <dan408_> final NTH?
17:10:47 <adamw> we don't block beta for suspend _not working_, never mind desktop niceties. =)
17:10:54 <tflink> I'd probably be -1 NTH on this for final, too
17:11:07 <dan408_> well i think there's a bigger issue than "Desktop niceties"
17:11:10 <dan408_> but okay
17:11:13 <adamw> that'd be the appropriate place to propose it though, yeah.
17:11:26 <adamw> seems like something that'll just get fixed normally, though.
17:11:45 <dan408_> what is the bug for final nth?
17:11:48 <tflink> dan408_: if it turns out to be more severe, that's fine. we're not saying that there is no way this could ever block release or get pulled in past freeze
17:11:54 <adamw> F18-accepted
17:11:57 <dan408_> k
17:12:04 <tflink> 752665
17:12:11 <dan408_> done
17:12:12 <dan408_> thanks
17:12:39 <tflink> oy, i just saw the final blocker list
17:12:53 * tflink is scared - checks to see if he has enough PTO to disappear for the rest of F18
17:13:14 <tflink> anyhow, beta status
17:13:35 <adamw> so outside of fedup we look fairly solid
17:13:45 <jreznik> yep, fedup scares me...
17:13:47 <adamw> bcl says wwoods is 'alive and kicking' but apparently not responding to irc pings...
17:14:24 <tflink> at some point, we need to figure out what we're willing to tolerate for beta
17:14:34 <jreznik> adamw, tflink: could you please keep pinging him overnight (our overnight)
17:14:42 <adamw> we'll try
17:14:57 <jreznik> tflink: but are upgrades what we can tolerate or y*u*m?
17:15:07 <adamw> tflink: well i mean i thought we were quantifying that via the blocker list.
17:15:10 * nirik suspects he will answer when he can... ping -f can be anoying.
17:15:14 <adamw> so far as i'm concerned we tolerate anything that's not on the blocker list.
17:15:33 <tflink> are no logs from upgrade a blocker?
17:15:48 <tflink> what about no output from the upgrade process during upgrade?
17:15:49 <adamw> nirik: trying to roll a release that's a month and a half late without much response from the maintainer of the thing which is delaying it is also annoying :)
17:16:00 <nirik> sure.
17:16:02 <jreznik> nirik: yep but at least status would be great, like...
17:16:13 * tflink is a bit fuzzy on what the minimum functionality is
17:16:17 <nirik> tflink: I'd say no, as long as it works. ;)
17:16:20 <adamw> it's not well defined, really.
17:16:27 <adamw> i'd say logs not a problem, output maybe
17:16:28 <tflink> nirik: define works
17:16:30 <tflink> :-D
17:16:44 <adamw> at least just a screen saying U CAN HAZ UPGRADE JUST WAIT would be nice.
17:17:04 <nirik> tflink: shall I quote the beta critera line? ;) But sure...
17:17:05 <tflink> I'm going to go through the current fixes today and see where we are
17:17:06 <adamw> #info current fedup status not terribly clear, minimum acceptable functionality has not yet been solidly defined
17:17:46 <jreznik> tflink: thanks
17:17:52 <tflink> at the very least, we're still missing builds for fedup-dracut and lorax
17:18:03 <jreznik> that's the main concern...
17:18:17 <tflink> the last I heard, will was working on altering lorax such that plymouth showed the correct theme
17:18:18 <adamw> #info  at the very least, we're still missing builds for fedup-dracut and lorax
17:18:24 <tflink> but that was sometime friday afternoon
17:18:41 * jreznik is not sure it makes sense to waste time with theming... at least in the current state
17:18:45 <tflink> and I don't pretend to know about everything he's working on :)
17:18:51 <nirik> so, lorax, libxml2 and fedup-dracut possibly...
17:18:58 <nirik> then we might be able to make a rc1. whee.
17:19:00 <tflink> there was some systemd in there, too according to one of the bug reports
17:19:02 <adamw> jreznik: i think 'theme' is closely related to 'status display' when it comes to plymouth.
17:19:10 <jreznik> adamw: ok
17:19:38 <tflink> eh, plymouth/systemd/something seems to be stomping on the status output either way
17:19:45 <jreznik> tflink: bz?
17:20:17 <tflink> jreznik: https://bugzilla.redhat.com/show_bug.cgi?id=873144
17:20:54 <jreznik> thx
17:21:44 <jreznik> nirik: for libxml2 - could be an option for relengs to use DV's patch (no CRC/len) check?
17:22:07 <adamw> tflink: for things like this that are 'define minimum acceptable functionality' things we should probably put them on the blocker list
17:22:16 <nirik> jreznik: that was a patch to createrepo? or ? /me looks
17:22:45 <tflink> adamw: ok, I'll propose the ones I know of to get the conversation started
17:22:45 <jreznik> nirik: libxml2
17:23:07 <tflink> and file a new one for EFI if that doesn't work for me :-/
17:23:10 <nirik> jreznik: composes are done in a mock chroot. So, we would need to patch and push libxml2 to stable?
17:23:39 <jreznik> nirik: it's at least dirty and ugly workaround...
17:23:58 <jreznik> the footer is not generated properly
17:24:30 <adamw> okay, so i think we have a broad picture of where we are
17:25:14 <adamw> any other pressing f18 business before we move on?
17:25:23 <tflink> making it work?
17:25:25 <nirik> jreznik: sure, if nothing else we could do that if libxml2 maintainer is ok with dropping that for not until it can get fixed.
17:25:32 <adamw> tflink: out of scope of the qa meeting I fear :)
17:25:40 <jreznik> nirik: DV is ok with that
17:26:01 <tflink> adamw: awww, I was hoping someone had a magic wand or a really big stick to beat F18 into submission :-D
17:26:04 <nirik> jreznik: ok then... can you have him push a libxml2 update for f18 for that? and we can upkarma it and pass it to stable.
17:26:06 <adamw> #info 877567 under intensive investigation, it will be possible to 'fix' it one way or the other
17:26:19 <adamw> #action tflink to continue to evaluate fedup status and propose significant bugs for blocker status
17:26:43 <adamw> #info RC is now essentially blocked on fedup
17:26:50 <adamw> moving on!
17:26:59 <adamw> #topic Open floor
17:27:04 <adamw> anyone have anything for open floor?
17:27:13 <jreznik> nirik: he's sleeping now - so one option is I use my provenpackager foo :)
17:27:28 <nirik> jreznik: sure, if you like/can. ;)
17:27:28 <jreznik> adamw: I have one topic for open floor (or two)
17:27:40 <adamw> jreznik: gimme a summary line?
17:28:07 <jreznik> adamw: I was asked if we are using ON_DEV in Fedora as the plan is to get rid of this bz status
17:28:19 <adamw> #topic Open floor - ON_DEV status in Fedora
17:28:23 <adamw> i believe the answer is 'no'.
17:28:37 <jreznik> looking on (seems to be oudated) https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#ON_DEV it's optional now
17:28:39 <tflink> yeah, I don't think I've seen it used much
17:28:59 <brunowolff> Is the createrepo issue with the Fedora 18 release composes the same as the libxml2 problem?
17:29:03 <adamw> jreznik: that's not really outdated. at least insofar as no-one has proposed any kind of official workflow change that is not reflected in it.
17:29:11 <adamw> in practice, everyone uses their own damn workflow anyway.
17:29:27 <adamw> jwb: kernel team doesn't use ON_DEV does it?
17:29:28 <nirik> brunowolff: yes
17:30:06 <adamw> https://bugzilla.redhat.com/buglist.cgi?list_id=842356&classification=Fedora&query_format=advanced&bug_status=ON_DEV&product=Fedora indicates that, recently, tfujiwara and dan are the only ones using it.
17:30:10 <jreznik> adamw: so, sorry not outdated but with nearly no triaging done... (as that offical triage)
17:30:25 <adamw> dan408: would you be terribly sad to see ON_DEV die?
17:30:49 <jreznik> adamw: the main idea behind is that nearly all other products got rid of it and it's confusing state now (out of workflow)
17:31:22 <adamw> jreznik: i've never really seen it used as a matter of course in fedora. i'd just check in with Dan and fujiwara if they're okay with losing it and if they're okay with it, it's fine, i think.
17:32:06 <adamw> #info ON_DEV very rarely used, apparently only by dan408 and tfujiwar lately.
17:32:22 <jreznik> adamw: ok, I can ask them - as we define it as optional and for package review it was misused (it's not defined in package review process)
17:32:22 <adamw> propose #agreed QA as a group has no objection to dropping ON_DEV status
17:32:25 <adamw> that ok with everyone?
17:32:28 <tflink> ack
17:33:01 * jreznik is not QA but does not think it's really blocking thing for us (from qa, eng pov)
17:33:22 <tflink> looks like we lost everyone else )
17:33:31 * jreznik is still here
17:33:31 <adamw> eh, good enough for government work.
17:33:34 <adamw> #agreed QA as a group has no objection to dropping ON_DEV status
17:33:40 <jreznik> thanks
17:33:49 <jreznik> I'll ask dan408_ and tfujiwar
17:33:56 <adamw> next topic?
17:34:02 <tflink> you should have asked for any objections instead of acks :)
17:34:32 <jreznik> adamw: next one - go/no-go - according to current status and thanksgiving day in the us on Thursday... not sure right now
17:34:46 <jreznik> we already somehow discussed it last week...
17:35:11 * nirik is fine with most anytime.
17:35:36 <nirik> note that there will be a lists.fedoraproject.org outage early on the 22nd.
17:35:40 <jreznik> Thursday means one more day if fedup moves but also it does not make sense to shoot US people to knee...
17:36:00 <adamw> #topic Open floor - go/no-go date
17:36:16 <dan408_> new years eve!
17:36:18 <adamw> personally i don't care about thursday as we got thanksgiving out of the way last month :)
17:36:27 <adamw> dan408: heh, sounds like the most realistic proposal
17:36:36 <dan408_> i was 100% serious too
17:36:45 <dan408_> ok 75%
17:36:58 * tflink doesn't much care, personally
17:36:59 <adamw> given the status of fedup i think we might have trouble making it by wed, but that's just an educated guess
17:37:07 <adamw> just feels like the wed/thu distinction could actually matter this week
17:37:08 <tflink> that wouldn't surprise me
17:37:09 <tflink> I'
17:37:21 <tflink> I'd be nervous about taking the lorax build w/o more testing
17:37:23 <dan408_> can we please unfreeze beta?
17:37:54 <jreznik> adamw: ok, then Thursday if tflink and nirik will be around... /me really does not know how thanksgiving day looks like :)
17:38:10 <adamw> dan408: that's not happening.
17:38:18 <tflink> I'd rather not be around since thursday and friday are US holidays
17:38:26 <adamw> i'll be around thu
17:38:37 <adamw> we really only need one person from qa for go/no-go itself as the decision is programmatic
17:39:00 <dan408_> k
17:39:36 <dan408_> ill be happy to type no go on thursday for you adamw
17:39:42 <jreznik> the main thing is - if we would be able to find some devs - mostly anaconda ones... but at least I can ask Brno Anaconda guys to be around
17:40:27 <dan408_> oh
17:40:31 <dan408_> btw i missed the last topic
17:40:36 <dan408_> I object to getting rid of on_dev
17:40:48 <adamw> #info Thursday is thanksgiving in the U.S., but we may need the extra day (wed vs. thu) to have a chance at being ready
17:40:54 <dan408_> rename it to pending_upstream or something
17:40:55 <adamw> dan408: ok, talk with jreznik about it
17:40:58 <dan408_> yep
17:41:02 <dan408_> just stating it publically
17:41:06 <adamw> fair enough
17:41:13 <adamw> #info dan408 is against dropping ON_DEV
17:41:29 <tflink> I don't know if it matters, but friday is also a holiday for most of the US
17:41:48 <tflink> well, not a holiday but generally grouped in with thanksgiving
17:41:49 <dan408_> thank you adamw
17:43:00 <nirik> there is a UPSTREAM already.
17:45:35 <tflink> anything else about this topic?
17:45:52 <jreznik> well, I'll schedule it to Thursday as we really need that day and if adamw is going to be around, we need nirik to push the button and he seems to be at least available to do this...
17:45:55 <adamw> i think not, leave it to jreznik to schedule
17:46:00 <adamw> ok thanks
17:46:03 <adamw> any more topics?>
17:46:07 <adamw> #topic Open floor
17:46:39 <dan408_> nirik: that is for closed bugs;.
17:46:54 <nirik> dan408_: right.
17:47:13 <dan408_> and used for something completely different than ON_DEV
17:47:16 <nirik> so you want something for 'upstream is working on this, and we will pull it/fix it when they are done, so it's in progress' ?
17:47:45 <dan408_> yes please
17:48:21 * nirik just uses ASSIGNED
17:48:56 <jreznik> or keyword is (probably) cheap...
17:48:57 <dan408_> .bug 868472
17:49:00 <zodbot> dan408_: Bug 868472 [abrt] mate-file-manager-1.4.0-12.fc18: handle_error: Process /usr/bin/caja was killed by signal 5 (SIGTRAP) - https://bugzilla.redhat.com/show_bug.cgi?id=868472
17:49:03 <adamw> that wasn't really what ON_DEV was for anyway, but hey.
17:49:07 <dan408_> ON_DEV was usefull for this bug
17:49:17 <dan408_> and when you are sorting through 68 bugs in your my bugs
17:49:36 <jreznik> using ON_DEV is abusing of initial intention of this status and nobody would understand it at all...
17:49:52 <dan408_> on_dev provided a good distinction between stuff i need to work on and stuff that i can't do anything about right now
17:52:55 <adamw> can we end this now? :)
17:53:04 <dan408_> please
17:53:07 * dan408_ is off to work
17:53:12 <jreznik> well, I think we agreed with dan408_ in PM that he's ok with getting rid of ON_DEV, keyword seems to be a way how to track it for him...
17:53:26 <dan408_> thanks jreznik
17:53:55 <jreznik> dan408_: thanks too!
17:53:55 <adamw> ok, setting fuse for X minutes
17:54:30 <jreznik> adamw: do you need a ticket for ON_DEV or meeting agreement is ok for you?
17:54:45 <jreznik> and it also means action item to fix the workflow page
17:54:59 <adamw> jreznik: can you just do an ML post?
17:55:32 <dan408_> let's track it with a ticket
17:55:41 <dan408_> jreznik can do it ;)
17:55:58 <dan408_> i will switch all my bugs from on_Dev to assigned
17:56:43 <dan408_> bbl
17:57:00 <adamw> #endmeeting