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