| 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
|
