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