QA/Meetings/20121105

Attendees

• adamw (96)
• tflink (90)
• j_dulaney (21)
• jreznik (19)
• kparal (17)
• cmurf (14)
• zodbot (5)
• mkrizek (4)
• nirik (2)
• nb (2)
• mkovarik (2)
• Cerlyn (1)
• satellit (1)
• nonamedotc (1)
• pschindl (1)

Agenda

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

Previous meeting follow-up

• adamw to finally finish drafting revised partitioning criteria - still not done, validation still getting in the way, but existing state should be OK for Beta
• adamw to push security criterion into 'production' after waiting a few more days for feedback - no more feedback received, so adam would push it immediately

Fedora 18 Beta status / mini blocker review

• TC7 testing over the weekend had revealed only one big issue, RC looked plausible
• fedup was still undergoing work, but tflink had been testing and called for others to help
• Plan for providing the fedup upgrade image was still not clear
• General agreement that requiring use of a side repo for fedup at Beta would be bad

Mini blocker review

• #872446 was accepted as a blocker per partitioning criteria
• #872791 was accepted as a blocker for breaking install in most/all non-English languages
• #863670 was left undetermined until further data could be obtained
• #869391 was accepted as a blocker per partitioning criteria

Open floor

N/A

IRC Log

adamw	#startmeeting Fedora QA meeting	16:01
zodbot	Meeting started Mon Nov 5 16:01:47 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.	16:01
zodbot	Useful Commands: #action #agreed #halp #info #idea #link #topic.	16:01
adamw	#meetingname fedora-qa	16:01
zodbot	The meeting name has been set to 'fedora-qa'	16:01
adamw	#topic roll call	16:01
adamw	must be --- this tall to ride!	16:02
* satellit listening		16:02
* Cerlyn listens to two meetings at once		16:02
tflink	good thing my monitor isn't above my head right now	16:02
* mkrizek is present		16:02
* adamw turns up the volume		16:02
* kparal around		16:02
adamw	take that, other meeting	16:02
* pschindl is here		16:02
adamw	okey dokey	16:03
* cmurf is here		16:03
adamw	thanks for coming folks	16:03
adamw	#topic previous meeting follow-up	16:03
* nirik is lurking around.		16:04
adamw	#info "adamw to finally finish drafting revised partitioning criteria" - nope. validation still getting in the way, sigh. but i think we're okay for beta anyhow.	16:04
adamw	#info "adamw to push security criterion into 'production' after waiting a few more days for feedback" - no more feedback last week, so i'll push that out today.	16:04
adamw	anything else from last week's meeting to follow up on?	16:04
adamw	okay then	16:05
adamw	#topic Fedora 18 Beta status / mini blocker review	16:05
adamw	#info TC7 was in testing over the weekend, one obvious booboo but looking decent aside from that	16:06
* jreznik is around		16:06
adamw	anyone have anything about beta to discuss outside of blocker review?	16:06
* j_dulaney waves for the first time in a while		16:06
adamw	hi j_dulaney, long time no see	16:06
* nirik really hopes we can get to rc1 soon.		16:06
j_dulaney	+1	16:06
* tflink is still working on upgrade testing, others have been helping and filing bugs		16:06
jreznik	adamw: current fedup status definitely, but it's part of blocker review probably	16:07
jreznik	nirik: hope so	16:07
nonamedotc	outside of blocker - i think beta tc7 is very nice	16:07
adamw	#info fedup still undergoing work, but tflink has been testing	16:07
tflink	we may have a fedup related blocker, depending on what I find today	16:08
tflink	the bug isn't filed yet, I'm still trying to gather more info	16:08
adamw	we're not necessarily going to hit fedup in blocker review, so...	16:08
adamw	any more detailed info on current fedup status besides the above?	16:08
tflink	if you're going to try testing fedup, please check the fedup testing wiki page	16:08
tflink	https://fedoraproject.org/wiki/QA%3AFedora_18_Upgrade_Testing	16:09
tflink	I'm trying to keep it updated with current procedure for using fedup, known issues etc.	16:09
tflink	there have been two bugs filed recently due to improper fedup usage (and a rather user unfriendly error message that looks like a crash)	16:10
adamw	thanks tflink	16:11
adamw	#chair tflink kparal	16:11
zodbot	Current chairs: adamw kparal tflink	16:11
jreznik	well, how do you evaluate the state of fedup? is it something usable or still not? beside bugs	16:11
tflink	jreznik: define usable and it depends on the issue that I'm looking into ATM	16:12
j_dulaney	Does it install a kernel?	16:12
tflink	I've hit a nasty issue at least once where the kernel initramfs isn't fully written to disk before dracut reboots the system during upgrade	16:12
tflink	which leaves you with a completely non-bootable system	16:13
tflink	but it's not every time and I've only confirmed one hit of that	16:13
jreznik	tflink: I mean - what's the chance to finish upgrade without the need to tweak the system etc	16:13
tflink	jreznik: I've yet to have a working git install post upgrade but I think that might be an upgradepath issue with git or its deps	16:13
tflink	jreznik: in general, the upgrades work fine. the only time I've had serious issues is when a kernel upgrade is involved	16:14
tflink	and by work fine, i mean reboot into a semi-working system that may still be on a f17 kernel	16:14
adamw	tflink: it may be useful to compare to a yum upgrade (with selinux in permissive)	16:15
adamw	i'd expect our Official Upgrade Method to manage at least as well as yum	16:15
adamw	and that should help you tell which issues are fedup-specific	16:15
jreznik	well, first part seems good, second does not but definitely comparing to yum is not a bad idea	16:15
adamw	i did a yum upgrade for testing on friday and didn't hit any obvious problems, but i didn't test the upgraded system very hard	16:15
jreznik	do you think fedup in the current state is blocking release? how much work would have to be done in f18 (and not possible to update?)	16:16
tflink	I'm more worried about this non-bootable system issue that I've hit twice now	16:16
jreznik	adamw: I heard yum works quite well from folks around too	16:16
tflink	there are two major fedup issues that I'm aware of right now	16:16
j_dulaney	Remember, if an F16 system is upgraded to F18, and the kernel doesn't install, then you wind up with a broken system	16:16
adamw	j_dulaney: yeah, we're aware.	16:17
tflink	the first is process/releng: how is the initramfs going to be built and where is it going to be hosted	16:17
tflink	I've spoken with dgilmore about this and he isn't a fan of the current siderepo technique	16:17
tflink	when I last talked to wwoods about it, he was working on integrating the initramfs generation into lorax but I'm not sure what the status of that work is	16:18
adamw	#info plan for building and providing upgrade initramfs is still not clear	16:18
tflink	he was hitting issues with lvm usage during initramfs generation and was looking into generating a separate upgrade.img generation with lorax for beta	16:18
tflink	the other issue is this non-bootable system post-upgrade thing I've hit twice now	16:19
tflink	I suspect they're the same issue but I haven't dug into this most recent failure enough to be certain	16:19
adamw	#info tflink working on pinning down a bug that causes non-bootable upgraded system	16:19
adamw	okay, thanks for that	16:19
adamw	with that in mind...shall we go onto blocker review?	16:20
tflink	assuming that I understand the issue correctly, it would require changes to the f18 packages and the initramfs generation	16:20
tflink	er, the generated initramfs for upgrade	16:20
tflink	whether that blocks release of F18 depends on what the answer to the releng question is, somewhat	16:20
adamw	good point	16:20
tflink	I'd rather not release with a 'recommended upgrade process' that could produce a non-bootable system, though	16:21
jreznik	and if we risk siderepo for beta?	16:21
jreznik	tflink: that makes sense...	16:21
adamw	yeah, we can go beta with the UI still rough but we should at least resolve _known_ total fails	16:21
tflink	I really don't like the idea of a separate repo for upgrades and I don't think that dgilmore does either	16:21
jreznik	tflink: nobody likes it, I bet	16:22
tflink	adamw: I've only hit it with upgrading the kernel during fedup upgrade. the new kernel isn't in stable yet so I don't think people would be hitting it now if the problem does show up regularly	16:22
* tflink has a local siderepo with newer kernels in it		16:22
* j_dulaney didn't get what the side repo is supposed to solve		16:22
adamw	tflink: but then, i'd say we want to be ensuring at least the kernel gets upgraded.	16:23
tflink	j_dulaney: testing fedup w/o changing the release image generation process	16:23
j_dulaney	Ah	16:23
tflink	adamw: that gets into a the usual mess of making sure that the ENVR of Fn kernel > Fn-1 kernel	16:23
adamw	booting F-N+1 with a kernel whose initramfs was generated on F-N can be a problem in general, not just wrt usrmove.	16:23
adamw	tflink: we have that whole bug report for that one. but at a high level i'd say that if we really want to do it, i'm sure we can.	16:24
adamw	it's not beyond the realm of possibility to code fedup to just 'install the latest F-N+1 kernel in all cases'.	16:24
tflink	sure, if you can get past the finger pointing	16:24
adamw	right.	16:24
tflink	both sides have reasonable arguments for why it should be solved elsewhere	16:24
adamw	both sides will have their fingers snapped off if pointing continues too long ;)	16:24
jreznik	adamw: ;-)	16:25
j_dulaney	LOL	16:25
j_dulaney	adamw: Back to firing?	16:25
adamw	#info we still have bug #820351 on upgrades in general: we don't force installation of the kernel from target release	16:25
adamw	j_dulaney: i never stopped!	16:25
adamw	.fire j_dulaney	16:25
zodbot	adamw fires j_dulaney	16:25
j_dulaney	Seriously, the *sane* thing to do is to always replace the kernel	16:25
adamw	yeah.	16:25
adamw	anyhow, i think we've been around that rodeo a few times	16:25
adamw	so is that everything now tflink?	16:26
tflink	as far as I know, yes	16:26
adamw	okay, you want to take over to do proposed blocker review?	16:26
tflink	if I say no, do I still have to do it? :-D	16:26
tflink	ok, at the moment, we have:	16:27
tflink	#info 7 Proposed Blockers	16:27
tflink	#info 8 Accepted Blockers	16:27
tflink	#info 3 Proposed NTH	16:27
tflink	#info 37 Accepted NTH	16:27
jreznik	tflink: no is not an asnwer!	16:27
tflink	since I don't think we want to be here for hours, let's look @ proposed blockers mostly and accepted if we still have people around at that point	16:28
tflink	jreznik: how is 'no' not an answer? it might not be an acceptable answer, but it is an answer :)	16:28
adamw	sure, proposed is the main thing for mondays.	16:28
tflink	#topic (872446) ValueError: new size same as old size	16:29
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=872446	16:29
tflink	#info Proposed Blocker, anaconda, ON_QA	16:29
tflink	sounds like this is really easy to hit during custom partitioning	16:31
tflink	using the current criteria,	16:31
adamw	it's in 18.24 already, so there's probably not a lot of point spending much time on it :)	16:31
tflink	it seems to hit "The installer's custom partitioning mode must be capable of the following ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types."	16:32
kparal	+1 blocker	16:32
adamw	and 'not crashing on common operations'	16:32
adamw	or whatever that line is	16:32
adamw	so +1	16:32
cmurf	+1	16:32
tflink	proposed #agreed 872446 - AcceptedBlocker - Violates the following F18 beta release criteria: "The installer's custom partitioning mode must be capable of the following ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types."	16:32
jreznik	+1, we have the patch, so	16:32
kparal	ack	16:32
mkrizek	ack	16:32
cmurf	ack	16:32
tflink	#agreed 872446 - AcceptedBlocker - Violates the following F18 beta release criteria: "The installer's custom partitioning mode must be capable of the following ... Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types."	16:33
tflink	#topic (872791) TypeError: Argument 1 does not allow None as a value	16:33
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=872791	16:33
tflink	#info Proposed Blocker, anaconda, NEW	16:33
tflink	this is the glade translations issue?	16:33
adamw	yeah	16:33
adamw	as i understand it, there's certain strings in custom part screen that if you hit them, and they aren't translated to the language you're using, anaconda crashes	16:34
jreznik	yep	16:34
adamw	seems pretty easy to hit, like 3-4 people hit it within hours of tc7 coming out	16:34
kparal	blocker then	16:34
j_dulaney	+1 blocker	16:34
cmurf	+1 blocker	16:34
tflink	proposed #agreed 872791 - AcceptedBlocker - Violates the following F18 alpha release criterion for most, if not all installs with non-english language: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the offici	16:34
cmurf	ack	16:35
kparal	ack	16:35
tflink	let me guess, that got cut off near officially	16:35
mkrizek	ack	16:35
cmurf	yes	16:35
adamw	halfway through it, yeah	16:35
j_dulaney	ack	16:35
adamw	but that seems a bit of a silly criterion anyway	16:35
adamw	i'd pick the partitioning one again	16:35
adamw	you _do_ have to go through custom part to hit it, i think	16:35
adamw	or, maybe not, actually. sorry.	16:36
adamw	w_pirker says that, but stevet doesn't.	16:37
tflink	some of these sounds like it's when picking an install language	16:37
tflink	er, which language to install	16:37
adamw	yeah. sorry, go ahead with that criterion, my bad	16:38
tflink	proposed #agreed 872791 - AcceptedBlocker - Violates the following F18 alpha release criterion for most, if not all installs with a non-english language: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick"	16:39
adamw	ack	16:39
kparal	ack	16:39
* jreznik does not know how qa handles the translations, so can't ack now		16:40
j_dulaney	ack	16:40
tflink	#agreed 872791 - AcceptedBlocker - Violates the following F18 alpha release criterion for most, if not all installs with a non-english language: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick"	16:40
tflink	#topic (863670) ValueError: ('invalid size specification', '-186.0 mb')	16:41
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=863670	16:41
tflink	#info Proposed Blocker, anaconda, NEW	16:41
adamw	so i was a bit worried when two people inc. bcl hit this, but no-one else has since	16:41
tflink	could it be btrfs related w/ the subvol parsing issue?	16:42
* tflink hasn't read logs yet		16:42
kparal	maybe ask bcl about severity?	16:42
adamw	well the severity is obviously high	16:43
adamw	the question is how _common_ it's likely to be	16:43
kparal	that's what I meant	16:43
cmurf	i don't actually understand how to reproduce this	16:44
* j_dulaney ran into this bug in a VM		16:45
j_dulaney	Installing from Live	16:45
tflink	wow, there are a lot of partitions on that disk	16:45
adamw	so i think i see several dupes of this	16:45
adamw	or similar issues anyhow	16:45
adamw	i see four bugs for "ValueError: ('invalid size specification', '-1.000000 MB')" and one for "ValueError: ('invalid size specification', '-150.000000 mb')" which is marked as ON_QA...	16:45
tflink	3x ntfs, 1x swap, 3x ext4 and 1 un-identifiable partition	16:45
adamw	the on_qa was for 18.14, though	16:46
* j_dulaney leans +1 blocker		16:47
tflink	when was the last repro of the bug that's not on_qa?	16:47
* adamw discussing with dlehman at present in #anaconda		16:47
cmurf	layout seems esoteric but again i'm still not sure what's triggering the bug	16:47
adamw	probably bcl with 18.22	16:47
adamw	shall we leave this one for a bit to give dlehman time to look at it and circle back at the end>?	16:49
tflink	works for me	16:50
jreznik	if dlehman takes a closer look yep, but would be great to have resolution asap, even it means voting in bug...	16:50
tflink	proposed #agreed 863670 - It's not clear how common this issue is right now, will re-visit when more information is available.	16:51
adamw	ack	16:51
cmurf	ack	16:51
jreznik	ack	16:51
kparal	ack	16:51
tflink	#agreed 863670 - It's not clear how common this issue is right now, will re-visit when more information is available.	16:51
tflink	#topic (869391) LUKSError: luks device has no key/passphrase	16:51
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=869391	16:51
tflink	#info Proposed Blocker, anaconda, NEW	16:51
tflink	I'm not 100% clear on this. is it just possible to install w/o LUKS password or the user is never prompted for it?	16:52
kparal	comment 17 mentions a different workflow than the description	16:52
tflink	and what happens if you do install w/o LUKS password	16:52
kparal	according to the reproducer it seems to be a blocker	16:53
adamw	yeah, comment #17 is what worries me here	16:53
adamw	i'm not too worried about the case where you're prompted for a password and don't type one, but a case where you're not prompted is bad	16:53
j_dulaney	Indeed	16:54
* kparal pinging mkovarik		16:54
tflink	I'm definitely not -1 but I'm leaning towards punt right now	16:54
cmurf	i think it's clearly unintended	16:54
tflink	sure, but is it worth of blocking release?	16:55
kparal	mkovarik is coming	16:55
j_dulaney	Wouldn't this be a final blocker?	16:55
adamw	encryption is in the criteria at alpha or beta iirc.	16:56
kparal	mkovarik: https://bugzilla.redhat.com/show_bug.cgi?id=869391#c17	16:56
* adamw checks to see if he can reproduce quick		16:56
cmurf	if it's about creating encrypted partitions it's beta blocking	16:56
kparal	mkovarik: does it mean you were not asked for password at all?	16:56
mkovarik	kparal, yes	16:56
nb	? will QA meeting be done in a few minutes or do we need to move FAmSCo elsewhere?	16:56
tflink	mkovarik: what is the result after install?	16:56
jreznik	nb: qa can move to #fedora-qa	16:56
nb	ok thanks	16:57
tflink	is the disk enrypted?	16:57
adamw	i just reproduced exactly as mkovarik described	16:57
adamw	tflink: it's a crash	16:57
adamw	the install fails	16:57
tflink	ah, that sounds blocker to me	16:57
adamw	it crashes at start of install, when creating partitions	16:57
kparal	mkovarik: thanks	16:57
cmurf	+1 blocker	16:57
tflink	let's get this proposed and we can move the meeting	16:57
adamw	OK	16:58
j_dulaney	+1 blocker	16:58
mkovarik	tflink, it fails during formating harddrives	16:58
tflink	proposed #agreed 869391 - AcceptedBlocker - Violates the following F18 beta release criterion for encrypted disks: "The installer's custom partitioning mode must be capable of the following ... Rejecting obviously invalid operations without crashing"	16:58
kparal	ack	16:58
mkrizek	ack	16:58
adamw	nack	16:59
adamw	this is nothing to do with custom partitioning	16:59
tflink	adamw: patch?	16:59
j_dulaney	ack	16:59
tflink	don't you have to use custom partitioning to get encryption?	16:59
adamw	no, that's a bit of a problem now	16:59
adamw	when we revised the criteria you had to	16:59
adamw	now you don't	16:59
adamw	so we may have to do it without a direct criterion reference	17:00
cmurf	ack	17:00
tflink	does it crash w/ encryption in the custom interface?	17:00
adamw	proposed #agreed 869391 - AcceptedBlocker - criteria do not reflect ability to encrypt partitions without entering custom partitioning, but in principle, showstoppers in encrypted installation are blockers	17:00
adamw	tflink: didn't test.	17:00
j_dulaney	adamw: ack	17:00
adamw	tflink: my guess would be that it may well not, as i think that codepath is different.	17:01
tflink	adamw: I guess that works well enough. smells a bit fudgy, though. not like i have a better idea	17:01
tflink	ack	17:01
* j_dulaney must take his leave, time for lunch then class		17:01
adamw	one more ack?	17:01
cmurf	ack	17:02
adamw	#agreed 869391 - AcceptedBlocker - criteria do not reflect ability to encrypt partitions without entering custom partitioning, but in principle, showstoppers in encrypted installation are blockers	17:02
adamw	okay, let's split to #fedora-qa	17:02
tflink	wheee!	17:02
adamw	#info time in this channel is exhausted, but we will continue blocker review in #fedora-qa	17:02
adamw	#endmeeting	17:02

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