16:01:20 <tflink> #startmeeting f19final-blocker-review-9
16:01:20 <zodbot> Meeting started Wed Jun 26 16:01:20 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:21 <tflink> #meetingname f19final-blocker-review-9
16:01:21 <zodbot> The meeting name has been set to 'f19final-blocker-review-9'
16:01:21 <tflink> #topic Roll Call
16:01:35 * kparal preparing dinner
16:01:41 * jreznik is on the call but will be available soon
16:01:43 * Viking-Ice eats kparals dinner
16:03:08 * jreznik is hungry and is going to move to his place now, will probably disconnect for a few minutes
16:03:22 * tflink is alarmed that Viking-Ice seems to have mastered instantanious transcontinental travel
16:03:43 <kparal> Viking-Ice: it's a fish ;)
16:04:34 <adamw> ahoyhoy
16:04:52 <Viking-Ice> kparal, Icelandic one or something nuclear?
16:05:30 <tflink> I believe that we have enough people to get started, hopefully it'll be a short meeting today
16:05:38 <tflink> any volunteers for secretary duty?
16:05:44 <adamw> moi
16:06:07 <Viking-Ice> somebody tie adamw hands so he wont throw in new blockers this meeting...
16:06:10 <tflink> adamw: thanks
16:06:26 <adamw> mmmmf! mmmmmmmf!
16:06:50 <tflink> #topic Introduction
16:06:59 * nirik is lurking around
16:07:23 <adamw> it's usually kparal throwing blockers around merrily, anyhow
16:07:48 <tflink> adamw: so having hands tied makes you type like you might sound if you were gagged?
16:07:56 <tflink> Why are we here?
16:07:56 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and freeze exception bugs.
16:08:02 <tflink> #info We'll be following the process outlined at:
16:08:02 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:07 <tflink> #info The bugs up for review today are available at:
16:08:07 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:10 <adamw> tflink: that made more sense in my head.
16:08:13 <tflink> #info The criteria for release blocking bugs can be found at:
16:08:13 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria
16:08:16 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria
16:08:19 <tflink> #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria
16:08:24 <tflink> #info Up for review today, we have:
16:08:31 <tflink> #info 2 Proposed Blockers
16:08:31 <tflink> #info 3 Accepted Blockers
16:08:31 <tflink> #info 10 Proposed Freeze Exceptions
16:08:31 <tflink> #info 24 Accepted Freeze Exceptions
16:08:32 <Viking-Ice> adamw, he's to busy cooking so he got this hands full ;)
16:08:59 <kparal> Viking-Ice: I don't about the fish quality, but it seems better than the rotten shark of yours :)
16:09:00 <adamw> morning jrez
16:09:13 <kparal> no offence, of course
16:09:26 <kparal> *don't know
16:10:09 <tflink> if we're done insulting the quality of the fish sourced from our respective countries, any objections to starting with the proposed blockers?
16:10:10 <jreznik> back again
16:10:40 * tflink assumes not
16:10:43 <tflink> #topic (977764) missing gnu-free fonts cause warnings when anaconda is run
16:10:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=977764
16:10:47 <adamw> goddamnit, tflink, why do you never give enough time to the really important topics
16:10:47 <kparal> tflink: you need to taste it (or smell it) to understand. Viking-Ice might bring some specimen to Flock :)
16:10:49 <tflink> #info Proposed Blocker, LiveCD, VERIFIED
16:10:57 <adamw> as this is fixed in rc2, let's not waste much time bikeshedding it
16:11:18 <tflink> but the shed should be _blue_!!!
16:11:20 <kparal> so let's just say "fixed, move on"
16:11:25 <adamw> probably fine just to leave it as FE at this point. only waiting for spin-kickstarts build to be pushed to close it anyhow.
16:11:27 <tflink> works for me
16:11:27 <adamw> ayup
16:11:51 <tflink> #info this was accepted as a freeze exception and fixed in RC2 - no need to consider it as a blocker
16:11:58 <tflink> #chair adamw kparal
16:11:58 <zodbot> Current chairs: adamw kparal tflink
16:12:08 <tflink> #topic (976415) Missing usermode-gtk in dependencies
16:12:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=976415
16:12:09 <tflink> #info Proposed Blocker, liveusb-creator, MODIFIED
16:12:33 <tflink> so, liveusb-creator is on the kde lives?
16:12:35 <adamw> yeah
16:12:39 <Viking-Ice> I thought we had dealt with this one already
16:12:40 <adamw> we missed that when discussing the bug before :/
16:12:41 <Viking-Ice> still -1
16:12:42 <tflink> fun
16:12:46 <adamw> Viking-Ice: we missed that it's on the KDE live image
16:12:58 <adamw> the vote before was based on the assumption this wasn't on any of the release media, since we didn't see it in comps
16:13:23 <adamw> but KDE adds it to their live image via spin-kickstarts, presumably on the assumption that you're more likely to want to write a live image...from a live install? not quite sure why, but anyhow.
16:13:39 <Viking-Ice> then just either add it to the kde live ks or remove it anywho -1 blocker +1 FE
16:13:41 <tflink> of all the places to put it, a live image seems rather strange to me but OK
16:13:44 <adamw> to me it's a pretty clear blocker per the criterion, but some people seem to want to fudge it. i'd quite like to fix it
16:13:59 <kparal> adamw: have you tried whether it actually doesn't start on KDE Live? maybe the package is already there
16:14:06 <adamw> we can fix it by re-spinning only the kde live (and a couple of non-blocking spins which are based on it)
16:14:16 <adamw> kparal: yes I have, that was what I was doing when I found it was on the KDE live =)
16:14:17 <tflink> yeah, I'm just not crazy about the idea of RC2.1 for just kde
16:14:24 <jreznik> adamw: you're right, bouncing icon is not nice but if you document it in common bugs... but if we could just get another RC (even only for KDE) and remove it, I'd be ok with that
16:14:25 <adamw> it just doesn't launch. you get a bouncing icon, then nada.
16:14:51 <adamw> to me it's worth just rebuilding a single spin with a single clearly isolated change to fix an app on the menus not running.
16:15:10 <adamw> though obviously it would've been better to catch this earlier.
16:15:15 <tflink> yeah, I'd rather not release broken lives, even if it minor
16:15:19 * kparal is for rebuilding KDE Live
16:15:20 <jreznik> adamw: ok and I'd prefer to remove it
16:15:20 <adamw> if we say -1 blocker to this, what is the rationale? and how do we justify the criterion in that case?
16:15:31 <adamw> 'all apps on the menus must launch unless we decide it's too late and we can't be bothered'?
16:15:46 * nirik is +1 based on critera... if we cna just do kde/kdebased that would be lovely.
16:15:50 <Viking-Ice> adamw, the rational that the board does not call KDE the default
16:16:01 <tflink> Viking-Ice: but it's still a release blocking DE
16:16:05 <adamw> it is a release-blocking spin, though. that is pretty solidly established.
16:16:35 <jreznik> well again you can ask "how many people will use this one single app if it's one day before go/no-go" as we do for many other bugs... so basically same smoke test
16:16:39 <tflink> who is -1 other than Viking-Ice ?
16:16:45 <jreznik> Viking-Ice: Board says there's no default at all
16:16:57 <Viking-Ice> jreznik, that's news to me
16:17:01 <adamw> jreznik: true, but then we basically have a criterion that's lying
16:17:12 * satellit_e does liveusb-creator work if installed via KDE to HD?
16:17:31 <adamw> jreznik: and it seems difficult to 'correct' it without losing it; how do we define what apps have to work and what apps don't? would we ship if, oh, say, Evolution or LO failed to run?
16:17:41 <loadiid> if it works from the command line, then it works, so it's an app on teh menus, and it launches (just not from the menus)
16:17:44 <kparal> satellit_e: not until you update it
16:17:45 <adamw> satellit: i was testing post-install
16:17:55 <adamw> loadiid: the criterion explicitly states that it must launch from the menus.
16:17:58 <Viking-Ice> jreznik, who other then that board labels stuff with "Default", "Recommended", "Official" etc.
16:18:35 * jreznik hopes vhumpa will reveal his dogtail automated tests for this test criterion one day
16:18:43 <adamw> loadiid: the intent is a) to make sure all the apps we ship basically work but also b) a polish thing: it looks pretty bad if we're shipping images where we apparently 'haven't even tested that the apps run'
16:18:56 <Viking-Ice> true
16:19:12 <jreznik> adamw: do you prefer pushing fixed version or remove it from spin?
16:19:13 <loadiid> ok, i read "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use."
16:19:22 <Viking-Ice> that's why we QA in general should leave those DE testing up to their respectful communities
16:19:28 * satellit_e it almost always requires "livusb-creator --reset-mbr" to work with USB's for me (command line)
16:19:30 <loadiid> so, listed - yes, basic functionality - yes
16:19:42 <adamw> jreznik: well, the fix is very clear and testable, and it seems a bit rude to just take it out. but either would probably be better than having it there but not running.
16:19:59 <tflink> before we continue the argument on how we could -1 this, are there enough people to carry the -1 vote
16:20:00 <kparal> satellit_e has quite a good remark, liveusb-creator doesn't usually work without extra cli commands :)
16:20:05 <tflink> I'm seeing more +1 than -1
16:20:17 <kparal> I'm still +1 though
16:20:19 <tflink> it sounds like jreznik and Viking-Ice are -1
16:20:20 <adamw> loadiid: oh, sorry, I should have cited "All applications listed under the Applications menu or category must start successfully "
16:20:36 <tflink> adamw, nirik, kparal and I are +1
16:20:47 <tflink> +4/-2
16:21:14 <tflink> other votes?
16:21:16 <kparal> tflink: don't forget your own vote
16:21:19 * satellit_e just remove from menu?
16:21:40 <Viking-Ice> there is a majority for agreement here so...
16:21:42 <kparal> jreznik: so you don't want to rebuild or you want to rebuild with the app removed from the spin?
16:21:47 * adamw builds a test live
16:22:12 <tflink> kparal: I didn't
16:22:26 <kparal> tflink: oh, my mistake
16:23:40 <jreznik> well, I'm not saying I'm strict -1 and I have to admit I like the criterion from pov of polishing, it's pretty strict compared to some bugs we said "not widespread enough" (my only problem with it)
16:23:44 * tflink doesn't much care whether the dep is added or the app removed
16:24:03 <Viking-Ice> I'm not strict -1 either
16:24:32 <adamw> jreznik: it's based on real world experience to an extent; it's not hard to find reviews which basically say 'jeez, i tried to launch some app from the menus and it didn't even work, do they even TEST this thing?!'
16:24:33 <jreznik> let's do it, don't waste time, fixed dep is probably better solution now
16:24:42 <tflink> jreznik: I think most of those "not widespread enough" are either hw specific or very specific workflows - anyone booting the kde live could hit this
16:25:20 <jreznik> tflink, adamw: everyone is going to try "word processor", not sure some tool nobody wants to use on Live
16:25:30 <adamw> jreznik: it's there after install too, of course.
16:25:37 <adamw> that's how i was testing.
16:25:54 <jreznik> adamw: it was an answer for "magazine review"
16:25:57 <tflink> proposed #agreed 976415 - AcceptedBlocker - Violates the following F19 final release criteria for the KDE live spin: "All applications listed under the Applications menu or category must start successfully"
16:25:58 <adamw> i agree it's quite a high bar to set, and we really need to do a better job of testing it early
16:26:03 <adamw> ack
16:26:04 <Viking-Ice> ack
16:26:05 <jreznik> ack
16:26:10 <nirik> ack
16:26:13 <tflink> jreznik: note that I said that they "could" not that everyone would
16:26:13 <adamw> it's just such a horrible test i always procrastinate it...
16:26:13 <kparal> ack
16:26:20 <tflink> #agreed 976415 - AcceptedBlocker - Violates the following F19 final release criteria for the KDE live spin: "All applications listed under the Applications menu or category must start successfully"
16:26:36 <jreznik> adamw: yeah, that's my only issue, I'll talk to vhumpa about his dogtail script for this criterion
16:26:37 <tflink> ok, that's all of the proposed blockers on my list
16:27:19 * satellit_e I still think it could be deleted from the menus and category but left on live to satisfy the criteria
16:27:29 <tflink> I'd be worried about dogtail causing as many false negatives as it was useful but maybe the approach works better than I think it does
16:28:10 <adamw> satellit: it's really easier to fix the dep than to remove the .desktop file...
16:28:17 <satellit_e> ok
16:28:36 <adamw> i already did a build that fixes this, i'm just building a live image to test the fix right now
16:29:00 * adamw is judge, jury and executioner
16:29:10 <Viking-Ice> let's move on
16:29:17 <adamw> not a lot to move on *to* really
16:29:22 * tflink runs away from judge dredd/adamw
16:29:35 * nirik moves on to the beach and a fruity drink.
16:29:44 <adamw> hearty +1
16:29:50 * Viking-Ice lights a torch
16:29:57 <tflink> yeah, I'm not seeing any proposed FEs that are worth discussing today
16:30:03 <adamw> voting on the FEs in case we find a blocker today and need to slip seems defeatist =)
16:30:14 <tflink> yep
16:30:17 <Viking-Ice> yup
16:30:27 <tflink> all accepted blockers are VERIFIED
16:30:29 <adamw> RC2(.1) is really looking pretty good, all we have to fill out are the RAID tests and i don't expect those to fail
16:30:35 <adamw> all other tests appear to be covered
16:30:41 * tflink will get started on that after the meeting
16:30:44 <adamw> me too
16:30:51 <adamw> nobody mention the live RAID1 bug kay
16:31:15 * tflink looks for the command to silence adamw in the channel
16:31:20 <adamw> we can go through and replace the RC1 runs with RC2, but RC2 was a pretty tiny change, no reason they'd fail
16:31:35 <jreznik> tflink: for dogtail - it's not cure but it could help and when I was doing this test case for KDE I was always - no, not again :) it's pretty boring one
16:31:37 <tflink> what about the upgrade stuff
16:31:44 <adamw> jreznik: yeah, it's pretty hideous
16:31:55 <adamw> i have to admit i phone it in for some of the apps
16:32:00 <adamw> i mean, they ship a goddamn usenet reader.
16:32:05 <tflink> jreznik: sure, I'm just skeptical of the approach dogtail takes to testing
16:32:16 <adamw> oh, yeah, we need to sort out that upgrade thing
16:32:22 <adamw> set a topic for the trac ticket?
16:33:09 <tflink> #info no proposed FEs need to be discussed at this time with go/no-go tomorrow
16:33:19 <tflink> #info all accepted blockers are VERIFIED
16:34:06 <tflink> #topic Fedup Builds for F19
16:34:13 <tflink> #link https://fedorahosted.org/rel-eng/ticket/5648
16:34:35 <tflink> it sounds like we've not been getting fedup initrds for i386 for a while now
16:34:47 <kparal> dgilmore says this is not a blocker for releng
16:34:55 <kparal> dgilmore: around?
16:35:08 <adamw> yeah, it'd be good to have some clarification here
16:35:19 <tflink> how are missing upgrade files not a blocker?
16:35:29 <Viking-Ice> aren't everybody fedup with i386 anyway ( drum solo please )
16:35:34 <kparal> dgilmore says the content from development/ goes to releases/F19/Everything
16:35:39 <adamw> badum-*tish*
16:35:40 <kparal> some images/ are pruned anyway
16:35:54 <kparal> and releases/F19/arch/os/images are populated from pungi
16:35:57 <tflink> sure, but if mash is failing, how could we have the initrd?
16:36:00 <adamw> so can we actually test fedup 32-bit for f19 atm in a way that matches what people will be using post-release?
16:36:01 <kparal> a completely different process, which works
16:36:05 <nirik> this looks like some lorax issue. I looked a bit, but couldn't fully find the problem
16:36:13 <adamw> that's the bottom line
16:36:24 <adamw> 'can we test fedup and make sure upgrades will be okay on release day'
16:36:25 <tflink> adamw: outside of mirrormanager, yeah. we can build a siderepo
16:36:33 <nirik> if we could perhaps ping lorax people they might know more off hand?
16:36:46 <nirik> note that the rc2 versions did work... so something is weird.
16:37:04 <kparal> adamw: no, we can't. the rest or pungi files are not accessible, and fedup rejects to work properly without Packages/ present
16:37:17 <tflink> why is lorax installing rsh?
16:37:24 * nirik has no idea.
16:37:39 <nirik> it looks like a template is too small for 32bit somewhere...
16:38:27 <tflink> it'd be nice if the tb gave more information about the yum transaction error :-/
16:39:22 * kparal asked dgilmore to come here, he's active on #fedora-devel now
16:40:14 <kparal> so, ideally, we would either need to fix mash, or make the rest of pungi job for RC2 accessible, right?
16:40:25 <nirik> it's not mash
16:40:28 <nirik> it's lorax.
16:40:34 <tflink> yeah, that tb is lorax
16:40:44 <tflink> which would affect pungi
16:40:52 <kparal> ok, but mash is creating and updating development/ tree, isn't it
16:40:54 <nirik> tflink: http://kojipkgs.fedoraproject.org/mash/branched-20130626/logs/i386.log
16:41:00 <dgilmore> tflink: but it doesnt
16:41:12 <kparal> so we would need to fix it and we would have a proper tree tomorrow
16:41:15 <nirik> mash calls lots of things to do it's work... that doesn't mean all bugs are it's fault. ;)
16:41:36 <tflink> dgilmore: then I'm missing something
16:41:43 * tflink reads logs
16:41:51 <nirik> kparal: yeah, it needs fixing.
16:42:06 <dgilmore> its not a release bloker issue
16:42:09 <kparal> we still have some time, so if we can fix it today, we can test fedup tomorrow
16:42:22 <kparal> dgilmore: we would love to verify fedup working before release
16:42:36 <dgilmore> because whats failing to build in nightly is removed from the release tree
16:42:39 <nirik> fedup shouldn't actually use that...
16:42:48 <kparal> of if dgilmore can sync the whole RC2 tree somewhere, we can verify fedup immediately
16:42:50 <dgilmore> tflink: pungi and lorax worked fine for rc2 composing
16:43:13 <dgilmore> the issue is something to do with the environemnet that the nightly composes run in
16:43:23 <tflink> if they work fine for composing, then I'm much less worried but still want something to test i386 upgrades with before go/no-go
16:43:32 <tflink> it looks like something ran out of disk space
16:43:40 <adamw> dgilmore: the bottom line for me is that we need to be able to verify some time between now and tuesday that fedup is going to be okay on the day of release
16:43:41 <dgilmore> tflink: right
16:43:56 <adamw> ideally we want to check that before go/no-go tomorrow
16:44:59 <kparal> if the compose process is different between development/ and RC2/, then it actually makes more sense to verify full RC2 tree, not development/ one. and we've been doing it wrong all the time
16:45:01 <tflink> adamw: just ideally? how can we justify being go without testing i386 upgrades?
16:45:28 <tflink> kparal: the upgrade bits are removed from the TC/RC trees on the mirror IIRC
16:45:59 <kparal> tflink: RC2 doesn't contain just Packages/, it contains everything else, I believe
16:46:46 <kparal> e.g. http://dl.fedoraproject.org/pub/alt/stage/19-RC2/Fedora/x86_64/os/images/pxeboot/upgrade.img
16:47:10 <tflink> yep, I'm misremembering
16:47:18 <kparal> we could also fix fedup to accept directories without Packages/, but that's not going to happen immediately
16:47:37 <kparal> and I think we were already declined on this
16:47:51 <tflink> that seems questionably unwise this late
16:48:04 <tflink> even if will was willing to make that change
16:48:14 <kparal> dgilmore: so, would it be possibly to make the full RC2 tree public?
16:48:26 <kparal> *possible
16:48:51 <kparal> including Packages/
16:49:09 <dgilmore> kparal: it is. but i dont think that will give you what you need
16:49:24 <kparal> we can test fedup and everyone is happy, no? :)
16:49:27 <dgilmore> kparal: because Packages is a subset of whats in development/19
16:49:39 <dgilmore> kparal: it should work with whats there now
16:49:51 <tflink> does MM point to the release tree or Everything?
16:49:54 <kparal> I believe that doesn't matter. fedup works with that as an extra repository, it also uses 'fedora' and 'updates'
16:50:05 <dgilmore> tflink: both
16:50:21 <tflink> I think fedup works with just the release tree
16:50:41 <dgilmore> there is a fedora-install-19 and fedora-19 mirrorlists it uses
16:50:42 <tflink> wait, that can't be right
16:50:48 <kparal> tflink: release tree
16:51:02 <tflink> then how does it upgrade pkgs that aren't in the release tree?
16:51:09 <kparal> fedup uses 'fedora', 'updates' and 'instrepo' -> release tree
16:51:15 <kparal> I blieve
16:51:26 <dgilmore> my underst6anding is that it uses fedora-install-19 to get the .treeinfo file and related bits, and fedora-19 for packages
16:51:31 <tflink> yeah, that's what I thought as well but using Everything would make more sense
16:51:39 <nirik> it uses Fedora
16:51:48 <dgilmore> nirik: it has to use more
16:51:50 <kparal> dgilmore: right, and therefore full RC2 compose should be sufficient
16:51:52 <nirik> https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-install-18&arch=x86_64
16:52:03 <nirik> dgilmore: for the image?
16:52:08 <nirik> images
16:52:12 * dgilmore goes to look at the source
16:52:15 <tflink> nirik: that's just for the upgrade image, I think though
16:52:17 <nirik> right.
16:52:21 <dgilmore> nirik: right
16:52:25 <nirik> but thats what we are talking about no?
16:52:35 <dgilmore> nirik: thats available now
16:52:35 <nirik> the upgrade.img is looked for in Fedora/ not Everything
16:52:36 <kparal> just the upgrade image, but also uses the repo that's available
16:52:36 <tflink> we were talking about the package sources
16:52:55 <adamw> rc2.1 request filed, btw.
16:52:56 <tflink> the stuff that fedup pulls into it's "local" repo before rebooting
16:53:04 <dgilmore> nirik: it looks for kernel and upgrade initramfs in Fedora
16:53:21 * kparal asked wwoods to come
16:53:21 * nirik is now comfused. I thought it was the upgrade.img that failed in everything?
16:53:28 <nirik> which we don't use.
16:54:24 <tflink> nirik: i think it's a combination of 2 issues
16:54:30 <dgilmore> nirik: upgrade.img gets pulled from Fedora
16:54:38 <tflink> it sounds like the upgrade.img in the development tree is failing
16:54:45 <tflink> failing/does not exist
16:54:49 <nirik> right, so we have it, we shouldn't need to care for release about development
16:55:06 <tflink> we have upgrade.img in the RC2 tree but it also needs Packages/ which isn't mirrored until after release
16:55:22 <nirik> ah, I see. ok.
16:55:36 <tflink> the question at the moment is whether making the RC2 packages public would be enough to test fedup or if it needs Everything
16:55:39 <adamw> so can we test by passing in a repo parameter?
16:55:48 <kparal> tflink: I believe it is completely enough
16:55:50 <nirik> if we had the repo public yeah
16:55:51 <dgilmore> tflink: it should need both
16:56:04 <tflink> adamw: sure, if that's an acceptable test
16:56:22 <dgilmore> though as i understand it the packages repo for Fedora is never used
16:56:52 <adamw> tflink: don't really see why not.
16:56:52 <tflink> kparal: so how are pkgs that _aren't_ in the release tree upgraded?
16:57:05 <dgilmore> i suspect that when you specify locations on the command line it acts differently
16:57:15 <tflink> kind of
16:57:17 <kparal> tflink: it just uses system 'fedora' and 'updates' repos
16:57:26 * adamw is amused that we apparently have no idea exactly how this works
16:57:27 <kparal> tflink: with bumped $version
16:57:32 <tflink> kparal: so pkgs that don't have updates yet don't get upgraded?
16:57:43 <adamw> system 'fedora' repo would be 'everything', no?
16:57:45 <tflink> it doesn't act all that differently
16:57:48 <kparal> adamw: yes
16:58:05 <kparal> adamw: that's what I'm trying to convey :)
16:58:09 * nirik blinks at adamw's statement.
16:58:21 <tflink> I thought that fedora was the dvd
16:58:28 <dgilmore> kparal: ok what you need to do is specify the development/19 tree as the repo and RC2 tree as the intrepo
16:58:31 <tflink> and was a subset of all the packages available in fedora
16:58:37 <kparal> tflink: I'm talking about network upgrade here, I haven't tried media upgrade yet
16:58:44 <dgilmore> tflink: it is
16:58:45 <tflink> kparal: I know
16:58:47 <nirik> tflink: yes
16:58:57 <adamw> tflink: er, no? look at your /etc/yum.repos.d/fedora.repo
16:59:05 <Viking-Ice> adamw, yet it is the "official" upgrade tool now that something to be amused over ;)
16:59:22 <adamw> Viking-Ice: well, it does seem to work quite well, we just don't appear to be entirely clear on how ;)
16:59:32 <tflink> I don't understand the confusion here - the fedup client just downloads stuff and adds a boot option to the grub menu
16:59:32 <kparal> dgilmore: I need to do "fedup --network 19 --instrepo http://location/RC2", where RC2 contains images/ and Packages/. fedup will itself add "fedup" and "updates" system repos
16:59:41 <kparal> to the mix
16:59:53 <kparal> "fedup" -> "fedora"
17:00:09 <tflink> it amuses me more that the releng folks are saying one thing while the QA folks are saying something different ... about what is contained in the different trees
17:00:23 <nirik> I think we all agree, it's just naming issues.
17:00:27 <tflink> yeah
17:00:34 <dgilmore> fedup ---enablerepo http://dl.fedoraproject.org/pub/fedora/linux/development/19/i386/os/ --instrepo http://dl.fedoraproject.org/pub/alt/stage/19-RC2/Fedora/i386/os/
17:00:34 <dgilmore> something like that
17:00:35 <nirik> On an installed system the 'fedora' repo is 'Everything' tree.
17:00:48 <adamw> yes.
17:00:51 <dgilmore> tflink: i know exactly whats in the different trees
17:00:55 <kparal> dgilmore: no --enablerepo should be needed
17:00:59 * nirik is pretty sure he does too. ;)
17:01:11 <dgilmore> kparal: to mimic what fedup actually does yes it is
17:01:13 <adamw> if fedup uses the system repos with releasever appropriately modified as a package source on upgrades, then you will have an Everything repo available on upgrades.
17:01:16 <tflink> nirik: which is different than the fedora repo WRT RC2 (which is Packages/ that comes out of pungi)
17:01:21 <dgilmore> kparal: /me just went and read the code
17:01:37 <nirik> tflink: the Fedora tree on mirrors is the dvd content.
17:02:05 <dgilmore> adamw: right and if you dont specify a --instrepo it deafults to using fedora-install-<release>
17:02:08 <nirik> adamw: for default command line options, yes.
17:02:19 <tflink> nirik: yeah, I think that's what I said. _think_ being the key word there
17:02:20 <dgilmore> if self.instrepoid is None:
17:02:20 <dgilmore> self.instrepoid = 'default-installrepo'
17:02:20 <dgilmore> mirrorurl = mirrorlist('fedora-install-$releasever')
17:02:20 <dgilmore> repos.append(('add', '%s=@%s' % (self.instrepoid, mirrorurl)))
17:02:25 <nirik> and mirrormanager isn't going to update to the fedora-install$ver until release day...
17:02:42 <tflink> so it's not all that different from the testing we'd have to do anyways
17:02:48 <tflink> the usual MM uncertainty
17:03:10 * nirik wonders if we could have mm in stg update pre-release to help.
17:03:13 <adamw> as long as we can test with the upgrade.img that will get shipped, and the frozen package set, i don't see a problem
17:03:24 <tflink> the only thing we wouldn't be testing 100% is the fedup client's ability to self-determine repo locations
17:03:27 <adamw> any issues that crop up in the mirror manager / mirror list stuff can be dealt with
17:03:33 <tflink> which I don't think has changed much since F18
17:03:55 <dgilmore> tflink: mm had a major upgarde :)
17:03:59 <adamw> the only things we need to verify for release are that the upgrade.img we're going to ship are good and (if we really care) that the frozen package set is okay for upgrades, as those are the only things we can't fix
17:04:09 <tflink> dgilmore: it still returns the same info, though. right?
17:04:17 <nirik> yes, info from it is fine
17:04:20 <dgilmore> tflink: should do yeah
17:04:20 * tflink wasn't really paying attention to the MM upgrade
17:04:28 <adamw> so if we can test those two things right now, we are finwe
17:04:43 * nirik thinks we can via dgilmore's command line above.
17:04:44 <tflink> OK, so to summarize
17:04:50 * tflink agrees
17:05:23 <tflink> #info fedup can be tested using the development/19 tree as a package source and the RC2 tree as instrepo
17:05:30 <adamw> now would be a good time for anyone who wants to do 'em to try those tests ;)
17:05:51 <tflink> #info there will be the usual uncertainty with regard to mirrormanager integration, but that's always been the case
17:06:01 * nirik thinks we should still ping lorax folks for the issue in branched, it would be nice to know whats causing it.
17:06:10 <tflink> #info if any mirrormanager integration issues surface, they will be dealth with
17:06:12 <dgilmore> if its borked
17:06:12 <dgilmore> then we should populate Packages
17:06:12 <dgilmore> because we should test the release tree not the nightly generated one thats thrown away
17:06:14 <tflink> #undo
17:06:14 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x124fcc90>
17:06:17 <tflink> #info if any mirrormanager integration issues surface, they will be dealt with
17:06:29 <dgilmore> nirik: i suspect its a issue in the compose environment
17:06:36 <dgilmore> nirik: ill try dig into it today
17:06:38 <nirik> me too. but just want to know for sure.
17:06:45 <tflink> adamw: I would argue that it's almost too late to be doing useful upgrade tests, but the argument would be rather pointless today :)
17:07:01 <tflink> anyhow, are there any other upgrade issues to cover right now?
17:07:12 * tflink suggests that we end the meeting and get back to testing
17:07:16 * nirik nods.
17:07:29 <adamw> tflink: sure, if we haven't actually been testing the right stuff so far we need to nail that down for next time
17:07:35 <adamw> (and hope like hell it works)
17:07:36 <Viking-Ice> well dont we need to hold up the release until all upgrade test pass
17:07:46 <Viking-Ice> since we you know offifically support it
17:07:55 <adamw> Viking-Ice: we should verify the two things mentioned above before go/no-go, yes
17:08:05 <tflink> adamw: it's more that upgrade method fixes now are extremely impractical
17:08:18 * tflink hasn't been doing as much upgrade testing as he should
17:08:18 <adamw> the tests were marked 'pass' for rc1 but it sounds like maybe those were actually testing the beta upgrade.img or something
17:08:20 <tflink> have been
17:08:35 <nirik> yes, thats what you get by default.
17:08:40 <tflink> adamw: probably - that's what MM was pointing at
17:08:49 <tflink> #topic Open Floor
17:08:56 <nirik> http://dl.fedoraproject.org/pub/fedora/linux/releases/test/19-Beta/Fedora/x86_64/os/ <- what fedora-install-19 gives you now.
17:09:02 <tflink> Is there anything else which needs to be covered here today?
17:09:19 <adamw> we should definitely get more on top of the fedup infrastructure for next time
17:09:29 <adamw> it'd be nice if we could somehow make it DTRT for testing more often
17:09:29 <tflink> among other things :)
17:09:39 <adamw> just a note that we need karma for the stuff i wrote to the ML about
17:09:41 <Viking-Ice> or simply stop officially supporting upgrades....
17:09:45 <jreznik> just the usual reminder - the Go/No-Go and Readiness meetings are tomorrow
17:10:10 <tflink> #info Go/No-GO and Readiness meetings are tomorrow (2013-06-27)
17:10:24 <tflink> adamw: do we have F19 retrospective pages started yet?
17:10:31 <adamw> tflink: no :( i missed out on doing that, sorry :(
17:10:35 <adamw> i should create them
17:10:58 <nirik> we might be able to use our stg setup to test mm pre-release...
17:11:01 <nirik> next cycle.
17:11:03 <adamw> definitely fedup is something to put in there
17:11:22 <tflink> adamw: I was also thinking about the updates.img snafu from yesterday
17:11:31 <adamw> tflink: i'll try and get to it today but if you feel like creating the page and adding your notes to it, by all means do
17:11:38 <adamw> it's a simple copy/paste, s/18/19/ job
17:11:57 <tflink> #action adamw or tflink to create F19 retrospective pages
17:12:09 <tflink> whoever gets to it first
17:12:15 <adamw> yeah
17:12:19 <adamw> gonna run some upgrade and RAID tests first
17:12:21 * tflink plans to get some tests started right after this, though
17:12:22 <tflink> yep
17:12:33 <tflink> if there's nothing else, I'm setting a short fuse
17:13:39 <tflink> and proposes a rename from "Fedora QA" to "The Fedora Enrichment Center" in the hopes that testing euphoria, cake and fire  will provide more motivation for testing
17:14:24 <Viking-Ice> right right
17:14:44 <adamw> just call it Project Colada
17:14:50 <Viking-Ice> we should be able to sit down and discuss that amongst other things on flock
17:15:07 <adamw> Viking-Ice: yup for sure
17:15:20 <adamw> Viking-Ice: for f20 cycle i'm planning on trying to do a fairly major overhaul of the validation test cases
17:15:33 <adamw> update them for newUI, noloader and other changes, add more partitioning tests and stufdf
17:15:51 <Viking-Ice> Ok
17:16:58 <tflink> Thanks for coming, everyone!
17:17:06 * tflink will send out minutes shortly
17:17:06 <adamw> ayup
17:17:11 <tflink> #endmeeting