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