From Fedora Project Wiki
Fedora Release Engineering Meeting :: Monday 14-MAY-07
Rawhide
- 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.
- https://www.redhat.com/archives/fedora-extras-commits/2007-May/msg02800.html
- 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
- http://fedoraproject.org/wiki/QA/ReleaseCriteria provides guidance on release blockers
- DECISION (UNANIMOUS):
- 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
EULA
- EULA only available online; not in the distro
- http://fedoraproject.org/wiki/Legal/Licenses/EULA
IRC Transcript
 f13 changed the topic of #fedora-meeting to: Fedora Release Meeting: Rawhide | <a href="#t12:58" class="time">12:58</a> | |
| f13 | meeting in just a couple minutes | <a href="#t12:58" class="time">12:58</a> |
|---|---|---|
| f13 | poelcat: hi, are you here? | <a href="#t12:58" class="time">12:58</a> |
| poelcat | f13: 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> | |
| f13 | alright, lets get a rollcall. | <a href="#t13:00" class="time">13:00</a> |
| f13 | jwb: notting, jeremy, rdieter, warren, wwoods: ping? | <a href="#t13:00" class="time">13:00</a> |
| f13 | mmcgrath: 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> | |
| warren | I'm here it seems. | <a href="#t13:01" class="time">13:01</a> |
| warren | jeremy, plumber will be joining us? =) | <a href="#t13:01" class="time">13:01</a> |
| f13 | Ok, well the rest will come in or notice this channel in a few moments. | <a href="#t13:02" class="time">13:02</a> |
| f13 | first 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> |
| f13 | notting: 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> |
| jeremy | yes, 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> |
| poelcat | donkey? | <a href="#t13:05" class="time">13:05</a> |
| * f13 tries the sms approach | <a href="#t13:08" class="time">13:08</a> | |
| f13 | hrm. | <a href="#t13:09" class="time">13:09</a> |
| warren | f13, tried his desk phone? | <a href="#t13:09" class="time">13:09</a> |
| f13 | warren: he's working from home. Helping wife take care of new baby. | <a href="#t13:09" class="time">13:09</a> |
| f13 | well, until he gets here. | <a href="#t13:10" class="time">13:10</a> |
| f13 | mmcgrath: what's our storage story like today? | <a href="#t13:10" class="time">13:10</a> |
| wwoods | yarg, 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> | |
| mmcgrath | hmm | <a href="#t13:11" class="time">13:11</a> |
| * mmcgrath looks it up | <a href="#t13:11" class="time">13:11</a> | |
| mmcgrath | f13: 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> |
| mmcgrath | f13: its filling up but we're ok. | <a href="#t13:12" class="time">13:12</a> |
| f13 | ok. | <a href="#t13:12" class="time">13:12</a> |
| f13 | mmcgrath: 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> |
| f13 | compose 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> | |
| f13 | 30 minutes for one createrepo. | <a href="#t13:13" class="time">13:13</a> |
| f13 | on hte fast side. | <a href="#t13:14" class="time">13:14</a> |
| f13 | and there goes notting :( | <a href="#t13:14" class="time">13:14</a> |
| f13 | notting: 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> | |
| notting | ok, so | <a href="#t13:16" class="time">13:16</a> |
| notting | it involved: | <a href="#t13:16" class="time">13:16</a> |
| notting | 1) running mash by hand (this can be scripted) | <a href="#t13:16" class="time">13:16</a> |
| notting | 2) 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> |
| notting | 3) 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> |
| wwoods | we 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> |
| f13 | sortof. | <a href="#t13:17" class="time">13:17</a> |
| f13 | there is more to it than just teaching koji how to do a runroot task. | <a href="#t13:17" class="time">13:17</a> |
| notting | 4) 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> |
| notting | the 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> |
| notting | mdomsch: 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> |
| notting | i 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> |
| jeremy | notting: ssh keys! | <a href="#t13:20" class="time">13:20</a> |
| jeremy | followed by 'ssh host somecommandshere' | <a href="#t13:20" class="time">13:20</a> |
| notting | jeremy: still... randomly saying 'hey, i'll abuse that builder' is kinda rude | <a href="#t13:21" class="time">13:21</a> |
| notting | also, to run pungi we'd need to toss a modified config at it | <a href="#t13:21" class="time">13:21</a> |
| notting | which is sort of messy through a chroot | <a href="#t13:21" class="time">13:21</a> |
| f13 | notting: yeah, we need koji runroot capability | <a href="#t13:21" class="time">13:21</a> |
| notting | f13: 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> |
| f13 | notting: configs can be stored in $SCM and pulled. | <a href="#t13:21" class="time">13:21</a> |
| f13 | notting: mostly because said createrepo used to live in buildinstall itself. | <a href="#t13:22" class="time">13:22</a> |
| f13 | this stage stuff was a patch I probably shouldn't have taken in. | <a href="#t13:22" class="time">13:22</a> |
| f13 | obviously it's not really ready to be broken up in stages like that. | <a href="#t13:22" class="time">13:22</a> |
| notting | please don't take it out! sort of need it for rawhide | <a href="#t13:22" class="time">13:22</a> |
| f13 | I know. | <a href="#t13:23" class="time">13:23</a> |
| f13 | although | <a href="#t13:23" class="time">13:23</a> |
| f13 | in 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> |
| notting | the rpm gathering doesn't need to be sent off - that would make it slower | <a href="#t13:24" class="time">13:24</a> |
| f13 | notting: so we could fairly easily automate rawhide, if it wasn't installable | <a href="#t13:24" class="time">13:24</a> |
| notting | f13: yes | <a href="#t13:24" class="time">13:24</a> |
| notting | f13: 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> |
| f13 | nod | <a href="#t13:25" class="time">13:25</a> |
| f13 | perhaps 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> |
| notting | ok, 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> |
| f13 | nod, that's what I was hoping for | <a href="#t13:28" class="time">13:28</a> |
| f13 | rsync shouldn't be nearly as bad next time around. | <a href="#t13:28" class="time">13:28</a> |
| notting | oh, all the extras debuginfo stuff *should* be imported now. | <a href="#t13:28" class="time">13:28</a> |
| f13 | goot. | <a href="#t13:28" class="time">13:28</a> |
| f13 | well that will make it slower 9: | <a href="#t13:28" class="time">13:28</a> |
| notting | random 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> |
| notting | but the db ends up ok | <a href="#t13:29" class="time">13:29</a> |
| f13 | anything else on Rawhide? | <a href="#t13:30" class="time">13:30</a> |
| notting | just fyi: | <a href="#t13:30" class="time">13:30</a> |
| notting | i started that compose at ~3PM on friday | <a href="#t13:30" class="time">13:30</a> |
| wwoods | oh - 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> |
| notting | it finished pushing to the mirror master at ~10AM on saturday | <a href="#t13:30" class="time">13:30</a> |
| jeremy | wwoods: they need to get the package builds for those arches going | <a href="#t13:31" class="time">13:31</a> |
| notting | f13 (and other interested parties) - please chime in on <a href="http://fedoraproject.org/wiki/Infrastructure/RFR/Compose">http://fedoraproject.org/wiki/Infrastructure/RFR/Compose</a> | <a href="#t13:31" class="time">13:31</a> |
| wwoods | I 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> |
| f13 | wwoods: lets talk about that in a more internal setting. | <a href="#t13:32" class="time">13:32</a> |
| f13 | wwoods: but simple answer, Fedora will not be building/composing rawhide for those arches. | <a href="#t13:32" class="time">13:32</a> |
| f13 | and Red Hat won't be doing it for Fedora either. | <a href="#t13:32" class="time">13:32</a> |
| wwoods | right, 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> |
| f13 | wwoods: correct, they should have their own koji to mash from (: | <a href="#t13:33" class="time">13:33</a> |
| jeremy | wwoods: 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> |
| wwoods | in 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> |
| f13 | wwoods: this is all part of our grand secondary arch plans, which spot-food is leading. | <a href="#t13:33" class="time">13:33</a> |
| wwoods | gotcha. | <a href="#t13:33" class="time">13:33</a> |
| f13 | ok, moving on. | <a href="#t13:35" class="time">13:35</a> |
| f13 changed the topic of #fedora-meeting to: Freeze on Thursday? | <a href="#t13:35" class="time">13:35</a> | |
| f13 | we agreed last week to revisit this week. | <a href="#t13:35" class="time">13:35</a> |
| f13 | although given we've only had one rawhide, perhaps we need to revisit on Wed? | <a href="#t13:35" class="time">13:35</a> |
| wwoods | my 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> |
| wwoods | so if that's not the determining factor.. what is? | <a href="#t13:37" class="time">13:37</a> |
| f13 | wwoods: are we making progress on them? | <a href="#t13:38" class="time">13:38</a> |
| mmcgrath | f13: 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> |
| f13 | mmcgrath: don't think so. | <a href="#t13:38" class="time">13:38</a> |
| wwoods | at 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> |
| warren | Without 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> |
| wwoods | f13: yeah, some, but there's some huge scary ones, like anaconda's handling of mdraid | <a href="#t13:38" class="time">13:38</a> |
| mmcgrath | k | <a href="#t13:38" class="time">13:38</a> |
| f13 | wwoods: 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> | |
| f13 | warren: we've had one rawhide... (: | <a href="#t13:38" class="time">13:38</a> |
| wwoods | ahhh. 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> |
| notting | wwoods: what sort of status do we have on the updated rawhide? anything go completely bang? | <a href="#t13:40" class="time">13:40</a> |
| warren | We need to be testing install of that, and testing upgrade of previous Fedora... | <a href="#t13:40" class="time">13:40</a> |
| wwoods | chatter seems mostly positive, although emacs exploded | <a href="#t13:40" class="time">13:40</a> |
| f13 | wwoods: 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> |
| wwoods | so we're talking about the freeze *and* the branchpoint. ok. | <a href="#t13:41" class="time">13:41</a> |
| f13 | yeah, they're tied together | <a href="#t13:41" class="time">13:41</a> |
| wwoods | gotcha. | <a href="#t13:41" class="time">13:41</a> |
| warren | In order to reduce confusion, should we also STOP addition of "extras" packages at that point? | <a href="#t13:42" class="time">13:42</a> |
| warren | at least until gold is cut | <a href="#t13:42" class="time">13:42</a> |
| f13 | warren: they could be added to devel/, which would build to dist-f8 | <a href="#t13:42" class="time">13:42</a> |
| warren | oh | <a href="#t13:42" class="time">13:42</a> |
| warren | ok | <a href="#t13:42" class="time">13:42</a> |
| f13 | warren: we'd just not respond to any FC-7 branch requests for new packages. | <a href="#t13:42" class="time">13:42</a> |
| warren | k | <a href="#t13:43" class="time">13:43</a> |
| f13 | or even if we did, they'd get tagged dist dist-fc7-updates-candidate | <a href="#t13:43" class="time">13:43</a> |
| notting | warren: 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> |
| wwoods | there'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> |
| warren | f13, well, branch requests can go through, we just wont tag? | <a href="#t13:43" class="time">13:43</a> |
| warren | wwoods, what is the hal issue? | <a href="#t13:43" class="time">13:43</a> |
| warren | beagle we really should turn off prior to the freeze. | <a href="#t13:43" class="time">13:43</a> |
| f13 | warren: right, we would direct new packages to updates, not the final tree. | <a href="#t13:43" class="time">13:43</a> |
| jeremy | wwoods: then we should go through them one by one now | <a href="#t13:43" class="time">13:43</a> |
| wwoods | warren: newest hal screws up quirks for a bunch of machines - symptoms are mostly resume regressions | <a href="#t13:44" class="time">13:44</a> |
| wwoods | beagle is.. beagle. the redhat.com 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> | |
| wwoods | newest 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> |
| notting | wwoods: eh, whaaa? (re: beagle) | <a href="#t13:45" class="time">13:45</a> |
| notting | why is it suddenly that drastic now? | <a href="#t13:45" class="time">13:45</a> |
| wwoods | notting: yes, filed under "things that would have been nice to know before the feature freeze" | <a href="#t13:45" class="time">13:45</a> |
| f13 | notting: 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> |
| jeremy | wwoods: 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> |
| warren | wireless-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> | |
| f13 | lets go back to beagle. | <a href="#t13:45" class="time">13:45</a> |
| wwoods | starting with beagle, then. | <a href="#t13:46" class="time">13:46</a> |
| wwoods | bug #217031 | <a href="#t13:46" class="time">13:46</a> |
| wwoods | basically, 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> |
| f13 | oh here's the fun thing. | <a href="#t13:47" class="time">13:47</a> |
| f13 | the maintainer already axed it from comps. :( | <a href="#t13:47" class="time">13:47</a> |
| wwoods | one 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> |
| wwoods | it stands to reason that we should at least *consider* removing it | <a href="#t13:47" class="time">13:47</a> |
| wwoods | yeah, especially since the maintainer has attempted to remove it himself. | <a href="#t13:47" class="time">13:47</a> |
| jeremy | f13: it's not like a comps change is impossible to revert | <a href="#t13:48" class="time">13:48</a> |
| f13 | no, it's not, just providing a data point. | <a href="#t13:48" class="time">13:48</a> |
| warren | Is beagle the only mono thing that is installed by default? | <a href="#t13:48" class="time">13:48</a> |
| f13 | warren: tomboy | <a href="#t13:49" class="time">13:49</a> |
| jeremy | warren: I think tomboy gets installed by default also | <a href="#t13:49" class="time">13:49</a> |
| f13 | f-spot | <a href="#t13:49" class="time">13:49</a> |
| warren | default? | <a href="#t13:49" class="time">13:49</a> |
| warren | oh | <a href="#t13:49" class="time">13:49</a> |
| f13 | not sure if those are defaults actaully | <a href="#t13:49" class="time">13:49</a> |
| jeremy | tomboy is default | <a href="#t13:49" class="time">13:49</a> |
| warren | well, 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> |
| f13 | tomboy is default, f-spot is optional. | <a href="#t13:49" class="time">13:49</a> |
| wwoods | beagle is the only one that's running by default | <a href="#t13:49" class="time">13:49</a> |
| jeremy | wwoods: yes | <a href="#t13:49" class="time">13:49</a> |
| wwoods | which means every fedora system automatically has the mono interpreter stuff running | <a href="#t13:49" class="time">13:49</a> |
| notting | f-spot is optional | <a href="#t13:49" class="time">13:49</a> |
| notting | which means it's not in prime, if i understand right | <a href="#t13:50" class="time">13:50</a> |
| notting | or fedora, or whatever we're calling it ;) | <a href="#t13:50" class="time">13:50</a> |
| wwoods | not 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> |
| warren | Do 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> |
| f13 | as 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> |
| notting | f13: 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> | |
| wwoods | optional? they were previously defaults | <a href="#t13:50" class="time">13:50</a> |
| wwoods | is that alexl's change? | <a href="#t13:50" class="time">13:50</a> |
| f13 | warren: maintainer changed comps. | <a href="#t13:50" class="time">13:50</a> |
| f13 | er wwoods | <a href="#t13:50" class="time">13:50</a> |
| f13 | notting: unless they get pulled in via some other deps, yes. | <a href="#t13:51" class="time">13:51</a> |
| wwoods | ah, I thought you were saying they were optional prior to his change | <a href="#t13:51" class="time">13:51</a> |
| f13 | notting: 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> |
| warren | how is this difficult? What is wrong with simply deciding not to install it by default? | <a href="#t13:51" class="time">13:51</a> |
| notting | jeremy: is commitspam for comps working for you? | <a href="#t13:51" class="time">13:51</a> |
| f13 | warren: 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> |
| f13 | quaid: stickster: know if there is any beagle content in the release notes? | <a href="#t13:52" class="time">13:52</a> |
| wwoods | so, wait, it's not even going to be on the *media* anymore? | <a href="#t13:52" class="time">13:52</a> |
| jeremy | notting: only via fedora-extras-commits | <a href="#t13:52" class="time">13:52</a> |
| wwoods | won't that be.. bad.. for people upgrading from fc6? | <a href="#t13:52" class="time">13:52</a> |
| jeremy | wwoods: 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> |
| f13 | wwoods: 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> |
| stickster | f13: 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> |
| stickster | f13: nope, none to date in our XML in CVS | <a href="#t13:53" class="time">13:53</a> |
| wwoods | it'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> | |
| wwoods | but, ugh. the current implementation is just.. not nearly ready | <a href="#t13:54" class="time">13:54</a> |
| notting | well ,it's ready enough that we've shipped it by default for how long? | <a href="#t13:54" class="time">13:54</a> |
| f13 | wwoods: tried the other search thingy? | <a href="#t13:54" class="time">13:54</a> |
| wwoods | anyway, 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> |
| nirik | tracker any better? | <a href="#t13:55" class="time">13:55</a> |
| notting | jeremy: should be fixed now | <a href="#t13:55" class="time">13:55</a> |
| wwoods | f13: 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> |
| wwoods | that's the big win for me | <a href="#t13:55" class="time">13:55</a> |
| stickster | nirik: better on this particular axis (battery drain), but covers fewer formats | <a href="#t13:55" class="time">13:55</a> |
| wwoods | although it's way better at, for instance, finding tagged media files | <a href="#t13:55" class="time">13:55</a> |
| wwoods | beagle doesn't index id3 / ogg tags | <a href="#t13:55" class="time">13:55</a> |
| stickster | true dat | <a href="#t13:55" class="time">13:55</a> |
| notting | which 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> |
| f13 | I guess we should vote on this. | <a href="#t13:55" class="time">13:55</a> |
| f13 | Proposal: 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> |
| warren | err.. +1 | <a href="#t13:56" class="time">13:56</a> |
| notting | is there another option? | <a href="#t13:56" class="time">13:56</a> |
| f13 | notting: force it to be default again. | <a href="#t13:56" class="time">13:56</a> |
| wwoods | force it back to being default, get someone else to fix 217031 for F7 | <a href="#t13:56" class="time">13:56</a> |
| jeremy | notting: 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> |
| rdieter | proposal: +1 | <a href="#t13:57" class="time">13:57</a> |
| wwoods | we 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> |
| notting | wwoods: 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> |
| wwoods | will do. | <a href="#t13:58" class="time">13:58</a> |
| * jwb is late | <a href="#t13:58" class="time">13:58</a> | |
| wwoods | good lord. I can't even load beagle-project.org | <a href="#t13:59" class="time">13:59</a> |
| rdieter | wwoods: for f8, include <a href="http://strigi.sourceforge.net/">http://strigi.sourceforge.net/</a> for evaluation too. | <a href="#t13:59" class="time">13:59</a> |
| wwoods | okay, so on the off chance that removing beagle causes a ripple effect | <a href="#t13:59" class="time">13:59</a> |
| nirik | and recoll | <a href="#t13:59" class="time">13:59</a> |
| wwoods | squash the ripple bugs, or revert the change & go back to beagle-default? | <a href="#t13:59" class="time">13:59</a> |
| f13 | depends 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> | |
| jeremy | well, 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> |
| mdomsch | notting, --delay-updates :-( | <a href="#t14:01" class="time">14:01</a> |
| wwoods | so actually, that bug is fixed in beagle-0.2.17 | <a href="#t14:01" class="time">14:01</a> |
| notting | mdomsch: rhel 2.1 :( | <a href="#t14:01" class="time">14:01</a> |
| wwoods | but 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> |
| notting | wwoods: someone claimed that 0.2.17 still failed for them | <a href="#t14:02" class="time">14:02</a> |
| f13 | anyway, I think the vote passed, so we have a plan for now. | <a href="#t14:02" class="time">14:02</a> |
| f13 | I'll respond to Alex's post | <a href="#t14:02" class="time">14:02</a> |
| f13 | wwoods: whats the next item on your hit list? | <a href="#t14:02" class="time">14:02</a> |
| wwoods | next let's do wireless-tools, which is pretty straightforward | <a href="#t14:03" class="time">14:03</a> |
| nirik | checkin on wireless tools this morning. | <a href="#t14:03" class="time">14:03</a> |
| nirik | <a href="https://www.redhat.com/archives/fedora-extras-commits/2007-May/msg02800.html">https://www.redhat.com/archives/fedora-extras-commits/2007-May/msg02800.html</a> | <a href="#t14:03" class="time">14:03</a> |
| mdomsch | notting, what's it going to take to upgrade that RPM? | <a href="#t14:03" class="time">14:03</a> |
| wwoods | nirik: oh nice. have you tried it? | <a href="#t14:03" class="time">14:03</a> |
| nirik | not yet, but I can real quick. | <a href="#t14:03" class="time">14:03</a> |
| nirik | except it's not built. ;( | <a href="#t14:03" class="time">14:03</a> |
| wwoods | this is bug #238657 | <a href="#t14:03" class="time">14:03</a> |
| notting | mdomsch: 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> |
| f13 | caillon is stuck in airport hell. | <a href="#t14:05" class="time">14:05</a> |
| f13 | won't be back until Wed~ | <a href="#t14:05" class="time">14:05</a> |
| wwoods | wireless-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> |
| wwoods | which 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> |
| f13 | he'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> |
| f13 | well, anybody can build a test srpm and build it that way | <a href="#t14:05" class="time">14:05</a> |
| warren | Proposal: Just back it out and build -3. | <a href="#t14:05" class="time">14:05</a> |
| f13 | warren: 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> | |
| wwoods | I think nirik's building the current -3 (revised patch) right now | <a href="#t14:06" class="time">14:06</a> |
| f13 | nirik: are you building locally? | <a href="#t14:06" class="time">14:06</a> |
| warren | f13, yes | <a href="#t14:06" class="time">14:06</a> |
| nirik | yeah, just locally. | <a href="#t14:06" class="time">14:06</a> |
| nirik | seems to work ok. | <a href="#t14:06" class="time">14:06</a> |
| warren | f13, I discovered and reported the breakage and spent hours with caillon trying to fix it | <a href="#t14:06" class="time">14:06</a> |
| nirik | I can still scan fine. | <a href="#t14:06" class="time">14:06</a> |
| warren | f13, we were unsuccessful | <a href="#t14:06" class="time">14:06</a> |
| f13 | warren: including the patch he has in CVS? | <a href="#t14:06" class="time">14:06</a> |
| warren | f13, yes. | <a href="#t14:06" class="time">14:06</a> |
| nirik | warren: looks like he backed out lots of the former -2 patch... | <a href="#t14:07" class="time">14:07</a> |
| nirik | <a href="https://www.redhat.com/archives/fedora-extras-commits/2007-May/msg02800.html">https://www.redhat.com/archives/fedora-extras-commits/2007-May/msg02800.html</a> | <a href="#t14:07" class="time">14:07</a> |
| warren | why didn't he build it? | <a href="#t14:07" class="time">14:07</a> |
| f13 | warren: probably because he's stuck in an airport and the tubes suck. | <a href="#t14:07" class="time">14:07</a> |
| nirik | dunno. It works here tho, and -2 segfaulted on me | <a href="#t14:07" class="time">14:07</a> |
| warren | nirik, latest CVS you mean? | <a href="#t14:07" class="time">14:07</a> |
| f13 | I'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> |
| nirik | warren: yes, -3 works here... built locally from cvs. | <a href="#t14:08" class="time">14:08</a> |
| notting | f13: stuck getting out of SD? | <a href="#t14:08" class="time">14:08</a> |
| f13 | <a href="http://koji.fedoraproject.org/koji/taskinfo?taskID=7892">http://koji.fedoraproject.org/koji/taskinfo?taskID=7892</a> | <a href="#t14:08" class="time">14:08</a> |
| f13 | notting: yeah | <a href="#t14:08" class="time">14:08</a> |
| warren | f13, 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> |
| warren | f13, 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> |
| f13 | warren: scratch build does all arches | <a href="#t14:09" class="time">14:09</a> |
| warren | f13, 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="http://www.scrye.com/~kevin/wireless-tools-28-3.fc7.x86_64.rpm">http://www.scrye.com/~kevin/wireless-tools-28-3.fc7.x86_64.rpm</a> if anyone here wants my locally built one to test real quick. | <a href="#t14:09" class="time">14:09</a> |
| f13 | warren: 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> |
| jeremy | the patch doesn't look insane; I can definitely see it fixing 64bit problems | <a href="#t14:10" class="time">14:10</a> |
| warren | f13, 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="http://koji.fedoraproject.org/koji/getfile?taskID=7894&name=wireless-tools-28-3.fc7.x86_64.rpm">http://koji.fedoraproject.org/koji/getfile?taskID=7894&name=wireless-tools-28-3.fc7.x86_64.rpm</a> | <a href="#t14:10" class="time">14:10</a> |
| wwoods | I'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> |
| jeremy | wwoods: +1 | <a href="#t14:10" class="time">14:10</a> |
| warren | I 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> |
| warren | If it explodes just revert fully in -4. | <a href="#t14:11" class="time">14:11</a> |
| jeremy | warren/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> |
| wwoods | we'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> |
| f13 | right | <a href="#t14:11" class="time">14:11</a> |
| warren | jeremy, yeah, I'll drive, I already spent hours on this. | <a href="#t14:11" class="time">14:11</a> |
| f13 | it would be far quicker to get people to test these scratch built rpms. | <a href="#t14:11" class="time">14:11</a> |
| warren | f13, why not both? | <a href="#t14:11" class="time">14:11</a> |
| jeremy | okay. we have a plan, let's move on :) | <a href="#t14:11" class="time">14:11</a> |
| f13 | since the build is already done. | <a href="#t14:11" class="time">14:11</a> |
| warren | just tag it and do it both ways. | <a href="#t14:12" class="time">14:12</a> |
| f13 | warren: 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> |
| f13 | can't tag a scratch build. | <a href="#t14:12" class="time">14:12</a> |
| wwoods | next 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> |
| jeremy | wwoods: item #3... hal stuffs | <a href="#t14:12" class="time">14:12</a> |
| jeremy | davidz 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> | |
| wwoods | basically 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> |
| jeremy | and I think he's traveling this week :-/ | <a href="#t14:13" class="time">14:13</a> |
| wwoods | but broke it for others (my pitiable t43) | <a href="#t14:13" class="time">14:13</a> |
| wwoods | I'm actually not sure -6 was the one that fixed davej's laptop | <a href="#t14:13" class="time">14:13</a> |
| warren | wwoods, my T60 was suspending/resuming fine both before and after. | <a href="#t14:13" class="time">14:13</a> |
| wwoods | warren: 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> | |
| wwoods | that answers that. but it definitely breaks my t43 - see 238792 | <a href="#t14:14" class="time">14:14</a> |
| jeremy | wwoods: 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> |
| wwoods | jeremy: 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> |
| f13 | quirks being passed now seems like a feature | <a href="#t14:14" class="time">14:14</a> |
| wwoods | definitely | <a href="#t14:14" class="time">14:14</a> |
| jeremy | f13: bugfix | <a href="#t14:14" class="time">14:14</a> |
| f13 | jeremy: where bug is the feature isn't there? | <a href="#t14:14" class="time">14:14</a> |
| jeremy | f13: 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> |
| wwoods | okay, 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> |
| jeremy | f13: 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> |
| f13 | jeremy: 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> |
| f13 | ah. | <a href="#t14:15" class="time">14:15</a> |
| wwoods | the final big pre-freeze problem I want to discuss is mdraid handling | <a href="#t14:15" class="time">14:15</a> |
| f13 | that 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> |
| jeremy | wwoods: for the hal stuff, I'll try to get hughsie to take a look | <a href="#t14:16" class="time">14:16</a> |
| wwoods | jeremy: that would be fantastic, thank you | <a href="#t14:16" class="time">14:16</a> |
| f13 | wwoods: davidz won't be back until the 20th. | <a href="#t14:16" class="time">14:16</a> |
| jeremy | f13: we've seen some of them; suspend/resume is doom :-/ | <a href="#t14:16" class="time">14:16</a> |
| jeremy | anyway, mdraid | <a href="#t14:16" class="time">14:16</a> |
| wwoods | so 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> |
| wwoods | the 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> |
| wwoods | the ioctl that anaconda uses | <a href="#t14:17" class="time">14:17</a> |
| wwoods | and the stuff that mkinitrd uses | <a href="#t14:17" class="time">14:17</a> |
| notting | mkinitrd had a fix to use mdadm go in | <a href="#t14:17" class="time">14:17</a> |
| wwoods | they 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> |
| wwoods | which obviously explodes when we change all hdX to sdX | <a href="#t14:18" class="time">14:18</a> |
| wwoods | notting: yeah, that fix is in mkinitrd (but not tagged for F7) | <a href="#t14:18" class="time">14:18</a> |
| wwoods | anaconda 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> |
| wwoods | but anaconda just calls the autorun ioctl directly, as far as I can tell | <a href="#t14:19" class="time">14:19</a> |
| notting | this 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> |
| wwoods | notting: yeah - they're referenced by ide name in the @#!^!@^ superblock | <a href="#t14:19" class="time">14:19</a> |
| wwoods | I 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> |
| wwoods | mdadm reads the newer metadata, which uses partition uuids to find 'em | <a href="#t14:20" class="time">14:20</a> |
| wwoods | so mdadm works | <a href="#t14:20" class="time">14:20</a> |
| f13 | this sounds a lot like pjones land here. | <a href="#t14:21" class="time">14:21</a> |
| wwoods | yeah, 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> |
| jeremy | erg. indeed the major/minor is used there | <a href="#t14:22" class="time">14:22</a> |
| f13 | did 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> | |
| wwoods | jeremy: yeah. facepalm. | <a href="#t14:22" class="time">14:22</a> |
| wwoods | this 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> |
| jeremy | the anaconda change is going to be ... less straight-forward, though :-/ | <a href="#t14:22" class="time">14:22</a> |
| wwoods | jeremy: 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> |
| jeremy | wwoods: 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> |
| wwoods | I 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> |
| notting | really really really could use fixed | <a href="#t14:25" class="time">14:25</a> |
| jeremy | wwoods: the workaround won't work | <a href="#t14:25" class="time">14:25</a> |
| wwoods | really 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> | |
| wwoods | I'm sad that we all missed it or forgot about it | <a href="#t14:25" class="time">14:25</a> |
| wwoods | I'm gonna get some IDE drives for my test machines | <a href="#t14:25" class="time">14:25</a> |
| notting | wwoods: 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> |
| wwoods | yeah, no, I should have caught this months ago | <a href="#t14:26" class="time">14:26</a> |
| warren | Which bug number are we discussing? Is there any concise summary of this problem? | <a href="#t14:26" class="time">14:26</a> |
| wwoods | so I'll be Super Tester Bitch for it | <a href="#t14:26" class="time">14:26</a> |
| jeremy | notting: well, most of the testing will need to be just general raid testing | <a href="#t14:26" class="time">14:26</a> |
| jwb | doesn't qemu present devices as old-ide? | <a href="#t14:26" class="time">14:26</a> |
| warren | how old IDE are we talking about? | <a href="#t14:26" class="time">14:26</a> |
| wwoods | warren: there's a bunch. 151653 is the first one | <a href="#t14:26" class="time">14:26</a> |
| wwoods | warren: anything that used to be hdX | <a href="#t14:26" class="time">14:26</a> |
| jeremy | jwb: it does | <a href="#t14:27" class="time">14:27</a> |
| jeremy | that's how I tested old ide upgrades :) | <a href="#t14:27" class="time">14:27</a> |
| wwoods | 231426, 238353, 221696, 213586, 238926 | <a href="#t14:28" class="time">14:28</a> |
| wwoods | weird that they all end in 3 or 6. | <a href="#t14:29" class="time">14:29</a> |
| wwoods | some 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> |
| jeremy | so, 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> |
| f13 | wwoods: you seem to have a good handle on the problem, want to poke peter? | <a href="#t14:30" class="time">14:30</a> |
| wwoods | f13: 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> |
| wwoods | warren: changed device name/number | <a href="#t14:30" class="time">14:30</a> |
| wwoods | e.g. hda -> sdc | <a href="#t14:30" class="time">14:30</a> |
| jeremy | anything else? | <a href="#t14:30" class="time">14:30</a> |
| warren | wwoods, 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> | |
| wwoods | warren: I don't think so? | <a href="#t14:31" class="time">14:31</a> |
| wwoods | I'm not sure, I can try to investigate further though | <a href="#t14:31" class="time">14:31</a> |
| rdieter | wrt 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> |
| notting | yes | <a href="#t14:33" class="time">14:33</a> |
| f13 | probably yes. | <a href="#t14:33" class="time">14:33</a> |
| rdieter | ok, we'll stick with (patched) 3.5.6 for now. :) | <a href="#t14:34" class="time">14:34</a> |
| wwoods | oh, 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> |
| warren | dmraid is like HPT and Promise ataraid? | <a href="#t14:35" class="time">14:35</a> |
| jeremy | warren: yes | <a href="#t14:35" class="time">14:35</a> |
| wwoods | yeah, the fakeraid BIOS-raid stuff | <a href="#t14:35" class="time">14:35</a> |
| warren | wwoods, what does the workaround involve? | <a href="#t14:35" class="time">14:35</a> |
| f13 | wwoods: I have hardware to test, but just nvidia raid. | <a href="#t14:35" class="time">14:35</a> |
| wwoods | warren: 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> |
| warren | wwoods, did dmraid work properly before? | <a href="#t14:37" class="time">14:37</a> |
| warren | wwoods, FC6 installer? | <a href="#t14:37" class="time">14:37</a> |
| wwoods | I thought it did - we have install test cases for it | <a href="#t14:37" class="time">14:37</a> |
| f13 | warren: yes. | <a href="#t14:37" class="time">14:37</a> |
| wwoods | like I said - no hardware, I've never tested it :/ | <a href="#t14:37" class="time">14:37</a> |
| warren | wwoods, is the broken component of this regression even isolated? | <a href="#t14:38" class="time">14:38</a> |
| f13 | I'm going to test dmraid in just a few minutes. | <a href="#t14:38" class="time">14:38</a> |
| warren | I'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> |
| wwoods | warren: +1 | <a href="#t14:40" class="time">14:40</a> |
| wwoods | okay, enough bugtalk from me | <a href="#t14:40" class="time">14:40</a> |
| warren | We seriously need -3 to be tested not just by x86_64 users, but all users. | <a href="#t14:40" class="time">14:40</a> |
| warren | we don't want to accidentally break it for everyone else. | <a href="#t14:41" class="time">14:41</a> |
| wwoods | hopefully 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> |
| wwoods | did we decide on the thursday freeze? | <a href="#t14:41" class="time">14:41</a> |
| f13 | no.... | <a href="#t14:42" class="time">14:42</a> |
| f13 | wwoods: we got sidetracked by your list of decisions to be made | <a href="#t14:43" class="time">14:43</a> |
| wwoods | sorry! | <a href="#t14:43" class="time">14:43</a> |
| f13 | no no, that's good | <a href="#t14:43" class="time">14:43</a> |
| f13 | as we needed to get through that to make a decision. | <a href="#t14:43" class="time">14:43</a> |
| wwoods | okay, 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> |
| f13 | wwoods: do you feel any better about doing the blocker only/branching on Thursday? | <a href="#t14:43" class="time">14:43</a> |
| wwoods | definitely | <a href="#t14:44" class="time">14:44</a> |
| warren | vote on it? | <a href="#t14:44" class="time">14:44</a> |
| wwoods | the 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> |
| warren | f13, when do we decide which blockers we will actually stop release for? | <a href="#t14:45" class="time">14:45</a> |
| wwoods | after Thursday nothing that does not fix a blocker will be accepted | <a href="#t14:45" class="time">14:45</a> |
| nirik | 81 still on the fc7blocker... | <a href="#t14:45" class="time">14:45</a> |
| wwoods | warren: 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="http://fedoraproject.org/wiki/QA/ReleaseCriteria">http://fedoraproject.org/wiki/QA/ReleaseCriteria</a> is how we're supposed to decide | <a href="#t14:45" class="time">14:45</a> |
| rdieter | we should work to prune those out (those that don't really belong). | <a href="#t14:45" class="time">14:45</a> |
| wwoods | in 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> |
| wwoods | everything else is a Target | <a href="#t14:46" class="time">14:46</a> |
| f13 | wwoods: presumably we'd have a meeting thursday or earlier to go over the blocker list. | <a href="#t14:46" class="time">14:46</a> |
| jeremy | anyone who wants to go through before and prune is welcome :) | <a href="#t14:46" class="time">14:46</a> |
| warren | wwoods, or broken deps? | <a href="#t14:46" class="time">14:46</a> |
| f13 | Proposal: Blocker only fixes starting Thursday (branch CVS same day) | <a href="#t14:47" class="time">14:47</a> |
| warren | Hmm, do we have a broken dep report after the merge? | <a href="#t14:47" class="time">14:47</a> |
| jeremy | f13: +1 | <a href="#t14:47" class="time">14:47</a> |
| f13 | repoclose 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> | |
| warren | Broken EVR paths and broken deps must be fixed before shipping. | <a href="#t14:48" class="time">14:48</a> |
| f13 | warren: those could be considered blockers. | <a href="#t14:48" class="time">14:48</a> |
| f13 | wwoods: you should add that to your ReleaseCriteria | <a href="#t14:48" class="time">14:48</a> |
| wwoods | f13: sure | <a href="#t14:49" class="time">14:49</a> |
| notting | hee "it seems that it's always the dumper" (re: emacs) | <a href="#t14:51" class="time">14:51</a> |
| f13 | can we get some more votes on the proposal? | <a href="#t14:51" class="time">14:51</a> |
| notting | f13: +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> |
| warren | which proposal specifically? | <a href="#t14:53" class="time">14:53</a> |
| f13 | jwb: ping? | <a href="#t14:53" class="time">14:53</a> |
| jwb | f13, yo | <a href="#t14:53" class="time">14:53</a> |
| wwoods | broken EVR paths / broken deps: blocker for all (test & final) releases, or just final? | <a href="#t14:53" class="time">14:53</a> |
| jwb | f13, i'm like .25% here | <a href="#t14:53" class="time">14:53</a> |
| jwb | what's the proposal? | <a href="#t14:53" class="time">14:53</a> |
| warren | wwoods, just final | <a href="#t14:54" class="time">14:54</a> |
| notting | wwoods: definitely blocker for final. almost-but-not-quite blocker for test releases | <a href="#t14:54" class="time">14:54</a> |
| warren | wwoods, it would have been impossible to fix deps of gaim-* plugins for Test4 for example. | <a href="#t14:54" class="time">14:54</a> |
| f13 | jwb: Proposal: Blocker only fixes starting Thursday (branch CVS same day) | <a href="#t14:54" class="time">14:54</a> |
| wwoods | okay, I'll list both as SHOULD | <a href="#t14:54" class="time">14:54</a> |
| warren | How 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> |
| warren | Fixing deps for the entire repo is a blocker for final. | <a href="#t14:54" class="time">14:54</a> |
| jwb | f13, 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> |
| f13 | warren: I wouldn't go that far for test releases. | <a href="#t14:55" class="time">14:55</a> |
| f13 | highly desireable, not blocker. | <a href="#t14:55" class="time">14:55</a> |
| warren | f13, packages within a spin shouldn't have working deps? | <a href="#t14:56" class="time">14:56</a> |
| f13 | warren: 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> |
| f13 | or at least it used to. | <a href="#t14:56" class="time">14:56</a> |
| f13 | jeremy: will it still? | <a href="#t14:56" class="time">14:56</a> |
| jeremy | yes. what else should we do? laugh in your face? :) | <a href="#t14:57" class="time">14:57</a> |
| jwb | yes | <a href="#t14:57" class="time">14:57</a> |
| f13 | nod | <a href="#t14:57" class="time">14:57</a> |
| jwb | you should have laughing ninja kittens | <a href="#t14:57" class="time">14:57</a> |
| notting | jeremy: steal the g-p-m 'can't suspend' sound | <a href="#t14:58" class="time">14:58</a> |
| f13 | that'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> |
| wwoods | so, 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> |
| f13 | you're making things complicated | <a href="#t14:59" class="time">14:59</a> |
| warren | we need a matrix to visualize this | <a href="#t14:59" class="time">14:59</a> |
| f13 | KISS | <a href="#t14:59" class="time">14:59</a> |
| jwb | yes, KISS. "fix your fscking broken deps" | <a href="#t14:59" class="time">14:59</a> |
| f13 | Broken deps for test == SHOULD> Broken deps for final == MUST | <a href="#t14:59" class="time">14:59</a> |
| f13 | btw, rawhide + dmraid just booted here. | <a href="#t14:59" class="time">14:59</a> |
| wwoods | f13: is that broken deps for the entire distro, or just the stuff in the spin? | <a href="#t15:00" class="time">15:00</a> |
| f13 | entire distro | <a href="#t15:00" class="time">15:00</a> |
| f13 | since the entire distro is itself a spin | <a href="#t15:00" class="time">15:00</a> |
| wwoods | oh, we're doing KitchenSink? | <a href="#t15:01" class="time">15:01</a> |
| f13 | wwoods: presumably anybody can by enabling the full repo at install time | <a href="#t15:01" class="time">15:01</a> |
| f13 | we'll do a tree, just no isos | <a href="#t15:01" class="time">15:01</a> |
| wwoods | do 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> |
| jwb | separate | <a href="#t15:02" class="time">15:02</a> |
| jwb | but it's important | <a href="#t15:02" class="time">15:02</a> |
| warren | separate, but equal | <a href="#t15:02" class="time">15:02</a> |
| notting | oh crap | <a href="#t15:03" class="time">15:03</a> |
| f13 | oh crap? | <a href="#t15:03" class="time">15:03</a> |
| notting | where is the eula for f7 - is it *completely* online? | <a href="#t15:03" class="time">15:03</a> |
| f13 | notting: yes. | <a href="#t15:03" class="time">15:03</a> |
| f13 | notting: 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> | |
| notting | where is the current eula? | <a href="#t15:04" class="time">15:04</a> |
| notting | jwb: nothing. apologies for the interrupt, want to make sure eula is correct? | <a href="#t15:04" class="time">15:04</a> |
| f13 | um... | <a href="#t15:04" class="time">15:04</a> |
| jwb | correct as in lacking the "Core"? | <a href="#t15:04" class="time">15:04</a> |
| notting | jwb: 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="http://fedoraproject.org/wiki/Legal/Licenses/EULA">http://fedoraproject.org/wiki/Legal/Licenses/EULA</a> | <a href="#t15:05" class="time">15:05</a> |
| f13 | it still has CORE (: | <a href="#t15:05" class="time">15:05</a> |
| jwb | can try.... would rather have gregdk do it though... | <a href="#t15:05" class="time">15:05</a> |
| jwb | or someone with access to RH legal | <a href="#t15:05" class="time">15:05</a> |
| notting | ok. will start working this | <a href="#t15:06" class="time">15:06</a> |
| warren | f13, what about name? | <a href="#t15:06" class="time">15:06</a> |
| f13 | hrm? | <a href="#t15:06" class="time">15:06</a> |
| jwb | notting, thx. if it wasn't legal-ish i would have no issues | <a href="#t15:06" class="time">15:06</a> |
| notting | warren: names are under review | <a href="#t15:06" class="time">15:06</a> |
| f13 | I guess we voted for the freeze, next topic | <a href="#t15:07" class="time">15:07</a> |
| f13 | well, we're over time anyway. | <a href="#t15:07" class="time">15:07</a> |
| warren | by an hour =) | <a href="#t15:07" class="time">15:07</a> |
| f13 | these meetings aren't short :( | <a href="#t15:07" class="time">15:07</a> |
| warren | who will announce the Thursday freeze? | <a href="#t15:08" class="time">15:08</a> |
| jwb | f13, want me to update the freeze/release dates? | <a href="#t15:08" class="time">15:08</a> |
| f13 | I will. | <a href="#t15:08" class="time">15:08</a> |
| warren | k | <a href="#t15:08" class="time">15:08</a> |
| jwb | ok | <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> | |
| f13 | jwb: I don't think we changed any dates today. | <a href="#t15:08" class="time">15:08</a> |
| jwb | f13, well we set the freeze date. | <a href="#t15:08" class="time">15:08</a> |
| f13 changed the topic of #fedora-meeting to: <a href="http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel">http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel</a> -- Meetings often get logged -- see schedule in the wiki for next meeting | <a href="#t15:08" class="time">15:08</a> | |
| f13 | jwb: it was already set for Thursday | <a href="#t15:08" class="time">15:08</a> |
| f13 | we just confirmed that we didn't need to further move it | <a href="#t15:09" class="time">15:09</a> |
| jwb | f13, <a href="http://fedoraproject.org/wiki/Releases/7/Schedule">http://fedoraproject.org/wiki/Releases/7/Schedule</a> | <a href="#t15:09" class="time">15:09</a> |
| jwb | f13, not according to that :) | <a href="#t15:09" class="time">15:09</a> |
| warren | f13, even if nothing changed, the warnings should go out. | <a href="#t15:09" class="time">15:09</a> |
| f13 | hrm, I thought we changed that last week. *sigh* | <a href="#t15:09" class="time">15:09</a> |
| f13 | warren: yeah, we're talking about a seperate issue. | <a href="#t15:10" class="time">15:10</a> |
| jwb | f13, 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> |
| jwb | f13, anyway, just update it when you send out the announce eh? | <a href="#t15:10" class="time">15:10</a> |
| f13 | roger | <a href="#t15:10" class="time">15:10</a> |
| jwb | danke | <a href="#t15:10" class="time">15:10</a> |
| wwoods | actually we need to be done by 29 May, IIRC | <a href="#t15:11" class="time">15:11</a> |
| jwb | yeah, something like that | <a href="#t15:11" class="time">15:11</a> |
| warren | gold bits so they can burn it | <a href="#t15:11" class="time">15:11</a> |
| wwoods | and synched/burnt by 31 | <a href="#t15:12" class="time">15:12</a> |
| f13 | which I'm still kind of thinking may be an act of god. | <a href="#t15:13" class="time">15:13</a> |
| f13 | or act of Zod | <a href="#t15:13" class="time">15:13</a> |
| jwb | f13, we need to get the updates tags ready... | <a href="#t15:15" class="time">15:15</a> |
| f13 | yeah | <a href="#t15:16" class="time">15:16</a> |
| f13 | I started work on that, got distracted | <a href="#t15:16" class="time">15:16</a> |
| jwb | f13, 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> |
| f13 | once we branch, the builds will automatically get tagged with the update candidate tag. | <a href="#t15:17" class="time">15:17</a> |
| jwb | update candidate == updates testing? | <a href="#t15:18" class="time">15:18</a> |
| jwb | or pre-updates testing? | <a href="#t15:18" class="time">15:18</a> |
| f13 | and dist-fc7-updates-candidate tag should be unlocked and will inherit from dist-fc7 | <a href="#t15:18" class="time">15:18</a> |
| f13 | both pre-updates teating and updates-testing | <a href="#t15:18" class="time">15:18</a> |
| jwb | so anything tagged with update candidate will show up in updates-testing on the mirrors? | <a href="#t15:18" class="time">15:18</a> |
| f13 | the 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> |
| f13 | jwb: only if they go through bodhi | <a href="#t15:19" class="time">15:19</a> |
| jwb | ok | <a href="#t15:19" class="time">15:19</a> |
| nirik | so 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> |
| f13 | nirik: after Thursday, new packages will get a devel/ branch and be tagged with dist-f8 | <a href="#t15:20" class="time">15:20</a> |
| f13 | nirik: 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> | |
| f13 | so 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> |
| nirik | so 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> |
| warren | Only four packages in F7 with broken deps that aren't kmod. | <a href="#t15:22" class="time">15:22</a> |
| f13 | nirik: 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> | |
| f13 | nirik: it would be the standard new package process | <a href="#t15:22" class="time">15:22</a> |
| f13 | nirik: you get devel/ for free, you ask for what other branches you want. | <a href="#t15:22" class="time">15:22</a> |
| nirik | yeah, 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> |
| jwb | nirik, that's already the case | <a href="#t15:23" class="time">15:23</a> |
| jwb | today. now | <a href="#t15:23" class="time">15:23</a> |
| f13 | why would a user ask for FC-5, FC-6, but not F-7 branch? | <a href="#t15:23" class="time">15:23</a> |
| f13 | and if they did, why would a cvs admin actually grant that request? | <a href="#t15:23" class="time">15:23</a> |
| nirik | sure, 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> |
| jwb | nirik, devel already _is_ final f7 | <a href="#t15:23" class="time">15:23</a> |
| jwb | right NOW | <a href="#t15:24" class="time">15:24</a> |
| f13 | nirik: I think one of us is confusing the other. | <a href="#t15:24" class="time">15:24</a> |
| nirik | yeah... likely me. | <a href="#t15:24" class="time">15:24</a> |
| nirik | what I am thinking of is this: | <a href="#t15:24" class="time">15:24</a> |
| jwb | f13, 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> |
| nirik | new packge. They request fc5/fc6/devel right now. | <a href="#t15:24" class="time">15:24</a> |
| f13 | jwb: we're talking about new packages. | <a href="#t15:24" class="time">15:24</a> |
| jwb | f13, ah | <a href="#t15:24" class="time">15:24</a> |
| nirik | they build for fc5/fc6/devel. | <a href="#t15:24" class="time">15:24</a> |
| f13 | nirik: 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> |
| nirik | they 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> |
| f13 | nirik: 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> |
| nirik | branch happens for f7... does there package have a f7 branch? | <a href="#t15:25" class="time">15:25</a> |
| f13 | nirik: yes, it would. | <a href="#t15:25" class="time">15:25</a> |
| jwb | nirik, yes. requests are only for tags | <a href="#t15:25" class="time">15:25</a> |
| f13 | nirik: at branch time, all active devel/ packages get branched. | <a href="#t15:25" class="time">15:25</a> |
| f13 | this 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> | |
| nirik | ok, 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> |
| jwb | now | <a href="#t15:26" class="time">15:26</a> |
| jwb | er, no | <a href="#t15:26" class="time">15:26</a> |
| jwb | CVS: cvsadmin request creates fc5/fc6/devel branches | <a href="#t15:26" class="time">15:26</a> |
| jwb | branching happens thursday | <a href="#t15:26" class="time">15:26</a> |
| jwb | now package has fc5/fc6/fc7/devel | <a href="#t15:27" class="time">15:27</a> |
| nirik | ok, and what packages do they have in the repo then? | <a href="#t15:27" class="time">15:27</a> |
| jwb | yep, getting to that | <a href="#t15:27" class="time">15:27</a> |
| f13 | which repo? | <a href="#t15:27" class="time">15:27</a> |
| nirik | the cvs side makes sense to me just fine. I think the tags are confusing me. | <a href="#t15:27" class="time">15:27</a> |
| jwb | plague: user builds. fc-5/fc-6 have packages in extras repo | <a href="#t15:27" class="time">15:27</a> |
| nirik | right | <a href="#t15:27" class="time">15:27</a> |
| jwb | koji: 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> |
| nirik | ok, say they did not | <a href="#t15:28" class="time">15:28</a> |
| f13 | then the build just sits there. | <a href="#t15:28" class="time">15:28</a> |
| jwb | if 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> |
| nirik | ok, that is the case I am talking about. | <a href="#t15:28" class="time">15:28</a> |
| f13 | and will be picked up once rawhide starts composing from dist-f8 | <a href="#t15:28" class="time">15:28</a> |
| jwb | nirik, that's true today | <a href="#t15:28" class="time">15:28</a> |
| nirik | end user on fc6 installs packageA. Upgrades to f7, and packageA isn't available anymore. | <a href="#t15:29" class="time">15:29</a> |
| f13 | nirik: 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> |
| jwb | the broken upgrade paths thing should catch that and send them nag-mail | <a href="#t15:29" class="time">15:29</a> |
| nirik | yeah, true... ok. | <a href="#t15:29" class="time">15:29</a> |
| nirik | do 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> |
| jwb | silence | <a href="#t15:32" class="time">15:32</a> |
| jwb | i think that means no? | <a href="#t15:32" class="time">15:32</a> |
| jwb | :) | <a href="#t15:32" class="time">15:32</a> |
| f13 | sorry, went to go get a soda | <a href="#t15:33" class="time">15:33</a> |
| f13 | we'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> |
| f13 | I just don't know who's going to be that "we" | <a href="#t15:33" class="time">15:33</a> |
| jwb | f13, what do you need access to to test it? | <a href="#t15:34" class="time">15:34</a> |
| nirik | mschwent 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> |
| jwb | he's a bit pissed at the moment | <a href="#t15:34" class="time">15:34</a> |
| nirik | yeah. Which is sad. :( | <a href="#t15:35" class="time">15:35</a> |
| f13 | jwb: access to the script, and uh, not sure what it looks at to compare. | <a href="#t15:36" class="time">15:36</a> |
| jwb | f13, i thought it ran right on the repos at push time | <a href="#t15:37" class="time">15:37</a> |
| f13 | it 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="http://cvs.fedora.redhat.com/viewcvs/upgradecheck/?root=fedora">http://cvs.fedora.redhat.com/viewcvs/upgradecheck/?root=fedora</a> | <a href="#t15:40" class="time">15:40</a> |
| jwb | that looks like it should already work? | <a href="#t15:41" class="time">15:41</a> |
| nirik | yeah, it just might. | <a href="#t15:41" class="time">15:41</a> |
| jwb | f13, think you can run that inside the colo and see what the results are? | <a href="#t15:42" class="time">15:42</a> |
| jwb | f13, given that would be fastest... | <a href="#t15:42" class="time">15:42</a> |
| f13 | might be able to | <a href="#t15:42" class="time">15:42</a> |
| nirik | I can run it here too, but yeah, slower | <a href="#t15:42" class="time">15:42</a> |
| f13 | it was changed 3 hours ago, maybe somebody is already running it? | <a href="#t15:44" class="time">15:44</a> |
| jwb | you'd have to ask ville | <a href="#t15:44" class="time">15:44</a> |
| jwb | can'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 irclog2html.py 2.3 by Marius Gedminas - find it at mg.pov.lt!