From Fedora Project Wiki

Fedora Release Engineering Meeting :: Monday 14-MAY-07


  • Notting put a lot of work into getting rawhide to build again--see IRC log for how it works
  • Discussion of mash and future rawhide building plans

Current Issues and Freeze Status

  • we agreed last week to revisit this week.
  • are we ready to freeze on Thursday?
  • discussion of packages causing problems

1. beagle

  • re-evaluate beagle and tracker for F8
  • bug #217031
  • maintainer made changes to comps
  • DECISION (UNANIMOUS): Accept maintainer's comps change, making beagle optional. Include it in manifest so that it is on media for upgrades.

1. wireless-tools

  • newest wireless-tools has a patch that's supposed to fix 64-bit that actually breaks all wireless scanning on 64-bit systems.
  • warren will drive issue to conclusion
  • we not only need x86_64 testers, but also ppc and i386 to be sure the 64bit fix didn't break 32bit.
  • DECISION (UNANIMOUS): If that -3 build turns out to be No Good then we just revert the 64-bit patches entirely and call that -3 (or -4 or whatever)

1. hal

  • wwoods--hal-0.5.9-6.fc7 fixed the suspend/resume quirks for some stuff (T60 maybe?), but broke it for others (my pitiable t43)
  • without passing the quirks there's no way suspend to work on large classes of laptops
  • ACTION: jeremy will try to get hughsie to take a look--davidz won't be back until the 20th.

1. mdraid

  • wwoods--the old raidautorun stuff + IDE = doooom
  • wwoods will enage Peter Jones
  • realy need IDE drives to do good testing
  • lots of bugs; BZ: 151653, 231426, 238353, 221696, 213586, 238926
  • wwoods--never tested dmraid because no hardware; f13 is going to test now
  • DECISION: None reached
  • we should direct new packages to updates, not the final tree.
  • f13 will announce and update the freeze/release dates
  • everything must be done and ready for GA on 29-MAY-07

Outstanding GA Blocker Bugs

  • 81 bugs still on the fc7blocker
  • provides guidance on release blockers
  • Blocker only fixes starting Thursday (branch CVS same day)
  • Broken EVR paths and broken deps (including from the Merge) in the entire distro must be fixed before GA
  • wwoods to add this to release criteria


IRC Transcript

