QA/Meetings/20121119

From FedoraProject

< QA | Meetings
Revision as of 04:02, 1 February 2013 by Adamwill (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

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

Previous meeting follow-up

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!