QA/Meetings/20121119

Attendees

• adamw (204)
• tflink (146)
• dan408_ (97)
• jreznik (75)
• nirik (55)
• brunowolff (8)
• akshayvyas (8)
• kparal (7)
• zodbot (6)
• mkrizek (3)
• herlo (2)
• satellit_e (1)
• jwb (1)

Agenda

• Previous meeting follow-up
• Fedora 18 Beta status / mini blocker review
• Open floor

Fedora 18 Beta mini blocker/NTH review

• #876789 was rejected as a blocker due to not affecting all testers, accepted NTH
• #875278 was skipped as already addressed
• #877623 was left undetermined until further data could be obtained
• #877567 was accepted as a blocker for preventing compose
• #877576 was accepted as NTH as a significant translation issue
• #874753 was rejected as NTH as fixable post-release
• #876922 was accepted as NTH pending some pre-flight testing

Fedora 18 Beta status

• There were two unaddressed blockers, #876655 and #877567
• Current fedup status was unclear, minimum acceptable functionality had not yet been solidly defined
• We were still missing builds for fedup-dracut and lorax
• #877567 was under intensive investigation, it would be possible to 'fix' it one way or the other
• RC was essentially blocked on fedup

Open floor

• jreznik was asked if ON_DEV status was used actively in Fedora: group generally agreed it was not and had no objections to dropping it
• Go/no-go meeting scheduled for 2012-11-22 (Thanksgiving in U.S.) despite the holiday, as we did not expect to be ready by Wednesday

Action items

• tflink to continue to evaluate fedup status and propose significant bugs for blocker status

IRC Log

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

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!