From Fedora Project Wiki

< QA‎ | Meetings
Revision as of 21:28, 10 April 2012 by Adamwill (talk | contribs) (update page with the results of the meeting)

Attendees

  • adamw (153)
  • VICODAN2 (111)
  • tflink (36)
  • nirik (22)
  • brunowolff (13)
  • Martix (12)
  • jreznik (12)
  • Viking-Ice (8)
  • Cerlyn (7)
  • robatino (5)
  • zodbot (3)
  • rbergeron (3)
  • rdieter (1)
  • satellit_ (1)

Agenda

  • Previous meeting follow-up
  • Fedora 17 Beta status / blocker review
  • Test Day report
  • Upcoming QA events
  • AutoQA update
  • Open floor

Previous meeting follow-up

Fedora 17 Beta status / blocker review

  • Current_Release_Blockers
  • Need to spin RC4 ASAP: blockers remained in anaconda/preupgrade and selinux
  • #809707 was rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date

Test Day report

Upcoming QA events

AutoQA update

  • No news, once more

Open floor

  • Some discussion of whether preupgrade bugs should block media spins: adam to propose changes on the list
  • Andre noted that mediacheck is now 'hidden' and should be exposed or enabled by default: see #809663

Action items

  • adamw to send formal proposal for preupgrade criteria adjustment to the list

IRC Log

