QA/Meetings/20121105

From FedoraProject

Jump to: navigation, search

Contents

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!