Idea.png f13 changed the topic of #fedora-meeting to: Fedora Release Meeting: Rawhide<a href="#t12:58" class="time">12:58</a>
f13meeting in just a couple minutes<a href="#t12:58" class="time">12:58</a>
f13poelcat: hi, are you here?<a href="#t12:58" class="time">12:58</a>
poelcatf13: present and accounted for<a href="#t12:59" class="time">12:59</a>
* mmcgrath here for a while<a href="#t13:00" class="time">13:00</a>
f13alright, lets get a rollcall.<a href="#t13:00" class="time">13:00</a>
f13jwb: notting, jeremy, rdieter, warren, wwoods: ping?<a href="#t13:00" class="time">13:00</a>
f13mmcgrath: thanks for stopping by<a href="#t13:00" class="time">13:00</a>
* jeremy is here (though the plumber is here too, so may be in and out)<a href="#t13:01" class="time">13:01</a>
warrenI'm here it seems.<a href="#t13:01" class="time">13:01</a>
warrenjeremy, plumber will be joining us? =)<a href="#t13:01" class="time">13:01</a>
f13Ok, well the rest will come in or notice this channel in a few moments.<a href="#t13:02" class="time">13:02</a>
f13first topic is Rawhide.  Bill put in a lot of great work and managed to make a rawhide show up.<a href="#t13:02" class="time">13:02</a>
f13notting: can you let us know what you had to do, and how we can keep it going?<a href="#t13:03" class="time">13:03</a>
jeremyyes, that would be good :)<a href="#t13:04" class="time">13:04</a>
* f13 wonders if notting got distracted by a shiney<a href="#t13:05" class="time">13:05</a>
mmcgrath:)<a href="#t13:05" class="time">13:05</a>
poelcatdonkey?<a href="#t13:05" class="time">13:05</a>
* f13 tries the sms approach<a href="#t13:08" class="time">13:08</a>
f13hrm.<a href="#t13:09" class="time">13:09</a>
warrenf13, tried his desk phone?<a href="#t13:09" class="time">13:09</a>
f13warren: he's working from home.  Helping wife take care of new baby.<a href="#t13:09" class="time">13:09</a>
f13well, until he gets here.<a href="#t13:10" class="time">13:10</a>
f13mmcgrath: what's our storage story like today?<a href="#t13:10" class="time">13:10</a>
wwoodsyarg, finally got X back up<a href="#t13:10" class="time">13:10</a>
* wwoods here<a href="#t13:11" class="time">13:11</a>
mmcgrathhmm<a href="#t13:11" class="time">13:11</a>
* mmcgrath looks it up<a href="#t13:11" class="time">13:11</a>
mmcgrathf13: I'm trying to get a quote for you on adding storage to the netap btw.<a href="#t13:11" class="time">13:11</a>
mmcgrathf13: its filling up but we're ok.<a href="#t13:12" class="time">13:12</a>
f13ok.<a href="#t13:12" class="time">13:12</a>
f13mmcgrath: any new information on eta on mounting the netapp?  Having to use that other NFS storage is putting a _huge_ cramp in our style.<a href="#t13:12" class="time">13:12</a>
f13compose processes which should take 20~ minutes are taking 4+ hours<a href="#t13:13" class="time">13:13</a>
mmcgrath<nod> I'm going to push hard to get it mounted in the next day or two even if it is a T less then what we were asking for.<a href="#t13:13" class="time">13:13</a>
* mmcgrath heard it was taking 30 minutes?<a href="#t13:13" class="time">13:13</a>
f1330 minutes for one createrepo.<a href="#t13:13" class="time">13:13</a>
f13on hte fast side.<a href="#t13:14" class="time">13:14</a>
f13and there goes notting :(<a href="#t13:14" class="time">13:14</a>
f13notting: welcome back?<a href="#t13:14" class="time">13:14</a>
notting*sigh*<a href="#t13:14" class="time">13:14</a>
* notting kicks his upstream network. and flings poo at networkmanager<a href="#t13:15" class="time">13:15</a>
f13<f13> first topic is Rawhide.  Bill put in a lot of great work and managed to make a rawhide show up.<a href="#t13:15" class="time">13:15</a>
f13<f13> notting: can you let us know what you had to do, and how we can keep it going?<a href="#t13:15" class="time">13:15</a>
* wwoods leads general cheers: yeah! yay notting! he is our hero! etc.<a href="#t13:15" class="time">13:15</a>
nottingok, so<a href="#t13:16" class="time">13:16</a>
nottingit involved:<a href="#t13:16" class="time">13:16</a>
notting1) running mash by hand (this can be scripted)<a href="#t13:16" class="time">13:16</a>
notting2) running pungi on that tree by hand (this is awfully hard to script with mock, and other machines involved.)<a href="#t13:16" class="time">13:16</a>
notting- for this i used the x86_64 and i386 chroots on publictest4, and made a quick chroot on ppc1<a href="#t13:16" class="time">13:16</a>
notting3) set up a rsync server on xen6 (installed xinetd, wrote config (sorry mmcgrath, forgot about puppet)<a href="#t13:17" class="time">13:17</a>
wwoodswe really need to teach koji to do this stuff so we can run the mash / pungi stuff as normal koji tasks on the builders<a href="#t13:17" class="time">13:17</a>
f13sortof.<a href="#t13:17" class="time">13:17</a>
f13there is more to it than just teaching koji how to do a runroot task.<a href="#t13:17" class="time">13:17</a>
notting4) ran rsync to push it to wallace (internal mirror master). this took a loooong time due to the amount of data)<a href="#t13:17" class="time">13:17</a>
nottingthe rsync can be scripted. i made sure to a) exclude deletions of debuginfo (since the tree had a very incomplete set at the time, should be fixed now), and I also didn't delete the ia64/s390/s390x trees, in case someone still wants them for a while<a href="#t13:18" class="time">13:18</a>
nottingmdomsch: random point - you suggest --delay-updates, the rsync on our mirror master head doesn't support that :/<a href="#t13:18" class="time">13:18</a>
nottingi am not sure how we script pungi right now, as it involves setting  up mock chroots on other machines :/<a href="#t13:19" class="time">13:19</a>
jeremynotting: ssh keys!<a href="#t13:20" class="time">13:20</a>
jeremyfollowed by 'ssh host somecommandshere'<a href="#t13:20" class="time">13:20</a>
nottingjeremy: still... randomly saying 'hey, i'll abuse that builder' is kinda rude<a href="#t13:21" class="time">13:21</a>
nottingalso, to run pungi we'd need to toss a modified config at it<a href="#t13:21" class="time">13:21</a>
nottingwhich is sort of messy through a chroot<a href="#t13:21" class="time">13:21</a>
f13notting: yeah, we need koji runroot capability<a href="#t13:21" class="time">13:21</a>
nottingf13: random pungi question - why is the createrepo in the -B stage instead of the -G phase?<a href="#t13:21" class="time">13:21</a>
f13notting: configs can be stored in $SCM and pulled.<a href="#t13:21" class="time">13:21</a>
f13notting: mostly because said createrepo used to live in buildinstall itself.<a href="#t13:22" class="time">13:22</a>
f13this stage stuff was a patch I probably shouldn't have taken in.<a href="#t13:22" class="time">13:22</a>
f13obviously it's not really ready to be broken up in stages like that.<a href="#t13:22" class="time">13:22</a>
nottingplease don't take it out! sort of need it for rawhide<a href="#t13:22" class="time">13:22</a>
f13I know.<a href="#t13:23" class="time">13:23</a>
f13although<a href="#t13:23" class="time">13:23</a>
f13in the future, we should be able to send off bits of mash to builders, to do the full gather/buildinstall part.<a href="#t13:23" class="time">13:23</a>
nottingthe rpm gathering doesn't need to be sent off - that would make it slower<a href="#t13:24" class="time">13:24</a>
f13notting: so we could fairly easily automate rawhide, if it wasn't installable<a href="#t13:24" class="time">13:24</a>
nottingf13: yes<a href="#t13:24" class="time">13:24</a>
nottingf13: although, due to the rsync hoop jumping,it would be kicked off via an internal script<a href="#t13:25" class="time">13:25</a>
f13nod<a href="#t13:25" class="time">13:25</a>
f13perhaps we should get that part automated, and we'll work on the installable part on the side?<a href="#t13:26" class="time">13:26</a>
nottingok, will start poking. the internal script will be something ridiculously short like ssh <host> doit && rsync<a href="#t13:27" class="time">13:27</a>
f13nod, that's what I was hoping for<a href="#t13:28" class="time">13:28</a>
f13rsync shouldn't be nearly as bad next time around.<a href="#t13:28" class="time">13:28</a>
nottingoh, all the extras debuginfo stuff *should* be imported now.<a href="#t13:28" class="time">13:28</a>
f13goot.<a href="#t13:28" class="time">13:28</a>
f13well that will make it slower 9:<a href="#t13:28" class="time">13:28</a>
nottingrandom note: koji commandline throws bizarre errors if you try to import the same source RPM twice in parallel<a href="#t13:29" class="time">13:29</a>
nottingbut the db ends up ok<a href="#t13:29" class="time">13:29</a>
f13anything else on Rawhide?<a href="#t13:30" class="time">13:30</a>
nottingjust fyi:<a href="#t13:30" class="time">13:30</a>
nottingi started that compose at ~3PM on friday<a href="#t13:30" class="time">13:30</a>
wwoodsoh - some of the folks internal to Red Hat have asked about rawhide builds for non-standard arches (e.g. ia64)<a href="#t13:30" class="time">13:30</a>
nottingit finished pushing to the mirror master at ~10AM on saturday<a href="#t13:30" class="time">13:30</a>
jeremywwoods: they need to get the package builds for those arches going<a href="#t13:31" class="time">13:31</a>
nottingf13 (and other interested parties) - please chime in on <a href=""></a><a href="#t13:31" class="time">13:31</a>
wwoodsI don't really want to commit us to building that stuff, but it seems like we might want to do it internally<a href="#t13:31" class="time">13:31</a>
f13wwoods: lets talk about that in a more internal setting.<a href="#t13:32" class="time">13:32</a>
f13wwoods: but simple answer, Fedora will not be building/composing rawhide for those arches.<a href="#t13:32" class="time">13:32</a>
f13and Red Hat won't be doing it for Fedora either.<a href="#t13:32" class="time">13:32</a>
wwoodsright, this will have implications for other people wanting to do their own koji->mash->pungi composes of rawhide (SGI, AlphaCore, etc)<a href="#t13:32" class="time">13:32</a>
f13wwoods: correct, they should have their own koji to mash from (:<a href="#t13:33" class="time">13:33</a>
jeremywwoods: just that they need to do the builds themselves.  they're secondary arches as far as fedora is concerned<a href="#t13:33" class="time">13:33</a>
wwoodsin short: we'll probably want to figure out some directions for telling other people how to build rawhide themselves, at some point (like after F7)<a href="#t13:33" class="time">13:33</a>
f13wwoods: this is all part of our grand secondary arch plans, which spot-food is leading.<a href="#t13:33" class="time">13:33</a>
wwoodsgotcha.<a href="#t13:33" class="time">13:33</a>
f13ok, moving on.<a href="#t13:35" class="time">13:35</a>
Idea.png f13 changed the topic of #fedora-meeting to: Freeze on Thursday?<a href="#t13:35" class="time">13:35</a>
f13we agreed last week to revisit this week.<a href="#t13:35" class="time">13:35</a>
f13although given we've only had one rawhide, perhaps we need to revisit on Wed?<a href="#t13:35" class="time">13:35</a>
wwoodsmy opinion depends on what we consider to be the gate for the freeze. we're obviously nowhere near fixing all the open blockers.<a href="#t13:36" class="time">13:36</a>
wwoodsso if that's not the determining factor.. what is?<a href="#t13:37" class="time">13:37</a>
f13wwoods: are we making progress on them?<a href="#t13:38" class="time">13:38</a>
mmcgrathf13: sorry I've got to run, (flight to catch) any immediate needs from me?  I'll get back on when I'm at the gate.<a href="#t13:38" class="time">13:38</a>
f13mmcgrath: don't think so.<a href="#t13:38" class="time">13:38</a>
wwoodsat this point we're already in a devel freeze so I'm unclear on what this other freeze will mean<a href="#t13:38" class="time">13:38</a>
warrenWithout rawhide, we can't get bits to testers and get feedback turnaround, we're in an awfully shaky level of awareness<a href="#t13:38" class="time">13:38</a>
wwoodsf13: yeah, some, but there's some huge scary ones, like anaconda's handling of mdraid<a href="#t13:38" class="time">13:38</a>
mmcgrathk<a href="#t13:38" class="time">13:38</a>
f13wwoods: we'd stop taking anything but the blocker bugs and things that prevent composes.<a href="#t13:38" class="time">13:38</a>
* mmcgrath out<a href="#t13:38" class="time">13:38</a>
f13warren: we've had one rawhide... (:<a href="#t13:38" class="time">13:38</a>
wwoodsahhh. yeah, at this point I'm fine saying "nothing but blockers and compose-breakers from now on" on thursday.<a href="#t13:39" class="time">13:39</a>
nottingwwoods: what sort of status do we have on the updated rawhide? anything go completely bang?<a href="#t13:40" class="time">13:40</a>
warrenWe need to be testing install of that, and testing upgrade of previous Fedora...<a href="#t13:40" class="time">13:40</a>
wwoodschatter seems mostly positive, although emacs exploded<a href="#t13:40" class="time">13:40</a>
f13wwoods: at that time, we'd also branch CVS and let stuff start moving toward F8 and f7 updates.<a href="#t13:40" class="time">13:40</a>
wwoodsso we're talking about the freeze *and* the branchpoint. ok.<a href="#t13:41" class="time">13:41</a>
f13yeah, they're tied together<a href="#t13:41" class="time">13:41</a>
wwoodsgotcha.<a href="#t13:41" class="time">13:41</a>
warrenIn order to reduce confusion, should we also STOP addition of "extras" packages at that point?<a href="#t13:42" class="time">13:42</a>
warrenat least until gold is cut<a href="#t13:42" class="time">13:42</a>
f13warren: they could be added to devel/, which would build to dist-f8<a href="#t13:42" class="time">13:42</a>
warrenoh<a href="#t13:42" class="time">13:42</a>
warrenok<a href="#t13:42" class="time">13:42</a>
f13warren: we'd just not respond to any FC-7 branch requests for new packages.<a href="#t13:42" class="time">13:42</a>
warrenk<a href="#t13:43" class="time">13:43</a>
f13or even if we did, they'd get tagged dist dist-fc7-updates-candidate<a href="#t13:43" class="time">13:43</a>
nottingwarren: might be a good idea, although it gives a short time that upgrades could be broken. can be fixed post-release ,though<a href="#t13:43" class="time">13:43</a>
wwoodsthere's a few packages - beagle, hal, wireless-tools - that we need to make decisions on. I feel like those should be pre-freeze but I don't know if that's required.<a href="#t13:43" class="time">13:43</a>
warrenf13, well, branch requests can go through, we just wont tag?<a href="#t13:43" class="time">13:43</a>
warrenwwoods, what is the hal issue?<a href="#t13:43" class="time">13:43</a>
warrenbeagle we really should turn off prior to the freeze.<a href="#t13:43" class="time">13:43</a>
f13warren: right, we would direct new packages to updates, not the final tree.<a href="#t13:43" class="time">13:43</a>
jeremywwoods: then we should go through them one by one now<a href="#t13:43" class="time">13:43</a>
wwoodswarren: newest hal screws up quirks for a bunch of machines - symptoms are mostly resume regressions<a href="#t13:44" class="time">13:44</a>
wwoodsbeagle is.. beagle. the maintainer suggests we remove it or disable it by default for F7.<a href="#t13:44" class="time">13:44</a>
* warren votes for removal<a href="#t13:44" class="time">13:44</a>
wwoodsnewest wireless-tools has a patch that's supposed to fix 64-bit that actually breaks all wireless scanning on 64-bit systems.<a href="#t13:45" class="time">13:45</a>
nottingwwoods: eh, whaaa? (re: beagle)<a href="#t13:45" class="time">13:45</a>
nottingwhy is it suddenly that drastic now?<a href="#t13:45" class="time">13:45</a>
wwoodsnotting: yes, filed under "things that would have been nice to know before the feature freeze"<a href="#t13:45" class="time">13:45</a>
f13notting: posted to -devel, they can't fix it where it breaks nad makes things really slow, want to make it off by default.<a href="#t13:45" class="time">13:45</a>
jeremywwoods: one at a time implies not just spewing them all out together so that we can sanely discuss them :/<a href="#t13:45" class="time">13:45</a>
warrenwireless-tools worked reasonably well on x86-64 prior to that patch.  With that patch, it doesn't work AT ALL.  They stopped responding on the topic, so we should just back it out.<a href="#t13:45" class="time">13:45</a>
* warren checks on caillon...<a href="#t13:45" class="time">13:45</a>
f13lets go back to beagle.<a href="#t13:45" class="time">13:45</a>
wwoodsstarting with beagle, then.<a href="#t13:46" class="time">13:46</a>
wwoodsbug #217031<a href="#t13:46" class="time">13:46</a>
wwoodsbasically, certain file types make the scanner freak out and peg the CPU forever<a href="#t13:46" class="time">13:46</a>
wwoods...again<a href="#t13:46" class="time">13:46</a>
f13oh here's the fun thing.<a href="#t13:47" class="time">13:47</a>
f13the maintainer already axed it from comps. :(<a href="#t13:47" class="time">13:47</a>
wwoodsone could make the argument that beagle is less solid than NM, and we don't enable NM by default, so...<a href="#t13:47" class="time">13:47</a>
wwoodsit stands to reason that we should at least *consider* removing it<a href="#t13:47" class="time">13:47</a>
wwoodsyeah, especially since the maintainer has attempted to remove it himself.<a href="#t13:47" class="time">13:47</a>
jeremyf13: it's not like a comps change is impossible to revert<a href="#t13:48" class="time">13:48</a>
f13no, it's not, just providing a data point.<a href="#t13:48" class="time">13:48</a>
warrenIs beagle the only mono thing that is installed by default?<a href="#t13:48" class="time">13:48</a>
f13warren: tomboy<a href="#t13:49" class="time">13:49</a>
jeremywarren: I think tomboy gets installed by default also<a href="#t13:49" class="time">13:49</a>
f13f-spot<a href="#t13:49" class="time">13:49</a>
warrendefault?<a href="#t13:49" class="time">13:49</a>
warrenoh<a href="#t13:49" class="time">13:49</a>
f13not sure if those are defaults actaully<a href="#t13:49" class="time">13:49</a>
jeremytomboy is default<a href="#t13:49" class="time">13:49</a>
warrenwell, given that beagle has such negative effects, it makes sense to simply not install it by default.<a href="#t13:49" class="time">13:49</a>
f13tomboy is default, f-spot is optional.<a href="#t13:49" class="time">13:49</a>
wwoodsbeagle is the only one that's running by default<a href="#t13:49" class="time">13:49</a>
jeremywwoods: yes<a href="#t13:49" class="time">13:49</a>
wwoodswhich means every fedora system automatically has the mono interpreter stuff running<a href="#t13:49" class="time">13:49</a>
nottingf-spot is optional<a href="#t13:49" class="time">13:49</a>
nottingwhich means it's not in prime, if i understand right<a href="#t13:50" class="time">13:50</a>
nottingor fedora, or whatever we're calling it ;)<a href="#t13:50" class="time">13:50</a>
wwoodsnot to mention the overhead of the scanning, the fact that it scans by default on batteries.. arjan has noted that it'll kill an hour from battery life<a href="#t13:50" class="time">13:50</a>
warrenDo not install beagle by default, but let it run by default if installed.  That way only people who choose to install it conveniently get it without more twiddling.<a href="#t13:50" class="time">13:50</a>
f13as it stands right now, beagle and beagle-evolution are optional.  I'm OK with it staying that way.<a href="#t13:50" class="time">13:50</a>
nottingf13: so, not in the tree?<a href="#t13:50" class="time">13:50</a>
* rdieter pokes head in...<a href="#t13:50" class="time">13:50</a>
wwoodsoptional? they were previously defaults<a href="#t13:50" class="time">13:50</a>
wwoodsis that alexl's change?<a href="#t13:50" class="time">13:50</a>
f13warren: maintainer changed comps.<a href="#t13:50" class="time">13:50</a>
f13er wwoods<a href="#t13:50" class="time">13:50</a>
f13notting: unless they get pulled in via some other deps, yes.<a href="#t13:51" class="time">13:51</a>
wwoodsah, I thought you were saying they were optional prior to his change<a href="#t13:51" class="time">13:51</a>
f13notting: actually I just did a pungi compose with the new comps and it does not get pulled into the spin.<a href="#t13:51" class="time">13:51</a>
warrenhow is this difficult?  What is wrong with simply deciding not to install it by default?<a href="#t13:51" class="time">13:51</a>
nottingjeremy: is commitspam for comps working for you?<a href="#t13:51" class="time">13:51</a>
f13warren: for one, I would like to be sure that our frozen release notes don't make reference to it.<a href="#t13:52" class="time">13:52</a>
f13quaid: stickster: know if there is any beagle content in the release notes?<a href="#t13:52" class="time">13:52</a>
wwoodsso, wait, it's not even going to be on the *media* anymore?<a href="#t13:52" class="time">13:52</a>
jeremynotting: only via fedora-extras-commits<a href="#t13:52" class="time">13:52</a>
wwoodswon't that be.. bad.. for people upgrading from fc6?<a href="#t13:52" class="time">13:52</a>
jeremywwoods: it might make sense to add it to the manifest so that it remains on the media<a href="#t13:52" class="time">13:52</a>
f13wwoods: it wouldn't be, unless we add it in via the manifest for the upgrade case.<a href="#t13:52" class="time">13:52</a>
f13(good catch)<a href="#t13:52" class="time">13:52</a>
sticksterf13: I don't think there's any beagle content, but let me check real quick<a href="#t13:52" class="time">13:52</a>
jeremy(side-note: we need to revisit the manifest thing again post-f7...  it's causing us a fair bit of pain due to optional packages that we due want available, but not installed by default)<a href="#t13:53" class="time">13:53</a>
sticksterf13: nope, none to date in our XML in CVS<a href="#t13:53" class="time">13:53</a>
wwoodsit's sad, too, I really like the concept of beagle<a href="#t13:54" class="time">13:54</a>
* stickster too<a href="#t13:54" class="time">13:54</a>
wwoodsbut, ugh. the current implementation is just.. not nearly ready<a href="#t13:54" class="time">13:54</a>
nottingwell ,it's ready enough that we've shipped it by default for how long?<a href="#t13:54" class="time">13:54</a>
f13wwoods: tried the other search thingy?<a href="#t13:54" class="time">13:54</a>
wwoodsanyway, so I guess it's decided: we're making beagle optional in f7 but keeping it on the media<a href="#t13:54" class="time">13:54</a>
niriktracker any better?<a href="#t13:55" class="time">13:55</a>
nottingjeremy: should be fixed now<a href="#t13:55" class="time">13:55</a>
wwoodsf13: tracker? yeah, it's nicely quick and low memory reqs, but it doesn't index evolution yet<a href="#t13:55" class="time">13:55</a>
wwoodsthat's the big win for me<a href="#t13:55" class="time">13:55</a>
sticksternirik: better on this particular axis (battery drain), but covers  fewer formats<a href="#t13:55" class="time">13:55</a>
wwoodsalthough it's way better at, for instance, finding tagged media files<a href="#t13:55" class="time">13:55</a>
wwoodsbeagle doesn't index id3 / ogg tags<a href="#t13:55" class="time">13:55</a>
stickstertrue dat<a href="#t13:55" class="time">13:55</a>
nottingwhich part of tracker is 'better'? i would assume the 'daemon that has to walk all files' would suck no matter how it's written<a href="#t13:55" class="time">13:55</a>
f13I guess we should vote on this.<a href="#t13:55" class="time">13:55</a>
f13Proposal: Accept maintainer's comps change, making beagle optional.  Include it in manifest so that it is on media for upgrades.<a href="#t13:56" class="time">13:56</a>
f13+1<a href="#t13:56" class="time">13:56</a>
warren+<a href="#t13:56" class="time">13:56</a>
wwoods+1<a href="#t13:56" class="time">13:56</a>
jeremy+1<a href="#t13:56" class="time">13:56</a>
warrenerr.. +1<a href="#t13:56" class="time">13:56</a>
nottingis there another option?<a href="#t13:56" class="time">13:56</a>
f13notting: force it to be default again.<a href="#t13:56" class="time">13:56</a>
wwoodsforce it back to being default, get someone else to fix 217031 for F7<a href="#t13:56" class="time">13:56</a>
jeremynotting: leave it in its current state?  hope maybe something can get fixed in the next few days?<a href="#t13:57" class="time">13:57</a>
rdieterproposal: +1<a href="#t13:57" class="time">13:57</a>
wwoodswe should definitely re-evaluate beagle and tracker for F8 though<a href="#t13:57" class="time">13:57</a>
notting+0.1. I really don't like changing things after feature freeze like this, but it being essentially a feature-ectomy makes it clean. HOWEVER<a href="#t13:58" class="time">13:58</a>
nottingwwoods: please test to make sure all the default panel/etc search stuff still does something sane :)<a href="#t13:58" class="time">13:58</a>
wwoodswill do.<a href="#t13:58" class="time">13:58</a>
* jwb is late<a href="#t13:58" class="time">13:58</a>
wwoodsgood lord. I can't even load<a href="#t13:59" class="time">13:59</a>
rdieterwwoods: for f8, include <a href=""></a> for evaluation too.<a href="#t13:59" class="time">13:59</a>
wwoodsokay, so on the off chance that removing beagle causes a ripple effect<a href="#t13:59" class="time">13:59</a>
nirikand recoll<a href="#t13:59" class="time">13:59</a>
wwoodssquash the ripple bugs, or revert the change & go back to beagle-default?<a href="#t13:59" class="time">13:59</a>
f13depends on the ripple.<a href="#t14:00" class="time">14:00</a>
* f13 doesn't like planning that far ahead.<a href="#t14:00" class="time">14:00</a>
jeremywell, the ripple bugs probably need fixing anyway.  since people apparently _are_ already just removing beagle from their system<a href="#t14:00" class="time">14:00</a>
mdomschnotting, --delay-updates :-(<a href="#t14:01" class="time">14:01</a>
wwoodsso actually, that bug is fixed in beagle-0.2.17<a href="#t14:01" class="time">14:01</a>
nottingmdomsch: rhel 2.1 :(<a href="#t14:01" class="time">14:01</a>
wwoodsbut the maintainer has just requested that we remove beagle from the distro rather than backporting the fix (or updating to 0.2.17)<a href="#t14:01" class="time">14:01</a>
nottingwwoods: someone claimed that 0.2.17 still failed for them<a href="#t14:02" class="time">14:02</a>
f13anyway, I think the vote passed, so we have a plan for now.<a href="#t14:02" class="time">14:02</a>
f13I'll respond to Alex's post<a href="#t14:02" class="time">14:02</a>
f13wwoods: whats the next item on your hit list?<a href="#t14:02" class="time">14:02</a>
wwoodsnext let's do wireless-tools, which is pretty straightforward<a href="#t14:03" class="time">14:03</a>
nirikcheckin on wireless tools this morning.<a href="#t14:03" class="time">14:03</a>
nirik<a href=""></a><a href="#t14:03" class="time">14:03</a>
mdomschnotting, what's it going to take to upgrade that RPM?<a href="#t14:03" class="time">14:03</a>
wwoodsnirik: oh nice. have you tried it?<a href="#t14:03" class="time">14:03</a>
niriknot yet, but I can real quick.<a href="#t14:03" class="time">14:03</a>
nirikexcept it's not built. ;(<a href="#t14:03" class="time">14:03</a>
wwoodsthis is bug #238657<a href="#t14:03" class="time">14:03</a>
nottingmdomsch: not sure if they'll take a non-official update. obviously, you can guess the chances of getting rsync updated for rhel2.1 or rhel3 at this point<a href="#t14:05" class="time">14:05</a>
f13caillon is stuck in airport hell.<a href="#t14:05" class="time">14:05</a>
f13won't be back until Wed~<a href="#t14:05" class="time">14:05</a>
wwoodswireless-tools-28-1 works fine, 28-2 added a patch to "Backport a few 64bit alignment fixes from the latest betas"<a href="#t14:05" class="time">14:05</a>
wwoodswhich which broke all wireless scanning on x86_64, so we've been telling people to revert to -1<a href="#t14:05" class="time">14:05</a>
f13he'll be checking mail and such periodically so we could get his go ahead to build -3 and see if it works.<a href="#t14:05" class="time">14:05</a>
f13well, anybody can build a test srpm and build it that way<a href="#t14:05" class="time">14:05</a>
warrenProposal: Just back it out and build -3.<a href="#t14:05" class="time">14:05</a>
f13warren: are you effected by this?<a href="#t14:05" class="time">14:05</a>
* nirik builds the cvs version. <a href="#t14:05" class="time">14:05</a>
wwoodsI think nirik's building the current -3 (revised patch) right now<a href="#t14:06" class="time">14:06</a>
f13nirik: are you building locally?<a href="#t14:06" class="time">14:06</a>
warrenf13, yes<a href="#t14:06" class="time">14:06</a>
nirikyeah, just locally.<a href="#t14:06" class="time">14:06</a>
nirikseems to work ok.<a href="#t14:06" class="time">14:06</a>
warrenf13, I discovered and reported the breakage and spent hours with caillon trying to fix it<a href="#t14:06" class="time">14:06</a>
nirikI can still scan fine.<a href="#t14:06" class="time">14:06</a>
warrenf13, we were unsuccessful<a href="#t14:06" class="time">14:06</a>
f13warren: including the patch he has in CVS?<a href="#t14:06" class="time">14:06</a>
warrenf13, yes.<a href="#t14:06" class="time">14:06</a>
nirikwarren: looks like he backed out lots of the former -2 patch...<a href="#t14:07" class="time">14:07</a>
nirik<a href=""></a><a href="#t14:07" class="time">14:07</a>
warrenwhy didn't he build it?<a href="#t14:07" class="time">14:07</a>
f13warren: probably because he's stuck in an airport and the tubes suck.<a href="#t14:07" class="time">14:07</a>
nirikdunno. It works here tho, and -2 segfaulted on me<a href="#t14:07" class="time">14:07</a>
warrennirik, latest CVS you mean?<a href="#t14:07" class="time">14:07</a>
f13I'm doing a --scratch build that will be publically available, we could get reporters to try that build.<a href="#t14:07" class="time">14:07</a>
nirikwarren: yes, -3 works here... built locally from cvs.<a href="#t14:08" class="time">14:08</a>
nottingf13: stuck getting out of SD?<a href="#t14:08" class="time">14:08</a>
f13<a href=""></a><a href="#t14:08" class="time">14:08</a>
f13notting: yeah<a href="#t14:08" class="time">14:08</a>
warrenf13, given that -2 is totally broken, why not just build and push -3 so it gets wider testing?<a href="#t14:08" class="time">14:08</a>
warrenf13, we not only need x86_64 testers, but also ppc and i386 to be sure the 64bit fix didn't break 32bit.<a href="#t14:09" class="time">14:09</a>
f13warren: scratch build does all arches<a href="#t14:09" class="time">14:09</a>
warrenf13, yes, but why not just push it to rawhide tagged?  It can't be worse than -2, and we automatically get WAY more testing.<a href="#t14:09" class="time">14:09</a>
nirik<a href=""></a> if anyone here wants my locally built one to test real quick.<a href="#t14:09" class="time">14:09</a>
f13warren: because if this doesn't fix the x86_64, the easiest thing is to just untag.<a href="#t14:09" class="time">14:09</a>
jeremythe patch doesn't look insane; I can definitely see it fixing 64bit problems<a href="#t14:10" class="time">14:10</a>
warrenf13, please don't just revert and expect people to use -1.  We should properly push an overriding newer release.<a href="#t14:10" class="time">14:10</a>
f13<a href=""></a><a href="#t14:10" class="time">14:10</a>
wwoodsI'd propose that if that -3 build turns out to be No Good then we just revert the 64-bit patches entirely and call that -3 (or -4 or whatever)<a href="#t14:10" class="time">14:10</a>
jeremywwoods: +1<a href="#t14:10" class="time">14:10</a>
warrenI think we should just push -3 in to rawhide, it is no worse than -2.  We need wide exposure and testing.<a href="#t14:10" class="time">14:10</a>
warrenIf it explodes just revert fully in -4.<a href="#t14:11" class="time">14:11</a>
jeremywarren/nirik: since the two of you are hitting this and caillon is stuck in airport hell, can one of the two of you drive it?<a href="#t14:11" class="time">14:11</a>
wwoodswe're not doing automatic rawhide pushes yet, so that's not really fully effective, but yeah<a href="#t14:11" class="time">14:11</a>
f13right<a href="#t14:11" class="time">14:11</a>
warrenjeremy, yeah, I'll drive, I already spent hours on this.<a href="#t14:11" class="time">14:11</a>
f13it would be far quicker to get people to test these scratch built rpms.<a href="#t14:11" class="time">14:11</a>
warrenf13, why not both?<a href="#t14:11" class="time">14:11</a>
jeremyokay.  we have a plan, let's move on :)<a href="#t14:11" class="time">14:11</a>
f13since the build is already done.<a href="#t14:11" class="time">14:11</a>
warrenjust tag it and do it both ways.<a href="#t14:12" class="time">14:12</a>
f13warren: whatever.  I don't care.  Scratch rpms are available _now_ for people to test.  Can be done in parallel.<a href="#t14:12" class="time">14:12</a>
f13can't tag a scratch build.<a href="#t14:12" class="time">14:12</a>
wwoodsnext on my list is hal - was davidz at the Summit? will he be around this week?<a href="#t14:12" class="time">14:12</a>
jeremywwoods: item #3... hal stuffs<a href="#t14:12" class="time">14:12</a>
jeremydavidz was at the summit<a href="#t14:12" class="time">14:12</a>
* warren builds -3 for real and tags it...<a href="#t14:12" class="time">14:12</a>
wwoodsbasically hal-0.5.9-6.fc7 fixed the suspend/resume quirks for some stuff (T60 maybe?)<a href="#t14:12" class="time">14:12</a>
jeremyand I think he's traveling this week :-/<a href="#t14:13" class="time">14:13</a>
wwoodsbut broke it for others (my pitiable t43)<a href="#t14:13" class="time">14:13</a>
wwoodsI'm actually not sure -6 was the one that fixed davej's laptop<a href="#t14:13" class="time">14:13</a>
warrenwwoods, my T60 was suspending/resuming fine both before and after.<a href="#t14:13" class="time">14:13</a>
wwoodswarren: well, okay then<a href="#t14:13" class="time">14:13</a>
* warren will reinstall his T41 tonight to test it there...<a href="#t14:13" class="time">14:13</a>
* nirik tries the scratchbuild wireless-tools. Works fine. <a href="#t14:13" class="time">14:13</a>
wwoodsthat answers that. but it definitely breaks my t43 - see 238792<a href="#t14:14" class="time">14:14</a>
jeremywwoods: the fix is probably that quirks are being _passed_ now.  some of the quirks in hal-info may be wrong<a href="#t14:14" class="time">14:14</a>
wwoodsjeremy: ahhhh.<a href="#t14:14" class="time">14:14</a>
jeremy(there's been a lot of discussion about that on the hal list)<a href="#t14:14" class="time">14:14</a>
f13quirks being passed now seems like a feature<a href="#t14:14" class="time">14:14</a>
wwoodsdefinitely<a href="#t14:14" class="time">14:14</a>
jeremyf13: bugfix<a href="#t14:14" class="time">14:14</a>
f13jeremy: where bug is the feature isn't there?<a href="#t14:14" class="time">14:14</a>
jeremyf13: where bug is without passing the quirks, there's no way in hell for suspend to work on large classes of laptops<a href="#t14:15" class="time">14:15</a>
wwoodsokay, let's definitely keep -6 and push davidz or somebody to get the right quirks for t43 et. al.<a href="#t14:15" class="time">14:15</a>
jeremyf13: the quirks were all handled with stuff hardcoded in the scripts in fc6; they moved to being in fdi files for f7<a href="#t14:15" class="time">14:15</a>
f13jeremy: were they being passed for some period of time and just not for a short period?<a href="#t14:15" class="time">14:15</a>
f13ah.<a href="#t14:15" class="time">14:15</a>
wwoodsthe final big pre-freeze problem I want to discuss is mdraid handling<a href="#t14:15" class="time">14:15</a>
f13that sounds a bit better, although does that mean we haven't seen these quirks at all during f7 until just now?<a href="#t14:16" class="time">14:16</a>
jeremywwoods: for the hal stuff, I'll try to get hughsie to take a look<a href="#t14:16" class="time">14:16</a>
wwoodsjeremy: that would be fantastic, thank you<a href="#t14:16" class="time">14:16</a>
f13wwoods: davidz won't be back until the 20th.<a href="#t14:16" class="time">14:16</a>
jeremyf13: we've seen some of them; suspend/resume is doom :-/<a href="#t14:16" class="time">14:16</a>
jeremyanyway, mdraid<a href="#t14:16" class="time">14:16</a>
wwoodsso it turns out that all my test machines are IDE-free now, so maybe that's why this went on so long, but as far as I can tell<a href="#t14:16" class="time">14:16</a>
wwoodsthe old raidautorun stuff + IDE = doooom<a href="#t14:16" class="time">14:16</a>
notting'the old'?<a href="#t14:17" class="time">14:17</a>
wwoodsthe ioctl that anaconda uses<a href="#t14:17" class="time">14:17</a>
wwoodsand the stuff that mkinitrd uses<a href="#t14:17" class="time">14:17</a>
nottingmkinitrd had a fix to use mdadm go in<a href="#t14:17" class="time">14:17</a>
wwoodsthey both use the older mdraid metadata, which encodes the rest of the raid set as maj/min device numbers<a href="#t14:17" class="time">14:17</a>
wwoodswhich obviously explodes when we change all hdX to sdX<a href="#t14:18" class="time">14:18</a>
wwoodsnotting: yeah, that fix is in mkinitrd (but not tagged for F7)<a href="#t14:18" class="time">14:18</a>
wwoodsanaconda will need a similar fix to be able to see pre-f7 mdraid devices that include IDE members<a href="#t14:18" class="time">14:18</a>
wwoodsbut anaconda just calls the autorun ioctl directly, as far as I can tell<a href="#t14:19" class="time">14:19</a>
nottingthis is 'see them even though they're not referenced by ide device name anywhere on the system'?<a href="#t14:19" class="time">14:19</a>
wwoodsnotting: yeah - they're referenced by ide name in the @#!^!@^ superblock<a href="#t14:19" class="time">14:19</a>
wwoodsI need to confirm this, but AFAIK there's a couple different versions of the mdraid metadata, and that ioctl reads the old metadata, which lists the members by maj/min number<a href="#t14:20" class="time">14:20</a>
wwoodsmdadm reads the newer metadata, which uses partition uuids to find 'em<a href="#t14:20" class="time">14:20</a>
wwoodsso mdadm works<a href="#t14:20" class="time">14:20</a>
f13this sounds a lot like pjones land here.<a href="#t14:21" class="time">14:21</a>
wwoodsyeah, if we decide that This Needs To Be Done then pjones'll be the one doing the heavy lifting, I suspect<a href="#t14:22" class="time">14:22</a>
jeremyerg.  indeed the major/minor is used there<a href="#t14:22" class="time">14:22</a>
f13did he do the mkinitrd change?<a href="#t14:22" class="time">14:22</a>
* jeremy is looking at the kernel code<a href="#t14:22" class="time">14:22</a>
wwoodsjeremy: yeah. facepalm.<a href="#t14:22" class="time">14:22</a>
wwoodsthis is a fairly invasive change to loader this late in the game.. but I'm not sure we have a choice<a href="#t14:22" class="time">14:22</a>
jeremythe anaconda change is going to be ... less straight-forward, though :-/<a href="#t14:22" class="time">14:22</a>
wwoodsjeremy: so.. are we just going to have to make the change and hope everything works out?<a href="#t14:24" class="time">14:24</a>
jeremywwoods: well, we can do a fair bit of targeted testing on it to make ourselves feel better<a href="#t14:24" class="time">14:24</a>
wwoodsI dunno, maybe there's a workaround? tell people to switch to vt2 and run mdadm? or is the impact small enough that we just go for it<a href="#t14:24" class="time">14:24</a>
nottingreally really really could use fixed<a href="#t14:25" class="time">14:25</a>
jeremywwoods: the workaround won't work<a href="#t14:25" class="time">14:25</a>
wwoodsreally really really should have been fixed months ago<a href="#t14:25" class="time">14:25</a>
* jeremy really really really filed a bug about it months ago :(<a href="#t14:25" class="time">14:25</a>
wwoodsI'm sad that we all missed it or forgot about it<a href="#t14:25" class="time">14:25</a>
wwoodsI'm gonna get some IDE drives for my test machines<a href="#t14:25" class="time">14:25</a>
nottingwwoods: alas, the only box i have with old-ide is my laptop, and i can't really nuke it to test this<a href="#t14:25" class="time">14:25</a>
wwoodsyeah, no, I should have caught this months ago<a href="#t14:26" class="time">14:26</a>
warrenWhich bug number are we discussing?  Is there any concise summary of this problem?<a href="#t14:26" class="time">14:26</a>
wwoodsso I'll be Super Tester Bitch for it<a href="#t14:26" class="time">14:26</a>
jeremynotting: well, most of the testing will need to be just general raid testing<a href="#t14:26" class="time">14:26</a>
jwbdoesn't qemu present devices as old-ide?<a href="#t14:26" class="time">14:26</a>
warrenhow old IDE are we talking about?<a href="#t14:26" class="time">14:26</a>
wwoodswarren: there's a bunch. 151653 is the first one<a href="#t14:26" class="time">14:26</a>
wwoodswarren: anything that used to be hdX<a href="#t14:26" class="time">14:26</a>
jeremyjwb: it does<a href="#t14:27" class="time">14:27</a>
jeremythat's how I tested old ide upgrades :)<a href="#t14:27" class="time">14:27</a>
wwoods231426, 238353, 221696, 213586, 238926<a href="#t14:28" class="time">14:28</a>
wwoodsweird that they all end in 3 or 6.<a href="#t14:29" class="time">14:29</a>
wwoodssome of those are mkinitrd-related and some anaconda-related but it's all the same root cause<a href="#t14:29" class="time">14:29</a>
jeremyso, can someone talk to peter and see if he has time to spend on it?  if not... then we have to figure out plan b (which probably involves me spending tomorrow on it)<a href="#t14:29" class="time">14:29</a>
f13wwoods: you seem to have a good handle on the problem, want to poke peter?<a href="#t14:30" class="time">14:30</a>
wwoodsf13: sure<a href="#t14:30" class="time">14:30</a>
warren"anaconda fails to bring up raid device whose members have moved"  .... moved means what?<a href="#t14:30" class="time">14:30</a>
wwoodswarren: changed device name/number<a href="#t14:30" class="time">14:30</a>
wwoodse.g. hda -> sdc<a href="#t14:30" class="time">14:30</a>
jeremyanything else?<a href="#t14:30" class="time">14:30</a>
warrenwwoods, this includes renumbering?  Same devices (like sdc1), but md1 inexplicably became md0?<a href="#t14:31" class="time">14:31</a>
* warren ran into weird behavior like that.<a href="#t14:31" class="time">14:31</a>
wwoodswarren: I don't think so?<a href="#t14:31" class="time">14:31</a>
wwoodsI'm not sure, I can try to investigate further though<a href="#t14:31" class="time">14:31</a>
rdieterwrt semi non-trivial kde updates coming down the pike, would I risk a lynching for suggesting including kde-3.5.7 (released to packagers today) in f7-final?<a href="#t14:32" class="time">14:32</a>
nottingyes<a href="#t14:33" class="time">14:33</a>
f13probably yes.<a href="#t14:33" class="time">14:33</a>
rdieterok, we'll stick with (patched) 3.5.6 for now. :)<a href="#t14:34" class="time">14:34</a>
wwoodsoh, dmraid is another thing I see a lot of complaints about, but I have no hardware to test.. and there appears to be a workaround<a href="#t14:34" class="time">14:34</a>
warrendmraid is like HPT and Promise ataraid?<a href="#t14:35" class="time">14:35</a>
jeremywarren: yes<a href="#t14:35" class="time">14:35</a>
wwoodsyeah, the fakeraid BIOS-raid stuff<a href="#t14:35" class="time">14:35</a>
warrenwwoods, what does the workaround involve?<a href="#t14:35" class="time">14:35</a>
f13wwoods: I have hardware to test, but just nvidia raid.<a href="#t14:35" class="time">14:35</a>
wwoodswarren: 234719 - apparently you can run "dmraid -ay" from the console during install and it'll see the devices properly. but then grub won't boot it, so it's not really useful<a href="#t14:36" class="time">14:36</a>
warrenwwoods, did dmraid work properly before?<a href="#t14:37" class="time">14:37</a>
warrenwwoods, FC6 installer?<a href="#t14:37" class="time">14:37</a>
wwoodsI thought it did - we have install test cases for it<a href="#t14:37" class="time">14:37</a>
f13warren: yes.<a href="#t14:37" class="time">14:37</a>
wwoodslike I said - no hardware, I've never tested it :/<a href="#t14:37" class="time">14:37</a>
warrenwwoods, is the broken component of this regression even isolated?<a href="#t14:38" class="time">14:38</a>
f13I'm going to test dmraid in just a few minutes.<a href="#t14:38" class="time">14:38</a>
warrenI'm tagging wireless-tools -3 because it isn't worse than -2.  If necessary we'll do a -4.<a href="#t14:39" class="time">14:39</a>
wwoodswarren: +1<a href="#t14:40" class="time">14:40</a>
wwoodsokay, enough bugtalk from me<a href="#t14:40" class="time">14:40</a>
warrenWe seriously need -3 to be tested not just by x86_64 users, but all users.<a href="#t14:40" class="time">14:40</a>
warrenwe don't want to accidentally break it for everyone else.<a href="#t14:41" class="time">14:41</a>
wwoodshopefully we can do a rawhide push after we cram in some more fixes and then see what people think<a href="#t14:41" class="time">14:41</a>
wwoodsdid we decide on the thursday freeze?<a href="#t14:41" class="time">14:41</a>
f13no....<a href="#t14:42" class="time">14:42</a>
f13wwoods: we got sidetracked by your list of decisions to be made<a href="#t14:43" class="time">14:43</a>
wwoodssorry!<a href="#t14:43" class="time">14:43</a>
f13no no, that's good<a href="#t14:43" class="time">14:43</a>
f13as we needed to get through that to make a decision.<a href="#t14:43" class="time">14:43</a>
wwoodsokay, knowing what we know now (there is significant badness but We Have A Plan, By God)<a href="#t14:43" class="time">14:43</a>
f13wwoods: do you feel any better about doing the blocker only/branching on Thursday?<a href="#t14:43" class="time">14:43</a>
wwoodsdefinitely<a href="#t14:44" class="time">14:44</a>
warrenvote on it?<a href="#t14:44" class="time">14:44</a>
wwoodsthe world gets until Thursday for new packages and last-minute updates (and we get a few days to clean up the blocker/target lists)<a href="#t14:45" class="time">14:45</a>
warrenf13, when do we decide which blockers we will actually stop release for?<a href="#t14:45" class="time">14:45</a>
wwoodsafter Thursday nothing that does not fix a blocker will be accepted<a href="#t14:45" class="time">14:45</a>
nirik81 still on the fc7blocker...<a href="#t14:45" class="time">14:45</a>
wwoodswarren: by definition, all of them, but a lot of things on that list shouldn't be there<a href="#t14:45" class="time">14:45</a>
wwoods<a href=""></a> is how we're supposed to decide<a href="#t14:45" class="time">14:45</a>
rdieterwe should work to prune those out (those that don't really belong).<a href="#t14:45" class="time">14:45</a>
wwoodsin short - apps that crash on startup, services that won't start, and anything that corrupts data or breaks installs<a href="#t14:46" class="time">14:46</a>
wwoodseverything else is a Target<a href="#t14:46" class="time">14:46</a>
f13wwoods: presumably we'd have a meeting thursday or earlier to go over the blocker list.<a href="#t14:46" class="time">14:46</a>
jeremyanyone who wants to go through before and prune is welcome :)<a href="#t14:46" class="time">14:46</a>
warrenwwoods, or broken deps?<a href="#t14:46" class="time">14:46</a>
f13Proposal:  Blocker only fixes starting Thursday (branch CVS same day)<a href="#t14:47" class="time">14:47</a>
warrenHmm, do we have a broken dep report after the merge?<a href="#t14:47" class="time">14:47</a>
jeremyf13: +1<a href="#t14:47" class="time">14:47</a>
f13repoclose away<a href="#t14:47" class="time">14:47</a>
* nirik also thinks broken EVR upgrades must be fixed. (If any)<a href="#t14:47" class="time">14:47</a>
warrenBroken EVR paths and broken deps must be fixed before shipping.<a href="#t14:48" class="time">14:48</a>
f13warren: those could be considered blockers.<a href="#t14:48" class="time">14:48</a>
f13wwoods: you should add that to your ReleaseCriteria<a href="#t14:48" class="time">14:48</a>
wwoodsf13: sure<a href="#t14:49" class="time">14:49</a>
nottinghee "it seems that it's always the dumper" (re: emacs)<a href="#t14:51" class="time">14:51</a>
f13can we get some more votes on the proposal?<a href="#t14:51" class="time">14:51</a>
nottingf13: +1<a href="#t14:51" class="time">14:51</a>
wwoods+1<a href="#t14:52" class="time">14:52</a>
rdieter+1<a href="#t14:52" class="time">14:52</a>
warrenwhich proposal specifically?<a href="#t14:53" class="time">14:53</a>
f13jwb: ping?<a href="#t14:53" class="time">14:53</a>
jwbf13, yo<a href="#t14:53" class="time">14:53</a>
wwoodsbroken EVR paths / broken deps: blocker for all (test & final) releases, or just final?<a href="#t14:53" class="time">14:53</a>
jwbf13, i'm like .25% here<a href="#t14:53" class="time">14:53</a>
jwbwhat's the proposal?<a href="#t14:53" class="time">14:53</a>
warrenwwoods, just final<a href="#t14:54" class="time">14:54</a>
nottingwwoods: definitely blocker for final. almost-but-not-quite blocker for test releases<a href="#t14:54" class="time">14:54</a>
warrenwwoods, it would have been impossible to fix deps of gaim-* plugins for Test4 for example.<a href="#t14:54" class="time">14:54</a>
f13jwb: Proposal:  Blocker only fixes starting Thursday (branch CVS same day)<a href="#t14:54" class="time">14:54</a>
wwoodsokay, I'll list both as SHOULD<a href="#t14:54" class="time">14:54</a>
warrenHow about.... fixing deps of stuff included in the spin is a blocker for test and final.<a href="#t14:54" class="time">14:54</a>
warrenFixing deps for the entire repo is a blocker for final.<a href="#t14:54" class="time">14:54</a>
jwbf13, yes that sounds very sane to me.  and i agree with the broken EVR paths being blocker as well<a href="#t14:54" class="time">14:54</a>
f13warren: I wouldn't go that far for test releases.<a href="#t14:55" class="time">14:55</a>
f13highly desireable, not blocker.<a href="#t14:55" class="time">14:55</a>
warrenf13, packages within a spin shouldn't have working deps?<a href="#t14:56" class="time">14:56</a>
f13warren: most should, but I'm not going to complain if some don't, since anaconda will still happily install<a href="#t14:56" class="time">14:56</a>
f13or at least it used to.<a href="#t14:56" class="time">14:56</a>
f13jeremy: will it still?<a href="#t14:56" class="time">14:56</a>
jeremyyes.  what else should we do?  laugh in your face? :)<a href="#t14:57" class="time">14:57</a>
jwbyes<a href="#t14:57" class="time">14:57</a>
f13nod<a href="#t14:57" class="time">14:57</a>
jwbyou should have laughing ninja kittens<a href="#t14:57" class="time">14:57</a>
nottingjeremy: steal the g-p-m 'can't suspend' sound<a href="#t14:58" class="time">14:58</a>
f13that's why I'm less inclined to drag out a test release freeze cycle waiting for every possible dep to be fixed.<a href="#t14:58" class="time">14:58</a>
wwoodsso, broken deps for the spin = MUST, broken EVR for entire distro = SHOULD?<a href="#t14:58" class="time">14:58</a>
wwoods(where MUST = blocker for test+final and SHOULD = blocker for final)<a href="#t14:59" class="time">14:59</a>
f13you're making things complicated<a href="#t14:59" class="time">14:59</a>
warrenwe need a matrix to visualize this<a href="#t14:59" class="time">14:59</a>
f13KISS<a href="#t14:59" class="time">14:59</a>
jwbyes, KISS.  "fix your fscking broken deps"<a href="#t14:59" class="time">14:59</a>
f13Broken deps for test == SHOULD>  Broken deps for final == MUST<a href="#t14:59" class="time">14:59</a>
f13btw, rawhide + dmraid just booted here.<a href="#t14:59" class="time">14:59</a>
wwoodsf13: is that broken deps for the entire distro, or just the stuff in the spin?<a href="#t15:00" class="time">15:00</a>
f13entire distro<a href="#t15:00" class="time">15:00</a>
f13since the entire distro is itself a spin<a href="#t15:00" class="time">15:00</a>
wwoodsoh, we're doing KitchenSink?<a href="#t15:01" class="time">15:01</a>
f13wwoods: presumably anybody can by enabling the full repo at install time<a href="#t15:01" class="time">15:01</a>
f13we'll do a tree, just no isos<a href="#t15:01" class="time">15:01</a>
wwoodsdo we consider broken EVR upgrade paths a subset of broken deps, or is that a separate thing?<a href="#t15:02" class="time">15:02</a>
jwbseparate<a href="#t15:02" class="time">15:02</a>
jwbbut it's important<a href="#t15:02" class="time">15:02</a>
warrenseparate, but equal<a href="#t15:02" class="time">15:02</a>
nottingoh crap<a href="#t15:03" class="time">15:03</a>
f13oh crap?<a href="#t15:03" class="time">15:03</a>
nottingwhere is the eula for f7 - is it *completely* online?<a href="#t15:03" class="time">15:03</a>
f13notting: yes.<a href="#t15:03" class="time">15:03</a>
f13notting: Legal decree, no eula in the distro<a href="#t15:03" class="time">15:03</a>
* jwb tries to determine with this has to do with EVR upgrade paths<a href="#t15:04" class="time">15:04</a>
nottingwhere is the current eula?<a href="#t15:04" class="time">15:04</a>
nottingjwb: nothing. apologies for the interrupt, want to make sure eula is correct?<a href="#t15:04" class="time">15:04</a>
f13um...<a href="#t15:04" class="time">15:04</a>
jwbcorrect as in lacking the "Core"?<a href="#t15:04" class="time">15:04</a>
nottingjwb: and not saying anything outright lying when we have firmware in the distro<a href="#t15:05" class="time">15:05</a>
f13<a href=""></a><a href="#t15:05" class="time">15:05</a>
f13it still has CORE (:<a href="#t15:05" class="time">15:05</a>
jwbcan try....  would rather have gregdk do it though...<a href="#t15:05" class="time">15:05</a>
jwbor someone with access to RH legal<a href="#t15:05" class="time">15:05</a>
nottingok. will start working this<a href="#t15:06" class="time">15:06</a>
warrenf13, what about name?<a href="#t15:06" class="time">15:06</a>
f13hrm?<a href="#t15:06" class="time">15:06</a>
jwbnotting, thx.  if it wasn't legal-ish i would have no issues<a href="#t15:06" class="time">15:06</a>
nottingwarren: names are under review<a href="#t15:06" class="time">15:06</a>
f13I guess we voted for the freeze, next topic<a href="#t15:07" class="time">15:07</a>
f13well, we're over time anyway.<a href="#t15:07" class="time">15:07</a>
warrenby an hour =)<a href="#t15:07" class="time">15:07</a>
f13these meetings aren't short :(<a href="#t15:07" class="time">15:07</a>
warrenwho will announce the Thursday freeze?<a href="#t15:08" class="time">15:08</a>
jwbf13, want me to update the freeze/release dates?<a href="#t15:08" class="time">15:08</a>
f13I will.<a href="#t15:08" class="time">15:08</a>
warrenk<a href="#t15:08" class="time">15:08</a>
jwbok<a href="#t15:08" class="time">15:08</a>
* rdieter is busy with work-stuff atm, ping me if you needed.<a href="#t15:08" class="time">15:08</a>
f13jwb: I don't think we changed any dates today.<a href="#t15:08" class="time">15:08</a>
jwbf13, well we set the freeze date.<a href="#t15:08" class="time">15:08</a>
Idea.png f13 changed the topic of #fedora-meeting to: <a href=""></a> -- Meetings often get logged -- see schedule in the wiki for next meeting<a href="#t15:08" class="time">15:08</a>
f13jwb: it was already set for Thursday<a href="#t15:08" class="time">15:08</a>
f13we just confirmed that we didn't need to further move it<a href="#t15:09" class="time">15:09</a>
jwbf13, <a href=""></a><a href="#t15:09" class="time">15:09</a>
jwbf13, not according to that :)<a href="#t15:09" class="time">15:09</a>
warrenf13, even if nothing changed, the warnings should go out.<a href="#t15:09" class="time">15:09</a>
f13hrm, I thought we changed that last week.  *sigh*<a href="#t15:09" class="time">15:09</a>
f13warren: yeah, we're talking about a seperate issue.<a href="#t15:10" class="time">15:10</a>
jwbf13, well we had the "thou shalt be done by 31 of May" come down, but i never saw anything about the freeze date<a href="#t15:10" class="time">15:10</a>
jwbf13, anyway, just update it when you send out the announce eh?<a href="#t15:10" class="time">15:10</a>
f13roger<a href="#t15:10" class="time">15:10</a>
jwbdanke<a href="#t15:10" class="time">15:10</a>
wwoodsactually we need to be done by 29 May, IIRC<a href="#t15:11" class="time">15:11</a>
jwbyeah, something like that<a href="#t15:11" class="time">15:11</a>
warrengold bits so they can burn it<a href="#t15:11" class="time">15:11</a>
wwoodsand synched/burnt by 31<a href="#t15:12" class="time">15:12</a>
f13which I'm still kind of thinking may be an act of god.<a href="#t15:13" class="time">15:13</a>
f13or act of Zod<a href="#t15:13" class="time">15:13</a>
jwbf13, we need to get the updates tags ready...<a href="#t15:15" class="time">15:15</a>
f13yeah<a href="#t15:16" class="time">15:16</a>
f13I started work on that, got distracted<a href="#t15:16" class="time">15:16</a>
jwbf13, and even if bohdi isn't ready i think we need a way for people to request tagging for updates...<a href="#t15:17" class="time">15:17</a>
f13once we branch, the builds will automatically get tagged with the update candidate tag.<a href="#t15:17" class="time">15:17</a>
jwbupdate candidate == updates testing?<a href="#t15:18" class="time">15:18</a>
jwbor pre-updates testing?<a href="#t15:18" class="time">15:18</a>
f13and dist-fc7-updates-candidate tag should be unlocked and will inherit from dist-fc7<a href="#t15:18" class="time">15:18</a>
f13both pre-updates teating and updates-testing<a href="#t15:18" class="time">15:18</a>
jwbso anything tagged with update candidate will show up in updates-testing on the mirrors?<a href="#t15:18" class="time">15:18</a>
f13the current workflow is that a package exsts in dist-fc7-updates-candidate, maintainer requests update through bodhi, it goes out into -testing.  Only when it goes from -testing to -final would it move from dist-fc7-updates-candidate to dist-fc7-updates (and would populate the buildroot)<a href="#t15:19" class="time">15:19</a>
f13jwb: only if they go through bodhi<a href="#t15:19" class="time">15:19</a>
jwbok<a href="#t15:19" class="time">15:19</a>
nirikso whats the path for new packages that were added in this freeze time? they go to updates for f7? or ?<a href="#t15:20" class="time">15:20</a>
f13nirik: after Thursday, new packages will get a devel/ branch and be tagged with dist-f8<a href="#t15:20" class="time">15:20</a>
f13nirik: they can request an F-7 branch, and a build from there will go into the updates pool<a href="#t15:20" class="time">15:20</a>
* jwb hopes f13 is logging this<a href="#t15:21" class="time">15:21</a>
f13so they'd have to request an 'update' through bodhi.  THis is good as users get new package notifications as well as update notifications.<a href="#t15:21" class="time">15:21</a>
nirikso they will need to specially request the f7 branch? that might end up being a lot of packages.<a href="#t15:21" class="time">15:21</a>
warrenOnly four packages in F7 with broken deps that aren't kmod.<a href="#t15:22" class="time">15:22</a>
f13nirik: no different than requesting the FC-6 branch<a href="#t15:22" class="time">15:22</a>
* warren sending mail to owners.<a href="#t15:22" class="time">15:22</a>
f13nirik: it would be the standard new package process<a href="#t15:22" class="time">15:22</a>
f13nirik: you get devel/ for free, you ask for what other branches you want.<a href="#t15:22" class="time">15:22</a>
nirikyeah, but things added in this freeze period might have, fc5/fc6/devel, but no f7... which breaks upgrade paths...<a href="#t15:22" class="time">15:22</a>
jwbnirik, that's already the case<a href="#t15:23" class="time">15:23</a>
jwbtoday.  now<a href="#t15:23" class="time">15:23</a>
f13why would a user ask for FC-5, FC-6, but not F-7 branch?<a href="#t15:23" class="time">15:23</a>
f13and if they did, why would a cvs admin actually grant that request?<a href="#t15:23" class="time">15:23</a>
niriksure, but once devel is final f7, there will be a hell of a lot more users hitting it.<a href="#t15:23" class="time">15:23</a>
jwbnirik, devel already _is_ final f7<a href="#t15:23" class="time">15:23</a>
jwbright NOW<a href="#t15:24" class="time">15:24</a>
f13nirik: I think one of us is confusing the other.<a href="#t15:24" class="time">15:24</a>
nirikyeah... likely me.<a href="#t15:24" class="time">15:24</a>
nirikwhat I am thinking of is this:<a href="#t15:24" class="time">15:24</a>
jwbf13, users don't ask for fc-5 or fc-6.  they just update and it gets pushed<a href="#t15:24" class="time">15:24</a>
niriknew packge. They request fc5/fc6/devel right now.<a href="#t15:24" class="time">15:24</a>
f13jwb: we're talking about new packages.<a href="#t15:24" class="time">15:24</a>
jwbf13, ah<a href="#t15:24" class="time">15:24</a>
nirikthey build for fc5/fc6/devel.<a href="#t15:24" class="time">15:24</a>
f13nirik: if they ask _right_ _now_ then yes, they have to ask for the build to be tagged for f7-final.<a href="#t15:25" class="time">15:25</a>
nirikthey don't request the new package for f7 because they don't know about doing that<a href="#t15:25" class="time">15:25</a>
f13nirik: if they ask after thursday, devel is now f8, and they'd have to ask for FC-5, FC-6, and F-7<a href="#t15:25" class="time">15:25</a>
nirikbranch happens for f7... does there package have a f7 branch?<a href="#t15:25" class="time">15:25</a>
f13nirik: yes, it would.<a href="#t15:25" class="time">15:25</a>
jwbnirik, yes.  requests are only for tags<a href="#t15:25" class="time">15:25</a>
f13nirik: at branch time, all active devel/ packages get branched.<a href="#t15:25" class="time">15:25</a>
f13this hasn't changed.<a href="#t15:26" class="time">15:26</a>
* jwb wonders if we're talking about rel-eng requests or cvsadmin requests<a href="#t15:26" class="time">15:26</a>
nirikok, so then their package has a fc5/fc6 and devel (now f8) version, right? what about f7?<a href="#t15:26" class="time">15:26</a>
jwbnow<a href="#t15:26" class="time">15:26</a>
jwber, no<a href="#t15:26" class="time">15:26</a>
jwbCVS: cvsadmin request creates fc5/fc6/devel branches<a href="#t15:26" class="time">15:26</a>
jwbbranching happens thursday<a href="#t15:26" class="time">15:26</a>
jwbnow package has fc5/fc6/fc7/devel<a href="#t15:27" class="time">15:27</a>
nirikok, and what packages do they have in the repo then?<a href="#t15:27" class="time">15:27</a>
jwbyep, getting to that<a href="#t15:27" class="time">15:27</a>
f13which repo?<a href="#t15:27" class="time">15:27</a>
nirikthe cvs side makes sense to me just fine. I think the tags are confusing me.<a href="#t15:27" class="time">15:27</a>
jwbplague: user builds.  fc-5/fc-6 have packages in extras repo<a href="#t15:27" class="time">15:27</a>
nirikright<a href="#t15:27" class="time">15:27</a>
jwbkoji: user builds.  package is in dist-fc7.  if they want it in f7-final, they email rel-eng and request it<a href="#t15:28" class="time">15:28</a>
nirikok, say they did not<a href="#t15:28" class="time">15:28</a>
f13then the build just sits there.<a href="#t15:28" class="time">15:28</a>
jwbif they don't email, it gets inherited to dist-f8, and the package is not available in a f7 repo<a href="#t15:28" class="time">15:28</a>
nirikok, that is the case I am talking about.<a href="#t15:28" class="time">15:28</a>
f13and will be picked up once rawhide starts composing from dist-f8<a href="#t15:28" class="time">15:28</a>
jwbnirik, that's true today<a href="#t15:28" class="time">15:28</a>
nirikend user on fc6 installs packageA. Upgrades to f7, and packageA isn't available anymore.<a href="#t15:29" class="time">15:29</a>
f13nirik: this exists today, which is why so many mails have been sent about requesting tags for yoru builds.<a href="#t15:29" class="time">15:29</a>
jwbthe broken upgrade paths thing should catch that and send them nag-mail<a href="#t15:29" class="time">15:29</a>
nirikyeah, true... ok.<a href="#t15:29" class="time">15:29</a>
nirikdo we have a broken upgrade path thing we can run now? the extras one was in the extras push scripts. The core one was part of brew?<a href="#t15:30" class="time">15:30</a>
jwbsilence<a href="#t15:32" class="time">15:32</a>
jwbi think that means no?<a href="#t15:32" class="time">15:32</a>
jwb:)<a href="#t15:32" class="time">15:32</a>
f13sorry, went to go get a soda<a href="#t15:33" class="time">15:33</a>
f13we're going to have to port the extras one over and make it part of the rawhide compose<a href="#t15:33" class="time">15:33</a>
f13I just don't know who's going to be that "we"<a href="#t15:33" class="time">15:33</a>
jwbf13, what do you need access to to test it?<a href="#t15:34" class="time">15:34</a>
nirikmschwent mostly wrote it I think... don't know if he would be willing to work on it or not. He sounded kinda burned out in his last few emails.<a href="#t15:34" class="time">15:34</a>
jwbhe's a bit pissed at the moment<a href="#t15:34" class="time">15:34</a>
nirikyeah. Which is sad. :(<a href="#t15:35" class="time">15:35</a>
f13jwb: access to the script, and uh, not sure what it looks at to compare.<a href="#t15:36" class="time">15:36</a>
jwbf13, i thought it ran right on the repos at push time<a href="#t15:37" class="time">15:37</a>
f13it could, I have no idea<a href="#t15:38" class="time">15:38</a>
* jwb goes looking<a href="#t15:39" class="time">15:39</a>
nirik<a href=""></a><a href="#t15:40" class="time">15:40</a>
jwbthat looks like it should already work?<a href="#t15:41" class="time">15:41</a>
nirikyeah, it just might.<a href="#t15:41" class="time">15:41</a>
jwbf13, think you can run that inside the colo and see what the results are?<a href="#t15:42" class="time">15:42</a>
jwbf13, given that would be fastest...<a href="#t15:42" class="time">15:42</a>
f13might be able to<a href="#t15:42" class="time">15:42</a>
nirikI can run it here too, but yeah, slower<a href="#t15:42" class="time">15:42</a>
f13it was changed 3 hours ago, maybe somebody is already running it?<a href="#t15:44" class="time">15:44</a>
jwbyou'd have to ask ville<a href="#t15:44" class="time">15:44</a>
jwbcan't hurt though<a href="#t15:45" class="time">15:45</a>
* nirik tries a run here. Hopefully not mailing people... ;) <a href="#t15:48" class="time">15:48</a>

Generated by 2.3 by Marius Gedminas - find it at!