adamw #startmeeting Fedora QA meeting 15:00
zodbot Meeting started Mon Apr 9 15:00:07 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00
adamw #meetingname fedora-qa 15:00
zodbot The meeting name has been set to 'fedora-qa' 15:00
adamw #topic roll call 15:00
adamw well hey, it appears to be meeting time again. 15:00
tflink it does indeed 15:00
* tflink thinks the attendance is going to be a bit light today 15:01
adamw likely 15:01
adamw who's around? come crawl out of the woodwork 15:01
adamw if it's just me and you we may as well cancel 15:02
* Cerlyn is here 15:02
* brunowolff is here 15:02
* nirik is lurking around as always 15:03
* satellit_ listening 15:03
adamw ooh, the woodwork is positively slithering, it appears. 15:03
VICODAN2 HI 15:05
adamw hi dan. 15:05
VICODAN2 how goes it? 15:05
adamw so, we don't have anything from last week that i can think of 15:05
VICODAN2 i just woke up 15:05
adamw anyone else think of anything to follow up on? 15:05
VICODAN2 probably nothing i can offer that hasn't been talked about already 15:06
VICODAN2 i installed RC3 yesterday on a VM 15:06
adamw okay, let's skip previous meeting follow-up then 15:06
adamw #topic Fedora 17 Beta status / blocker review 15:07
adamw so, not looking great here, we have no rc4 and still two open blockers, it seems. unless i missed something this morning. 15:07
VICODAN2 nope sounds about right 15:07
* Viking-Ice sneaks in 15:07
adamw anyone heard anything from mgrepl or wwoods through any side channels? 15:08
tflink nope 15:08
brunowolff I saw a bunch of updates did get pulled in to F17 stable over the weekend. 15:08
nirik that was the gnome 3.4 update. 15:08
VICODAN2 the login screen still shows the sql server login 15:09
adamw brunowolff: yeah, we're tidying up the stuff from rc3. 15:10
brunowolff It looks like today's compose failed. Though it's kind of an odd looking error. 15:10
adamw VICODAN2: that one's not a beta blocker. think desktop team was bikeshedding it, but it should be gone for final one way or another, i guess. 15:10
VICODAN2 yea i'd like to have a word with them 15:11
VICODAN2 oh 15:11
VICODAN2 package dependencies seems to be fixed 15:11
VICODAN2 no more problems when running yum update after installing a bunch of packages with customize now 15:12
VICODAN2 i did have to install twice yesterday, but im going to blame virtualbox on that 15:12
adamw so, basically, seems we need to get out the pokey sticks and start poking mgrepl and wwoods. not a whole lot we can do till then. 15:12
VICODAN2 nope 15:12
adamw rbergeron: have you been performing official pokeage? 15:13
VICODAN2 maybe hes poking them now 15:14
adamw she 15:15
VICODAN2 she's been idle for 20 mins 15:16
adamw oh, well. 15:16
adamw tflink: we don't have any blockers to review, right? 15:16
adamw oh, hey, we do have one new one. 15:16
adamw the other two proposed are already discussed, i just didn't secretaryize from friday yet, my bad. 15:17
adamw #topic Beta blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=809707 15:17
VICODAN2 LOL 15:18
adamw this sounds worse reading through it than it does from the summary... 15:19
VICODAN2 this is not a blocker 15:19
Viking-Ice Do we have any "date" criteria 15:19
Viking-Ice if not then not a blocker just regular bug 15:19
VICODAN2 this is lamer than the y2k bug 15:19
Cerlyn it's a failure to boot due to the RTC not being correct 15:19
adamw yeah. 15:19
adamw that's the problem: if you have system date earlier than 2012-01-29 for any reason (newly bought system, duff system clock, testing something) you get a crash on boot. 15:20
VICODAN2 someone needs a new cr2032 15:20
VICODAN2 yeah but this is complaining about 1-1-2000 15:20
VICODAN2 1-29-2012 is a bigger problem but not as big :P 15:21
Viking-Ice is it not rather rare that that is the case 15:21
Cerlyn This comes up on early XO-1.75 prototypes which occasionally reset their clock for no reason 15:21
VICODAN2 really? 15:21
adamw Cerlyn: yeah, I was wondering about the XO case 15:21
brunowolff I am thinking this is a blocker. But it looked like there was a simple change that could be done to avoid triggering the bug and I think that would be OK for Beta. 15:22
adamw but if they're prototypes...then i guess it's kind of annoying for prototype testers, but not a huge issue 15:22
VICODAN2 oh is that the laptop for the african children? 15:22
Viking-Ice and nobody with the XO team investigating why the clock reset's itselfs? 15:22
Cerlyn Production units should not be prone to doing this provided they aren't kept in storage improperly to the point the RTC battery drains 15:22
rbergeron adamw: not this morning yet. /me is on phone in meeting, i will flog shortly 15:22
adamw rbergeron: set whips to stun 15:23
adamw so we're kind of left with the generalized 'some kind of weird oops or the RTC battery ran out' case, really 15:23
VICODAN2 yup 15:23
tflink sounds like a conditional violation of the "needs to boot into graphical env" criterion 15:24
VICODAN2 not a blocker, but a bug none the less, i can think of way more important things to worry about 15:24
Cerlyn Is there any known signs that clock values other than an RTC reset may cause this? 15:24
adamw Cerlyn: well, any value before jan 29th causes it. 15:25
adamw but there's very few reasons to have a system date that wrong that i can think of. 15:25
VICODAN2 good thing it's April 9th 15:25
rbergeron adamw: willdo 15:25
VICODAN2 doesn't NTP start before Gnome? 15:26
tflink assuming you have it turned on, yes 15:26
Viking-Ice in any case I vote -1 on blocker even NTH since this is more an exception than a rule that this happens 15:26
VICODAN2 well, problem solved. 15:26
adamw VICODAN2: ntp isn't enabled by default 15:26
VICODAN2 i know. 15:26
VICODAN2 you have to have dead battery and ntp turned off for this to happen 15:27
adamw but yeah, i think i'm with viking-ice, the cases that are going to hit this are just too corner-y and there's an obvious 'workaround' (fix the darn date) 15:27
VICODAN2 i have a better chance of winning the lottery 15:27
adamw probably +1 final blocker, but -1 beta 15:27
tflink yeah, this seems like a rather hairy failure mode but I'm not sure it's beta blocker worty 15:28
brunowolff It won't be obvious that setting the correct date in the bios is the needed fix. So it would be nice to have this documented with commmon bugs. 15:28
Viking-Ice yeah +1 final 15:28
VICODAN2 +1 15:28
Cerlyn +1 15:28
adamw tflink: gnome's failure modes now are just hairy in general. in gnome2 if g-s-d crashed you got a basically working desktop with fonts and sizes and window theme and so on that you didn't specify. in gnome3 you get the fail whale. progress! 15:28
tflink at least its obvious when something goes wrong 15:29
VICODAN2 can we just move back to gnome 2? 15:29
adamw propose #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date 15:29
VICODAN2 i propose a move back to gnome 2 15:29
adamw VICODAN2: not here, you don't. 15:29
adamw :P 15:29
VICODAN2 :( 15:29
tflink adamw: ack 15:30
VICODAN2 its funny 15:30
VICODAN2 you install f17 15:30
VICODAN2 login 15:30
VICODAN2 and you are presented with an empty desktop 15:30
brunowolff I'd prefer to see common bugs suggestion for this one. 15:30
VICODAN2 with like 15:30
VICODAN2 "windows" and "activities" 15:31
adamw brunowolff: stick 'commonbugs' in the keywords list 15:31
adamw VICODAN2: the desktop battles belong on devel list, or desktop list, or really anywhere that's not here. =) 15:31
Martix regarding Test Days, could you approve mail for tomorrow test 15:32
Martix day? 15:32
VICODAN2 it's really terrible, i'll look them up. 15:32
adamw Martix: will do 15:32
Martix adamw: thanks 15:32
adamw any more acks? 15:32
brunowolff For right now I was suggesting ammending the proposal, but if no one has any objections, I'll just mark the bug. 15:32
adamw oh okay 15:32
adamw commonbugs proposing doesn't really have to follow nth/blocker procedure 15:32
Cerlyn adamw: Do we wish to propose it as a final blocker in the same motion, or is that a later vote? 15:33
VICODAN2 it's a final blocker 15:33
brunowolff ack 15:33
adamw you can nominate a bug for commonbugs any time, at your own authority, it's just a 'suggestion' to people who like to update the page 15:33
adamw Cerlyn: i was going to keep it for later just to keep things simple 15:33
adamw it sounds like it'll likely get fixed before we hit final blocker review anyhow 15:33
VICODAN2 yep 15:34
adamw #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date 15:34
VICODAN2 also 15:35
VICODAN2 other workaround is use ntp 15:35
adamw anything else anyone's worried about for beta? 15:35
VICODAN2 well 15:35
VICODAN2 let me tell you about my experience yesterday 15:35
VICODAN2 again this is in a vbox vm 15:35
VICODAN2 i install f17 15:35
VICODAN2 im at the end 15:35
VICODAN2 "congratulations fedora is installed!" "remove the cdrom and reboot!" remove cdrom from drive and press reboot and it hangs 15:36
VICODAN2 do hard reset, reboot and im dropped in to a grub shell 15:36
VICODAN2 booted off DVD again, did an upgrade and it was fine 15:36
tflink VICODAN2: have you filed a bug? 15:36
adamw if it's not reproducible and you didn't get logs from the failure, there's not a whole lot anyone can do with that. 15:36
VICODAN2 no. I want to reproduce it again 15:36
VICODAN2 and i was hoping rc4 would drop soon 15:37
tflink VICODAN2: make sure you grab the logs from the failed install 15:37
VICODAN2 so I could report it against RC4 15:37
VICODAN2 well it technically wasn't a "failed install" 15:37
VICODAN2 when is RC4 dropping? 15:37
tflink not sure, we're waiting for blocker fixes 15:38
VICODAN2 so a week? 2 at most? 15:38
tflink the hope is in the next day or two 15:38
VICODAN2 k 15:38
tflink but we're getting a bit off into the weeds for a meeting, here 15:38
VICODAN2 i'll wait for rc4 and try it again 15:39
VICODAN2 how do i grab logs from anacdona/install? 15:39
tflink VICODAN2: can you ask in #fedora-qa, this is getting off topic for the meeting 15:39
VICODAN2 yessir 15:39
tflink thanks 15:39
adamw okay, so, there we are. 15:39
VICODAN2 anything else? 15:39
VICODAN2 i need to get to work 15:40
adamw #info rc4 is waiting on blocker fixes, we are trying to ping responsible parties. 15:40
adamw #topic Test Day report 15:40
adamw VICODAN2: the agenda's at https://fedoraproject.org/wiki/QA/Meetings/20120409 15:40
adamw so we had power management test day - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management - and installer i18n/l10n test days last week - https://fedoraproject.org/wiki/Test_Day:2012-04-05_L10n_I18n_Installation 15:41
adamw did anyone make it out to those? I suck at attending test days lately. 15:41
VICODAN2 yep 15:41
VICODAN2 i did 15:41
VICODAN2 i did power management day 15:41
adamw how'd they go? 15:41
VICODAN2 pretty good 15:41
VICODAN2 lots of people ran the reports 15:41
VICODAN2 i was impressed as to how well it was actually working 15:42
VICODAN2 f17 was actually able to read my battery info through a virtualbox vm 15:42
VICODAN2 i18n/l10n, didnt attend, dont know anything about it 15:43
adamw looks like we got good turnout for the pm day, yup. 15:43
adamw #info turnout for the power management test day was good, looks like a solid bunch of results - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management 15:43
Martix it was Open House in Brno office :-) 15:43
VICODAN2 brb, hoppin in the shower 15:44
Martix so many people got involved 15:44
adamw cool 15:44
adamw #info PM test day was open house in Brno 15:44
adamw #info seems to have been solid data in the i18n/l10n installation test day too, but the results table is a little odd, may need tidying up 15:45
adamw #topic upcoming events 15:46
adamw so it looks like we have KDE 4.10 tomorrow and Virtualization on Thursday 15:46
adamw er, 4.8, rather 15:46
adamw #info KDE 4.8 Test Day tomorrow - https://fedoraproject.org/wiki/Test_Day:2012-04-10_KDE_4.8 15:46
VICODAN2 when we say "virtualization" are we mainly concerned with KVM? 15:47
Martix yep, I am looking for your test reports :-) 15:47
adamw #info Virtualization Test Day on Thursday - https://fedoraproject.org/wiki/Test_Day:2012-04-12_Virtualization_Test_Day 15:47
adamw VICODAN2: yep 15:47
VICODAN2 k 15:47
adamw VICODAN2: it means 'fedora virt stack' - see the page 15:47
VICODAN2 yep 15:47
jreznik for kde 4.8 rdieter prepared the image, we are finishing test cases, ltinkl reviewed Martix's testcases, looks good 15:47
adamw so the kde page has test cases but the results table is still generic and no special live images up 15:47
jreznik also some marketing is done 15:48
jreznik adamw: yep, I know 15:48
adamw jreznik: looks like you need to update the image links and results table - cool 15:48
jreznik will be fixed once we will have all testcases 15:48
adamw we'll get the test-ann mail approved 15:48
adamw great 15:48
jreznik adamw: Martix should update the link to image, at least he promised it :) 15:48
adamw #info KDE team is on top of preparation for tomorrow 15:48
Martix jreznik: thanks, but we need finish more test cases 15:48
adamw #info virt test day is taking a freeform testing approach, looks like they have the page set up as they want it 15:49
Martix jreznik: its already updated 15:49
jreznik Martix: ok 15:49
Martix jreznik: waiting for sha256 verification 15:49
jreznik I'd like to combine test cases with freeform tests on the rest topics we don't have a test case 15:49
adamw oh yeah, i just saw the 'tbd' and missed the links, d'oh :) 15:49
adamw jreznik: you can certainly do that if you get enough people in IRC to get the chat flowing 15:50
Martix x86_64 image passed media verification, I'll add sha256 sum, but still downloading i686 image 15:50
Martix or can rdieter provide sha256 sums for his images? 15:51
Viking-Ice VICODAN2, I would go as far to say the only thing we care about kvm ( because it's the only solution we can actually do anything about ) 15:51
rdieter Martix: good idea, I totally forgot about that. 15:51
jreznik adamw: I hope to ge traffic but we completely forgot Easter, so a lot of people still on vacations :) 15:52
adamw ah, well, we'll see :) 15:53
adamw okay, so they're both looking pretty well prepared for, let us know if there's anything we can do to help jreznik 15:53
adamw aside from showing up of course :) 15:53
jreznik adamw: yep, thanks :) Martix is still around, so we have a good fedora qa guy taking care of it :) 15:54
adamw well, i wouldn't say 'good'....<ducks> 15:54
adamw oh, and go/no-go is set for wednesday once more. 15:55
adamw i'm not saying it means anything, just that i've seen World Domination For Beginners in martix's desk drawer 15:55
jreznik adamw: :) I should probably use a different word :) amazing? awesome? :) 15:55
adamw and he keeps sending in expense requests for sharks and lasers 15:55
* jreznik knows Martix for several years... 15:56
Martix adamw: hehe, we must block Fedora Beta release for all costs! </irony> :-D 15:56
adamw :P 15:57
adamw okay, so looks like upcoming events are under control 15:57
* jreznik hopes :) 15:57
adamw #topic AutoQA update 15:57
adamw i'm guessing there's no news here again? 15:57
tflink nope, we've been pretty consumed w/ F17 beta testing AFAIK 15:58
adamw fun. :/ 15:59
adamw #info there is no news. ding. 15:59
adamw #topic Open floor 15:59
VICODAN2 back 16:00
adamw so, i did have one thing for open floor, though we're slightly over time 16:00
VICODAN2 go on... 16:00
adamw i can send a formal proposal to the list, but - it actually occurred to me last week as we were slipping a release for a bug in preupgrade that there's no damn reason to slip releases for bugs in preupgrade. 16:01
adamw even if they're on the anaconda side. 16:01
VICODAN2 that's my bug :) 16:01
VICODAN2 i give you permission to move it to final blocker 16:01
* rbergeron doesn't look at this line 16:01
adamw am i missing anything? or should we just treat all preupgrade blockers as 'special' the way we currently treat livecd-iso-to-disk blockers? 16:01
tflink I assume that the rationale is something along the lines of "as long as some upgrade method works"? 16:02
adamw no 16:02
adamw #startmeeting Fedora QA meeting 15:00
zodbot Meeting started Mon Apr 9 15:00:07 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00
adamw #meetingname fedora-qa 15:00
zodbot The meeting name has been set to 'fedora-qa' 15:00
adamw #topic roll call 15:00
adamw well hey, it appears to be meeting time again. 15:00
tflink it does indeed 15:00
* tflink thinks the attendance is going to be a bit light today 15:01
adamw likely 15:01
adamw who's around? come crawl out of the woodwork 15:01
adamw if it's just me and you we may as well cancel 15:02
* Cerlyn is here 15:02
* brunowolff is here 15:02
* nirik is lurking around as always 15:03
* satellit_ listening 15:03
adamw ooh, the woodwork is positively slithering, it appears. 15:03
VICODAN2 HI 15:05
adamw hi dan. 15:05
VICODAN2 how goes it? 15:05
adamw so, we don't have anything from last week that i can think of 15:05
VICODAN2 i just woke up 15:05
adamw anyone else think of anything to follow up on? 15:05
VICODAN2 probably nothing i can offer that hasn't been talked about already 15:06
VICODAN2 i installed RC3 yesterday on a VM 15:06
adamw okay, let's skip previous meeting follow-up then 15:06
adamw #topic Fedora 17 Beta status / blocker review 15:07
adamw so, not looking great here, we have no rc4 and still two open blockers, it seems. unless i missed something this morning. 15:07
VICODAN2 nope sounds about right 15:07
* Viking-Ice sneaks in 15:07
adamw anyone heard anything from mgrepl or wwoods through any side channels? 15:08
tflink nope 15:08
brunowolff I saw a bunch of updates did get pulled in to F17 stable over the weekend. 15:08
nirik that was the gnome 3.4 update. 15:08
VICODAN2 the login screen still shows the sql server login 15:09
adamw brunowolff: yeah, we're tidying up the stuff from rc3. 15:10
brunowolff It looks like today's compose failed. Though it's kind of an odd looking error. 15:10
adamw VICODAN2: that one's not a beta blocker. think desktop team was bikeshedding it, but it should be gone for final one way or another, i guess. 15:10
VICODAN2 yea i'd like to have a word with them 15:11
VICODAN2 oh 15:11
VICODAN2 package dependencies seems to be fixed 15:11
VICODAN2 no more problems when running yum update after installing a bunch of packages with customize now 15:12
VICODAN2 i did have to install twice yesterday, but im going to blame virtualbox on that 15:12
adamw so, basically, seems we need to get out the pokey sticks and start poking mgrepl and wwoods. not a whole lot we can do till then. 15:12
VICODAN2 nope 15:12
adamw rbergeron: have you been performing official pokeage? 15:13
VICODAN2 maybe hes poking them now 15:14
adamw she 15:15
VICODAN2 she's been idle for 20 mins 15:16
adamw oh, well. 15:16
adamw tflink: we don't have any blockers to review, right? 15:16
adamw oh, hey, we do have one new one. 15:16
adamw the other two proposed are already discussed, i just didn't secretaryize from friday yet, my bad. 15:17
adamw #topic Beta blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=809707 15:17
VICODAN2 LOL 15:18
adamw this sounds worse reading through it than it does from the summary... 15:19
VICODAN2 this is not a blocker 15:19
Viking-Ice Do we have any "date" criteria 15:19
Viking-Ice if not then not a blocker just regular bug 15:19
VICODAN2 this is lamer than the y2k bug 15:19
Cerlyn it's a failure to boot due to the RTC not being correct 15:19
adamw yeah. 15:19
adamw that's the problem: if you have system date earlier than 2012-01-29 for any reason (newly bought system, duff system clock, testing something) you get a crash on boot. 15:20
VICODAN2 someone needs a new cr2032 15:20
VICODAN2 yeah but this is complaining about 1-1-2000 15:20
VICODAN2 1-29-2012 is a bigger problem but not as big :P 15:21
Viking-Ice is it not rather rare that that is the case 15:21
Cerlyn This comes up on early XO-1.75 prototypes which occasionally reset their clock for no reason 15:21
VICODAN2 really? 15:21
adamw Cerlyn: yeah, I was wondering about the XO case 15:21
brunowolff I am thinking this is a blocker. But it looked like there was a simple change that could be done to avoid triggering the bug and I think that would be OK for Beta. 15:22
adamw but if they're prototypes...then i guess it's kind of annoying for prototype testers, but not a huge issue 15:22
VICODAN2 oh is that the laptop for the african children? 15:22
Viking-Ice and nobody with the XO team investigating why the clock reset's itselfs? 15:22
Cerlyn Production units should not be prone to doing this provided they aren't kept in storage improperly to the point the RTC battery drains 15:22
rbergeron adamw: not this morning yet. /me is on phone in meeting, i will flog shortly 15:22
adamw rbergeron: set whips to stun 15:23
adamw so we're kind of left with the generalized 'some kind of weird oops or the RTC battery ran out' case, really 15:23
VICODAN2 yup 15:23
tflink sounds like a conditional violation of the "needs to boot into graphical env" criterion 15:24
VICODAN2 not a blocker, but a bug none the less, i can think of way more important things to worry about 15:24
Cerlyn Is there any known signs that clock values other than an RTC reset may cause this? 15:24
adamw Cerlyn: well, any value before jan 29th causes it. 15:25
adamw but there's very few reasons to have a system date that wrong that i can think of. 15:25
VICODAN2 good thing it's April 9th 15:25
rbergeron adamw: willdo 15:25
VICODAN2 doesn't NTP start before Gnome? 15:26
tflink assuming you have it turned on, yes 15:26
Viking-Ice in any case I vote -1 on blocker even NTH since this is more an exception than a rule that this happens 15:26
VICODAN2 well, problem solved. 15:26
adamw VICODAN2: ntp isn't enabled by default 15:26
VICODAN2 i know. 15:26
VICODAN2 you have to have dead battery and ntp turned off for this to happen 15:27
adamw but yeah, i think i'm with viking-ice, the cases that are going to hit this are just too corner-y and there's an obvious 'workaround' (fix the darn date) 15:27
VICODAN2 i have a better chance of winning the lottery 15:27
adamw probably +1 final blocker, but -1 beta 15:27
tflink yeah, this seems like a rather hairy failure mode but I'm not sure it's beta blocker worty 15:28
brunowolff It won't be obvious that setting the correct date in the bios is the needed fix. So it would be nice to have this documented with commmon bugs. 15:28
Viking-Ice yeah +1 final 15:28
VICODAN2 +1 15:28
Cerlyn +1 15:28
adamw tflink: gnome's failure modes now are just hairy in general. in gnome2 if g-s-d crashed you got a basically working desktop with fonts and sizes and window theme and so on that you didn't specify. in gnome3 you get the fail whale. progress! 15:28
tflink at least its obvious when something goes wrong 15:29
VICODAN2 can we just move back to gnome 2? 15:29
adamw propose #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date 15:29
VICODAN2 i propose a move back to gnome 2 15:29
adamw VICODAN2: not here, you don't. 15:29
adamw :P 15:29
VICODAN2 :( 15:29
tflink adamw: ack 15:30
VICODAN2 its funny 15:30
VICODAN2 you install f17 15:30
VICODAN2 login 15:30
VICODAN2 and you are presented with an empty desktop 15:30
brunowolff I'd prefer to see common bugs suggestion for this one. 15:30
VICODAN2 with like 15:30
VICODAN2 "windows" and "activities" 15:31
adamw brunowolff: stick 'commonbugs' in the keywords list 15:31
adamw VICODAN2: the desktop battles belong on devel list, or desktop list, or really anywhere that's not here. =) 15:31
Martix regarding Test Days, could you approve mail for tomorrow test 15:32
Martix day? 15:32
VICODAN2 it's really terrible, i'll look them up. 15:32
adamw Martix: will do 15:32
Martix adamw: thanks 15:32
adamw any more acks? 15:32
brunowolff For right now I was suggesting ammending the proposal, but if no one has any objections, I'll just mark the bug. 15:32
adamw oh okay 15:32
adamw commonbugs proposing doesn't really have to follow nth/blocker procedure 15:32
Cerlyn adamw: Do we wish to propose it as a final blocker in the same motion, or is that a later vote? 15:33
VICODAN2 it's a final blocker 15:33
brunowolff ack 15:33
adamw you can nominate a bug for commonbugs any time, at your own authority, it's just a 'suggestion' to people who like to update the page 15:33
adamw Cerlyn: i was going to keep it for later just to keep things simple 15:33
adamw it sounds like it'll likely get fixed before we hit final blocker review anyhow 15:33
VICODAN2 yep 15:34
adamw #agreed 809707 is rejected as a beta blocker as we can only think of very few cases which will be hit by it, and there is an obvious 'workaround' (really, the fix): correct the system date 15:34
VICODAN2 also 15:35
VICODAN2 other workaround is use ntp 15:35
adamw anything else anyone's worried about for beta? 15:35
VICODAN2 well 15:35
VICODAN2 let me tell you about my experience yesterday 15:35
VICODAN2 again this is in a vbox vm 15:35
VICODAN2 i install f17 15:35
VICODAN2 im at the end 15:35
VICODAN2 "congratulations fedora is installed!" "remove the cdrom and reboot!" remove cdrom from drive and press reboot and it hangs 15:36
VICODAN2 do hard reset, reboot and im dropped in to a grub shell 15:36
VICODAN2 booted off DVD again, did an upgrade and it was fine 15:36
tflink VICODAN2: have you filed a bug? 15:36
adamw if it's not reproducible and you didn't get logs from the failure, there's not a whole lot anyone can do with that. 15:36
VICODAN2 no. I want to reproduce it again 15:36
VICODAN2 and i was hoping rc4 would drop soon 15:37
tflink VICODAN2: make sure you grab the logs from the failed install 15:37
VICODAN2 so I could report it against RC4 15:37
VICODAN2 well it technically wasn't a "failed install" 15:37
VICODAN2 when is RC4 dropping? 15:37
tflink not sure, we're waiting for blocker fixes 15:38
VICODAN2 so a week? 2 at most? 15:38
tflink the hope is in the next day or two 15:38
VICODAN2 k 15:38
tflink but we're getting a bit off into the weeds for a meeting, here 15:38
VICODAN2 i'll wait for rc4 and try it again 15:39
VICODAN2 how do i grab logs from anacdona/install? 15:39
tflink VICODAN2: can you ask in #fedora-qa, this is getting off topic for the meeting 15:39
VICODAN2 yessir 15:39
tflink thanks 15:39
adamw okay, so, there we are. 15:39
VICODAN2 anything else? 15:39
VICODAN2 i need to get to work 15:40
adamw #info rc4 is waiting on blocker fixes, we are trying to ping responsible parties. 15:40
adamw #topic Test Day report 15:40
adamw VICODAN2: the agenda's at https://fedoraproject.org/wiki/QA/Meetings/20120409 15:40
adamw so we had power management test day - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management - and installer i18n/l10n test days last week - https://fedoraproject.org/wiki/Test_Day:2012-04-05_L10n_I18n_Installation 15:41
adamw did anyone make it out to those? I suck at attending test days lately. 15:41
VICODAN2 yep 15:41
VICODAN2 i did 15:41
VICODAN2 i did power management day 15:41
adamw how'd they go? 15:41
VICODAN2 pretty good 15:41
VICODAN2 lots of people ran the reports 15:41
VICODAN2 i was impressed as to how well it was actually working 15:42
VICODAN2 f17 was actually able to read my battery info through a virtualbox vm 15:42
VICODAN2 i18n/l10n, didnt attend, dont know anything about it 15:43
adamw looks like we got good turnout for the pm day, yup. 15:43
adamw #info turnout for the power management test day was good, looks like a solid bunch of results - https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management 15:43
Martix it was Open House in Brno office :-) 15:43
VICODAN2 brb, hoppin in the shower 15:44
Martix so many people got involved 15:44
adamw cool 15:44
adamw #info PM test day was open house in Brno 15:44
adamw #info seems to have been solid data in the i18n/l10n installation test day too, but the results table is a little odd, may need tidying up 15:45
adamw #topic upcoming events 15:46
adamw so it looks like we have KDE 4.10 tomorrow and Virtualization on Thursday 15:46
adamw er, 4.8, rather 15:46
adamw #info KDE 4.8 Test Day tomorrow - https://fedoraproject.org/wiki/Test_Day:2012-04-10_KDE_4.8 15:46
VICODAN2 when we say "virtualization" are we mainly concerned with KVM? 15:47
Martix yep, I am looking for your test reports :-) 15:47
adamw #info Virtualization Test Day on Thursday - https://fedoraproject.org/wiki/Test_Day:2012-04-12_Virtualization_Test_Day 15:47
adamw VICODAN2: yep 15:47
VICODAN2 k 15:47
adamw VICODAN2: it means 'fedora virt stack' - see the page 15:47
VICODAN2 yep 15:47
jreznik for kde 4.8 rdieter prepared the image, we are finishing test cases, ltinkl reviewed Martix's testcases, looks good 15:47
adamw so the kde page has test cases but the results table is still generic and no special live images up 15:47
jreznik also some marketing is done 15:48
jreznik adamw: yep, I know 15:48
adamw jreznik: looks like you need to update the image links and results table - cool 15:48
jreznik will be fixed once we will have all testcases 15:48
adamw we'll get the test-ann mail approved 15:48
adamw great 15:48
jreznik adamw: Martix should update the link to image, at least he promised it :) 15:48
adamw #info KDE team is on top of preparation for tomorrow 15:48
Martix jreznik: thanks, but we need finish more test cases 15:48
adamw #info virt test day is taking a freeform testing approach, looks like they have the page set up as they want it 15:49
Martix jreznik: its already updated 15:49
jreznik Martix: ok 15:49
Martix jreznik: waiting for sha256 verification 15:49
jreznik I'd like to combine test cases with freeform tests on the rest topics we don't have a test case 15:49
adamw oh yeah, i just saw the 'tbd' and missed the links, d'oh :) 15:49
adamw jreznik: you can certainly do that if you get enough people in IRC to get the chat flowing 15:50
Martix x86_64 image passed media verification, I'll add sha256 sum, but still downloading i686 image 15:50
Martix or can rdieter provide sha256 sums for his images? 15:51
Viking-Ice VICODAN2, I would go as far to say the only thing we care about kvm ( because it's the only solution we can actually do anything about ) 15:51
rdieter Martix: good idea, I totally forgot about that. 15:51
jreznik adamw: I hope to ge traffic but we completely forgot Easter, so a lot of people still on vacations :) 15:52
adamw ah, well, we'll see :) 15:53
adamw okay, so they're both looking pretty well prepared for, let us know if there's anything we can do to help jreznik 15:53
adamw aside from showing up of course :) 15:53
jreznik adamw: yep, thanks :) Martix is still around, so we have a good fedora qa guy taking care of it :) 15:54
adamw well, i wouldn't say 'good'....<ducks> 15:54
adamw oh, and go/no-go is set for wednesday once more. 15:55
adamw i'm not saying it means anything, just that i've seen World Domination For Beginners in martix's desk drawer 15:55
jreznik adamw: :) I should probably use a different word :) amazing? awesome? :) 15:55
adamw and he keeps sending in expense requests for sharks and lasers 15:55
* jreznik knows Martix for several years... 15:56
Martix adamw: hehe, we must block Fedora Beta release for all costs! </irony> :-D 15:56
adamw :P 15:57
adamw okay, so looks like upcoming events are under control 15:57
* jreznik hopes :) 15:57
adamw #topic AutoQA update 15:57
adamw i'm guessing there's no news here again? 15:57
tflink nope, we've been pretty consumed w/ F17 beta testing AFAIK 15:58
adamw fun. :/ 15:59
adamw #info there is no news. ding. 15:59
adamw #topic Open floor 15:59
VICODAN2 back 16:00
adamw so, i did have one thing for open floor, though we're slightly over time 16:00
VICODAN2 go on... 16:00
adamw i can send a formal proposal to the list, but - it actually occurred to me last week as we were slipping a release for a bug in preupgrade that there's no damn reason to slip releases for bugs in preupgrade. 16:01
adamw even if they're on the anaconda side. 16:01
VICODAN2 that's my bug :) 16:01
VICODAN2 i give you permission to move it to final blocker 16:01
* rbergeron doesn't look at this line 16:01
adamw am i missing anything? or should we just treat all preupgrade blockers as 'special' the way we currently treat livecd-iso-to-disk blockers? 16:01
tflink I assume that the rationale is something along the lines of "as long as some upgrade method works"? 16:02
adamw no 16:02
adamw the rationale is that preupgrade doesn't pull anything from anywhere that goes out as media 16:02
brunowolff That's assuming we know the fix needs to be in preupgrade, not in some f17 package. 16:02
adamw no 16:02
adamw think about it :) 16:02
tflink adamw: the difference in my mind is that most livecd-iso-to-disk bugs can be fixed outside of the release 16:02
adamw what's the problem with testing preupgrade? 16:02
adamw we always have to wait for a stable update push to test it 16:03
VICODAN2 why not just get rid of preupgrade all together? 16:03
adamw it's so annoying...the only way we can test preupgrade blockers is to update the tree on the mirrors...just re-spinning the media doesn't help... 16:03
adamw *gears whirring* 16:03
adamw then why are we blocking media composes on preupgrade bugs? :) 16:03
tflink officially, yes but now that we have a method of testing preupgrade before everything hits stable, it's a little easier 16:03
tflink because preupgrade requires interaction with anaconda, which can't be fixed by updates 16:04
adamw tflink: follow the thought process, though. point is, preupgrade process and media composes are completely independent of each other, effectively. 16:04
adamw yes it can. for preupgrade. 16:04
VICODAN2 look 16:04
adamw preupgrade never uses the anaconda on the media. it always pulls its anaconda from the tree on the repos. 16:04
VICODAN2 you can upgrade via yum right? 16:04
VICODAN2 you can upgrade via dvd right? 16:04
tflink I didn't think that preupgrade pulled from updates, though 16:04
adamw if we ship Beta with anaconda that's 'broken' re preupgrade, and we then push an anaconda update that fixes preupgrade stable, does preupgrade start working? 16:04
tflink I thought that it always pulls from stable 16:04
adamw tflink: there is no updates before release 16:05
adamw there are only two repos for f17 at present: updates-testing and 'stable' 16:05
adamw when we approve an update, it goes to 'stable' 16:05
VICODAN2 lol "stable" 16:05
tflink adamw: updates/updates-testing - not stable was what I was getting at 16:05
adamw tflink: there is no 'updates' for branched releases. the tree is empty. 16:05
VICODAN2 but it pulls from updates-testing by default anyway 16:05
tflink adamw: preupgrade uses the initrd and vmlinuz from the tree 16:05
adamw tflink: right. but that gets rebuilt every day from whatever's in 'stable'. as soon as we push a fixed anaconda, we get a new vmlinuz/initrd on the mirrors. 16:06
tflink we do? 16:06
VICODAN2 lol 16:06
tflink I thought that was only updated on the mirrors @ releases 16:06
adamw i believe so. i might be wrong, of course. 16:06
VICODAN2 again, why do we need preupgrade? 16:06
VICODAN2 last question before i leave 16:06
adamw tflink: no, otherwise we'd never get preupgrade behaviour changes except at alpha, beta and final. 16:07
adamw VICODAN2: in theory, it's a more reliable mechanism than yum. we don't officially support yum upgrades. preupgrade is the supported 'online' upgrade method. 16:07
VICODAN2 i would say let's deprecate preupgrade and make yum the new standard 16:07
VICODAN2 yum works great 16:07
VICODAN2 i've upgraded from 11->12->13->14->15 via yum 16:07
VICODAN2 the only thing 16:08
VICODAN2 is making yum handle the new boot process stuffs 16:08
VICODAN2 which ims sure it could do 16:08
brunowolff You need to know special things to to yum upgrades between some releases, preupgrade is supposed to hide that from you. 16:08
VICODAN2 that's my $.02 16:08
tflink adamw: have we had many changes in preupgrade that required anaconda fixes? the one that I remember from F16 required changes in preupgrade only 16:08
adamw there would not be any support for that from devel side. they are fairly strongly of the opinion that yum is not a supportable upgrade mechanism. it's sidetracking the question of whether preupgrade issues need to block media composes, anyway. 16:08
VICODAN2 no need to hide it 16:08
tflink unless I'm just mis-remembering 16:08
adamw nirik: can you confirm or deny whether i'm right about how branched tree works? 16:09
brunowolff For you maybe. For lots of people yes. 16:09
VICODAN2 well, we aren't getting much "support" from the devel side on preupgrade now are we? 16:09
* nirik reads up. 16:09
VICODAN2 has anyone done any work on this? 16:09
adamw while we're doing that - preupgrade goes out and reads https://mirrors.fedoraproject.org/releases.txt to find out where to get its anaconda from. 16:09
VICODAN2 i found the bug like a month or two ago 16:09
adamw VICODAN2: which bug? there have been like eight preupgrade bugs, in serial. we fix one of them at a time, and keep finding more. 16:10
VICODAN2 f16, preupgrade to 17 16:10
adamw VICODAN2: the current preupgrade blocker was not filed by you. it was filed by me. 16:10
adamw https://bugzilla.redhat.com/show_bug.cgi?id=810391 16:10
nirik adamw: right. there's updates-testing and empty updates, and a 'base' repo. We rebuild the base repo every night with anything thats going to stable. 16:10
VICODAN2 so mine was fixed then eh? 16:10
VICODAN2 all i know is that it's still not working 16:10
VICODAN2 ill check my bug then 16:10
adamw nirik: so say we build rc4 right now, then we get an anaconda that fixes preupgrade tomorrow 16:10
VICODAN2 build rc5! 16:11
VICODAN2 :P 16:11
adamw nirik: whenever that anaconda gets pushed 'stable', preupgrade will start working, right? it doesn't matter that it wasn't in the rc4 compose? 16:11
nirik adamw: I think so, unless preupgrades releases.txt points to the release instead of the f17 devel tree. 16:11
VICODAN2 ok my boss just called me and yelled at me 16:11
VICODAN2 i need to go now, i've caused enough havoc here 16:11
VICODAN2 have fun y'all 16:11
adamw nirik: it uses https://mirrors.fedoraproject.org/releases.txt 16:11
tflink nirik: I didn't think that the devel tree was mirrored in many places 16:11
tflink ie most mirrors use the release 16:12
adamw nirik: what's that pointing to? 16:12
tflink but I could easily be wrong 16:12
brunowolff And if the bug is in preupgrade, that will be fixed in earlier releases. So I am buying that preupgrade should not block composes. 16:12
nirik adamw: correct. that points to whatever we point it at. ;) Right now it points to the devel tree. 16:12
nirik tflink: all mirrors who do rawhide should also have f17 16:12
nirik right now we have: 16:13
nirik (flood coming) 16:13
nirik [Fedora 17 (Beefy Miracle)] 16:13
nirik stable=False 16:13
nirik preupgrade-ok=True 16:13
nirik version=17 16:13
nirik mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-17&arch=$basearch 16:13
nirik installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/development/17/$basearch/os/ 16:13
adamw brunowolff: well, thinking about it, so far i think it shows that preupgrade shouldn't block alpha or beta composes 16:14
adamw Final may be a different question 16:14
adamw nirik: for final releases, what does preupgrade use? is it using the original 'frozen' release tree, i.e. whatever anaconda we shipped at release time? 16:14
nirik yeah, we do point to releases for final. 16:14
adamw okay 16:14
adamw (though we could probably improve that if we wanted, i guess.) 16:15
nirik mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-16&arch=$basearch 16:15
nirik installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/16/Fedora/$basearch/os/ 16:15
adamw so, i think i'm right in that alpha and beta composes can disregard preupgrade 16:15
tflink yeah, that makes sense to me 16:15
adamw okay...can anyone else see anything we're not accounting for? 16:15
adamw if everyone's following the logic so far, i'll send a proposal to the list - guess the easiest thing is just to push the preupgrade criterion to final 16:16
tflink sounds like a plan 16:16
nirik I'd be worried if we moved all preupgrade to final tho 16:16
adamw 'all preupgrade'? 16:17
brunowolff Just because it blocks composes doesn't necessarily mean we wouldn't block a release if needed fix for say anaconda hadn't gone to stable. 16:17
nirik well, if we ignore preupgrade for alpha and beta it means at final we would have a nasty set of russian dolls of bugs to try and fix before release. 16:17
adamw nirik: not being blocking doesn't mean it gets 'ignored' 16:17
nirik right. 16:17
adamw nirik: we usually try and do the whole matrix at alpha and beta stages 16:17
adamw but yeah, i take the point 16:18
adamw i guess we can discuss further on list 16:18
nirik just wanted to clarify that it wasn't ignoring it... just not blocking composes. 16:18
adamw thanks for letting me kick that one around :) 16:18
adamw #action adamw to send formal proposal for preupgrade criteria adjustment to the list 16:18
adamw anyone have anything else for open floor? 16:18
robatino long term, the mediacheck needs to be exposed again 16:18
robatino i filed https://bugzilla.redhat.com/show_bug.cgi?id=809663 16:18
robatino right now, it's not discoverable for install discs 16:19
adamw right, i saw that bug 16:19
adamw #info mediacheck is now 'hidden' as it was previously part of loader, it can be prompted with a cmdline parameter but most people won't know that: https://bugzilla.redhat.com/show_bug.cgi?id=809663 16:20
tflink wouldn't the required change be in lorax/pungi? 16:20
* tflink can't remember if pungi does anything with the syslinux menu off the top of his head 16:20
robatino and it might be good to modify the final criteria to require mediacheck (we could do it right now since it's there already) 16:22
robatino just its existence, i mean, not having it done by default 16:22
adamw right, i think we have a dormant list thread about that? maybe wake it up 16:24
adamw okay...anything else? 16:25
tflink I have some other questions about the preupgrade issue, but they can wait for the email thread 16:26
adamw okie dokie 16:26
* adamw sets fuse for 2 minutes 16:26
adamw thanks for coming, all! 16:28
adamw #endmeeting 16:28

Generated by irclog2html.py 2.8 by Marius Gedminas - find it at mg.pov.lt! ! style="background-color: #407a40" | adamw | style="color: #407a40" | the rationale is that preupgrade doesn't pull anything from anywhere that goes out as media || 16:02 |- id="t16:02:41" ! style="background-color: #488888" | brunowolff | style="color: #488888" | That's assuming we know the fix needs to be in preupgrade, not in some f17 package. || 16:02 |- id="t16:02:45" ! style="background-color: #407a40" | adamw | style="color: #407a40" | no || 16:02 |- id="t16:02:49" ! style="background-color: #407a40" | adamw | style="color: #407a40" | think about it :) || 16:02 |- id="t16:02:50" ! style="background-color: #818144" | tflink | style="color: #818144" | adamw: the difference in my mind is that most livecd-iso-to-disk bugs can be fixed outside of the release || 16:02 |- id="t16:02:53" ! style="background-color: #407a40" | adamw | style="color: #407a40" | what's the problem with testing preupgrade? || 16:02 |- id="t16:03:07" ! style="background-color: #407a40" | adamw | style="color: #407a40" | we always have to wait for a stable update push to test it || 16:03 |- id="t16:03:16" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | why not just get rid of preupgrade all together? || 16:03 |- id="t16:03:28" ! style="background-color: #407a40" | adamw | style="color: #407a40" | it's so annoying...the only way we can test preupgrade blockers is to update the tree on the mirrors...just re-spinning the media doesn't help... || 16:03 |- id="t16:03:31" ! style="background-color: #407a40" | adamw | style="color: #407a40" | *gears whirring* || 16:03 |- id="t16:03:38" ! style="background-color: #407a40" | adamw | style="color: #407a40" | then why are we blocking media composes on preupgrade bugs? :) || 16:03 |- id="t16:03:39" ! style="background-color: #818144" | tflink | style="color: #818144" | officially, yes but now that we have a method of testing preupgrade before everything hits stable, it's a little easier || 16:03 |- id="t16:04:01" ! style="background-color: #818144" | tflink | style="color: #818144" | because preupgrade requires interaction with anaconda, which can't be fixed by updates || 16:04 |- id="t16:04:04" ! style="background-color: #407a40" | adamw | style="color: #407a40" | tflink: follow the thought process, though. point is, preupgrade process and media composes are completely independent of each other, effectively. || 16:04 |- id="t16:04:08" ! style="background-color: #407a40" | adamw | style="color: #407a40" | yes it can. for preupgrade. || 16:04 |- id="t16:04:23" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | look || 16:04 |- id="t16:04:25" ! style="background-color: #407a40" | adamw | style="color: #407a40" | preupgrade never uses the anaconda on the media. it always pulls its anaconda from the tree on the repos. || 16:04 |- id="t16:04:28" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | you can upgrade via yum right? || 16:04 |- id="t16:04:37" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | you can upgrade via dvd right? || 16:04 |- id="t16:04:47" ! style="background-color: #818144" | tflink | style="color: #818144" | I didn't think that preupgrade pulled from updates, though || 16:04 |- id="t16:04:52" ! style="background-color: #407a40" | adamw | style="color: #407a40" | if we ship Beta with anaconda that's 'broken' re preupgrade, and we then push an anaconda update that fixes preupgrade stable, does preupgrade start working? || 16:04 |- id="t16:04:57" ! style="background-color: #818144" | tflink | style="color: #818144" | I thought that it always pulls from stable || 16:04 |- id="t16:05:04" ! style="background-color: #407a40" | adamw | style="color: #407a40" | tflink: there is no updates before release || 16:05 |- id="t16:05:17" ! style="background-color: #407a40" | adamw | style="color: #407a40" | there are only two repos for f17 at present: updates-testing and 'stable' || 16:05 |- id="t16:05:24" ! style="background-color: #407a40" | adamw | style="color: #407a40" | when we approve an update, it goes to 'stable' || 16:05 |- id="t16:05:26" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | lol "stable" || 16:05 |- id="t16:05:27" ! style="background-color: #818144" | tflink | style="color: #818144" | adamw: updates/updates-testing - not stable was what I was getting at || 16:05 |- id="t16:05:38" ! style="background-color: #407a40" | adamw | style="color: #407a40" | tflink: there is no 'updates' for branched releases. the tree is empty. || 16:05 |- id="t16:05:43" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | but it pulls from updates-testing by default anyway || 16:05 |- id="t16:05:44" ! style="background-color: #818144" | tflink | style="color: #818144" | adamw: preupgrade uses the initrd and vmlinuz from the tree || 16:05 |- id="t16:06:09" ! style="background-color: #407a40" | adamw | style="color: #407a40" | tflink: right. but that gets rebuilt every day from whatever's in 'stable'. as soon as we push a fixed anaconda, we get a new vmlinuz/initrd on the mirrors. || 16:06 |- id="t16:06:18" ! style="background-color: #818144" | tflink | style="color: #818144" | we do? || 16:06 |- id="t16:06:30" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | lol || 16:06 |- id="t16:06:32" ! style="background-color: #818144" | tflink | style="color: #818144" | I thought that was only updated on the mirrors @ releases || 16:06 |- id="t16:06:33" ! style="background-color: #407a40" | adamw | style="color: #407a40" | i believe so. i might be wrong, of course. || 16:06 |- id="t16:06:54" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | again, why do we need preupgrade? || 16:06 |- id="t16:06:58" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | last question before i leave || 16:06 |- id="t16:07:00" ! style="background-color: #407a40" | adamw | style="color: #407a40" | tflink: no, otherwise we'd never get preupgrade behaviour changes except at alpha, beta and final. || 16:07 |- id="t16:07:20" ! style="background-color: #407a40" | adamw | style="color: #407a40" | VICODAN2: in theory, it's a more reliable mechanism than yum. we don't officially support yum upgrades. preupgrade is the supported 'online' upgrade method. || 16:07 |- id="t16:07:41" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | i would say let's deprecate preupgrade and make yum the new standard || 16:07 |- id="t16:07:44" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | yum works great || 16:07 |- id="t16:07:53" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | i've upgraded from 11->12->13->14->15 via yum || 16:07 |- id="t16:08:19" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | the only thing || 16:08 |- id="t16:08:33" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | is making yum handle the new boot process stuffs || 16:08 |- id="t16:08:37" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | which ims sure it could do || 16:08 |- id="t16:08:43" ! style="background-color: #488888" | brunowolff | style="color: #488888" | You need to know special things to to yum upgrades between some releases, preupgrade is supposed to hide that from you. || 16:08 |- id="t16:08:45" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | that's my $.02 || 16:08 |- id="t16:08:52" ! style="background-color: #818144" | tflink | style="color: #818144" | adamw: have we had many changes in preupgrade that required anaconda fixes? the one that I remember from F16 required changes in preupgrade only || 16:08 |- id="t16:08:55" ! style="background-color: #407a40" | adamw | style="color: #407a40" | there would not be any support for that from devel side. they are fairly strongly of the opinion that yum is not a supportable upgrade mechanism. it's sidetracking the question of whether preupgrade issues need to block media composes, anyway. || 16:08 |- id="t16:08:55" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | no need to hide it || 16:08 |- id="t16:08:57" ! style="background-color: #818144" | tflink | style="color: #818144" | unless I'm just mis-remembering || 16:08 |- id="t16:09:24" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: can you confirm or deny whether i'm right about how branched tree works? || 16:09 |- id="t16:09:25" ! style="background-color: #488888" | brunowolff | style="color: #488888" | For you maybe. For lots of people yes. || 16:09 |- id="t16:09:38" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | well, we aren't getting much "support" from the devel side on preupgrade now are we? || 16:09 |- id="t16:09:41" | colspan="2" | * nirik reads up. || 16:09 |- id="t16:09:44" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | has anyone done any work on this? || 16:09 |- id="t16:09:47" ! style="background-color: #407a40" | adamw | style="color: #407a40" | while we're doing that - preupgrade goes out and reads https://mirrors.fedoraproject.org/releases.txt to find out where to get its anaconda from. || 16:09 |- id="t16:09:52" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | i found the bug like a month or two ago || 16:09 |- id="t16:10:09" ! style="background-color: #407a40" | adamw | style="color: #407a40" | VICODAN2: which bug? there have been like eight preupgrade bugs, in serial. we fix one of them at a time, and keep finding more. || 16:10 |- id="t16:10:21" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | f16, preupgrade to 17 || 16:10 |- id="t16:10:24" ! style="background-color: #407a40" | adamw | style="color: #407a40" | VICODAN2: the current preupgrade blocker was not filed by you. it was filed by me. || 16:10 |- id="t16:10:28" ! style="background-color: #407a40" | adamw | style="color: #407a40" | https://bugzilla.redhat.com/show_bug.cgi?id=810391 || 16:10 |- id="t16:10:33" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | adamw: right. there's updates-testing and empty updates, and a 'base' repo. We rebuild the base repo every night with anything thats going to stable. || 16:10 |- id="t16:10:33" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | so mine was fixed then eh? || 16:10 |- id="t16:10:38" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | all i know is that it's still not working || 16:10 |- id="t16:10:44" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | ill check my bug then || 16:10 |- id="t16:10:53" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: so say we build rc4 right now, then we get an anaconda that fixes preupgrade tomorrow || 16:10 |- id="t16:11:07" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | build rc5! || 16:11 |- id="t16:11:09" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | :P || 16:11 |- id="t16:11:09" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: whenever that anaconda gets pushed 'stable', preupgrade will start working, right? it doesn't matter that it wasn't in the rc4 compose? || 16:11 |- id="t16:11:35" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | adamw: I think so, unless preupgrades releases.txt points to the release instead of the f17 devel tree. || 16:11 |- id="t16:11:38" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | ok my boss just called me and yelled at me || 16:11 |- id="t16:11:45" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | i need to go now, i've caused enough havoc here || 16:11 |- id="t16:11:48" ! style="background-color: #854685" | VICODAN2 | style="color: #854685" | have fun y'all || 16:11 |- id="t16:11:50" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: it uses https://mirrors.fedoraproject.org/releases.txt || 16:11 |- id="t16:11:55" ! style="background-color: #818144" | tflink | style="color: #818144" | nirik: I didn't think that the devel tree was mirrored in many places || 16:11 |- id="t16:12:10" ! style="background-color: #818144" | tflink | style="color: #818144" | ie most mirrors use the release || 16:12 |- id="t16:12:13" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: what's that pointing to? || 16:12 |- id="t16:12:15" ! style="background-color: #818144" | tflink | style="color: #818144" | but I could easily be wrong || 16:12 |- id="t16:12:32" ! style="background-color: #488888" | brunowolff | style="color: #488888" | And if the bug is in preupgrade, that will be fixed in earlier releases. So I am buying that preupgrade should not block composes. || 16:12 |- id="t16:12:37" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | adamw: correct. that points to whatever we point it at. ;) Right now it points to the devel tree. || 16:12 |- id="t16:12:50" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | tflink: all mirrors who do rawhide should also have f17 || 16:12 |- id="t16:13:41" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | right now we have: || 16:13 |- id="t16:13:49" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | (flood coming) || 16:13 |- id="t16:13:52" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | [Fedora 17 (Beefy Miracle)] || 16:13 |- id="t16:13:52" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | stable=False || 16:13 |- id="t16:13:53" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | preupgrade-ok=True || 16:13 |- id="t16:13:53" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | version=17 || 16:13 |- id="t16:13:53" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-17&arch=$basearch || 16:13 |- id="t16:13:53" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/development/17/$basearch/os/ || 16:13 |- id="t16:14:07" ! style="background-color: #407a40" | adamw | style="color: #407a40" | brunowolff: well, thinking about it, so far i think it shows that preupgrade shouldn't block alpha or beta composes || 16:14 |- id="t16:14:10" ! style="background-color: #407a40" | adamw | style="color: #407a40" | Final may be a different question || 16:14 |- id="t16:14:42" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: for final releases, what does preupgrade use? is it using the original 'frozen' release tree, i.e. whatever anaconda we shipped at release time? || 16:14 |- id="t16:14:50" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | yeah, we do point to releases for final. || 16:14 |- id="t16:14:53" ! style="background-color: #407a40" | adamw | style="color: #407a40" | okay || 16:14 |- id="t16:15:03" ! style="background-color: #407a40" | adamw | style="color: #407a40" | (though we could probably improve that if we wanted, i guess.) || 16:15 |- id="t16:15:04" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-16&arch=$basearch || 16:15 |- id="t16:15:04" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/16/Fedora/$basearch/os/ || 16:15 |- id="t16:15:20" ! style="background-color: #407a40" | adamw | style="color: #407a40" | so, i think i'm right in that alpha and beta composes can disregard preupgrade || 16:15 |- id="t16:15:31" ! style="background-color: #818144" | tflink | style="color: #818144" | yeah, that makes sense to me || 16:15 |- id="t16:15:42" ! style="background-color: #407a40" | adamw | style="color: #407a40" | okay...can anyone else see anything we're not accounting for? || 16:15 |- id="t16:16:00" ! style="background-color: #407a40" | adamw | style="color: #407a40" | if everyone's following the logic so far, i'll send a proposal to the list - guess the easiest thing is just to push the preupgrade criterion to final || 16:16 |- id="t16:16:19" ! style="background-color: #818144" | tflink | style="color: #818144" | sounds like a plan || 16:16 |- id="t16:16:47" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | I'd be worried if we moved all preupgrade to final tho || 16:16 |- id="t16:17:09" ! style="background-color: #407a40" | adamw | style="color: #407a40" | 'all preupgrade'? || 16:17 |- id="t16:17:21" ! style="background-color: #488888" | brunowolff | style="color: #488888" | Just because it blocks composes doesn't necessarily mean we wouldn't block a release if needed fix for say anaconda hadn't gone to stable. || 16:17 |- id="t16:17:36" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | well, if we ignore preupgrade for alpha and beta it means at final we would have a nasty set of russian dolls of bugs to try and fix before release. || 16:17 |- id="t16:17:50" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: not being blocking doesn't mean it gets 'ignored' || 16:17 |- id="t16:17:56" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | right. || 16:17 |- id="t16:17:56" ! style="background-color: #407a40" | adamw | style="color: #407a40" | nirik: we usually try and do the whole matrix at alpha and beta stages || 16:17 |- id="t16:18:03" ! style="background-color: #407a40" | adamw | style="color: #407a40" | but yeah, i take the point || 16:18 |- id="t16:18:06" ! style="background-color: #407a40" | adamw | style="color: #407a40" | i guess we can discuss further on list || 16:18 |- id="t16:18:13" ! style="background-color: #8c4a4a" | nirik | style="color: #8c4a4a" | just wanted to clarify that it wasn't ignoring it... just not blocking composes. || 16:18 |- id="t16:18:15" ! style="background-color: #407a40" | adamw | style="color: #407a40" | thanks for letting me kick that one around :) || 16:18 |- id="t16:18:27" ! style="background-color: #407a40" | adamw | style="color: #407a40" | #action adamw to send formal proposal for preupgrade criteria adjustment to the list || 16:18 |- id="t16:18:32" ! style="background-color: #407a40" | adamw | style="color: #407a40" | anyone have anything else for open floor? || 16:18 |- id="t16:18:44" ! style="background-color: #57a657" | robatino | style="color: #57a657" | long term, the mediacheck needs to be exposed again || 16:18 |- id="t16:18:58" ! style="background-color: #57a657" | robatino | style="color: #57a657" | i filed https://bugzilla.redhat.com/show_bug.cgi?id=809663 || 16:18 |- id="t16:19:10" ! style="background-color: #57a657" | robatino | style="color: #57a657" | right now, it's not discoverable for install discs || 16:19 |- id="t16:19:48" ! style="background-color: #407a40" | adamw | style="color: #407a40" | right, i saw that bug || 16:19 |- id="t16:20:14" ! style="background-color: #407a40" | adamw | style="color: #407a40" | #info mediacheck is now 'hidden' as it was previously part of loader, it can be prompted with a cmdline parameter but most people won't know that: https://bugzilla.redhat.com/show_bug.cgi?id=809663 || 16:20 |- id="t16:20:25" ! style="background-color: #818144" | tflink | style="color: #818144" | wouldn't the required change be in lorax/pungi? || 16:20 |- id="t16:20:51" | colspan="2" | * tflink can't remember if pungi does anything with the syslinux menu off the top of his head || 16:20 |- id="t16:22:25" ! style="background-color: #57a657" | robatino | style="color: #57a657" | and it might be good to modify the final criteria to require mediacheck (we could do it right now since it's there already) || 16:22 |- id="t16:22:59" ! style="background-color: #57a657" | robatino | style="color: #57a657" | just its existence, i mean, not having it done by default || 16:22 |- id="t16:24:04" ! style="background-color: #407a40" | adamw | style="color: #407a40" | right, i think we have a dormant list thread about that? maybe wake it up || 16:24 |- id="t16:25:38" ! style="background-color: #407a40" | adamw | style="color: #407a40" | okay...anything else? || 16:25 |- id="t16:26:19" ! style="background-color: #818144" | tflink | style="color: #818144" | I have some other questions about the preupgrade issue, but they can wait for the email thread || 16:26 |- id="t16:26:50" ! style="background-color: #407a40" | adamw | style="color: #407a40" | okie dokie || 16:26 |- id="t16:26:55" | colspan="2" | * adamw sets fuse for 2 minutes || 16:26 |- id="t16:28:29" ! style="background-color: #407a40" | adamw | style="color: #407a40" | thanks for coming, all! || 16:28 |- id="t16:28:55" ! style="background-color: #407a40" | adamw | style="color: #407a40" | #endmeeting || 16:28 |}

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

Retrieved from "https://fedoraproject.org/w/index.php?title=QA/Meetings/20120409&oldid=283738"