19:30:07 #startmeeting FESCO (2010-06-08) 19:30:07 Meeting started Tue Jun 8 19:30:07 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:07 #meetingname fesco 19:30:07 #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:07 #topic init process 19:30:07 The meeting name has been set to 'fesco' 19:30:07 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:28 jola. 19:30:41 #info notting kylem and cwickert all said they will be unable to attend today. 19:30:49 Afternoon 19:31:42 * nirik waits to see if we have quorum. ;) 19:32:25 * SMParrish here 19:32:41 if i say i'm not here, can we skip it? 19:32:42 ok, thats 5 at leasy. 19:32:59 * nirik can't type today. 19:33:06 I'm definitely not here. No way no how. 19:33:12 I'm someplace else. Probably at home. 19:33:40 cool. Since pjones isn't here lets assign everything to him. ;) 19:33:58 good luck with that ;) 19:34:07 #topic #351 Create a policy for updates - status report on implementation 19:34:08 .fesco 351 19:34:10 nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:34:28 so, I talked with lmacken... hopefully we can get something pushed out later this week... 19:34:34 \o/ 19:34:36 yay 19:34:40 for the critpath at least. 19:34:40 * mclasen walks in 19:34:56 lmacken: does that include the other 2 tickets I filed... ? 19:35:16 nirik: potentially... I need to give them a Good Hard Look first. 19:35:31 ok. 19:35:50 I take it no one objects to implementing critpath and the 3rd section before autoqa is ready to land? 19:36:04 https://fedoraproject.org/wiki/Package_update_acceptance_criteria 19:36:48 nirik: whats the 3rd section ? All other updates ? 19:37:17 the Updates to 'important' packages and All other updates sections. 19:38:08 yeah, I'm for that. 19:38:17 * nirik is too. 19:38:28 I'm ok with it 19:38:33 +1 19:39:10 #info lmacken is working on a new bodhi version this week that will have the important packages and (possibly) the all other updates section implemented. 19:39:42 ok, any other thoughts/input on this? or shall we move along? 19:40:04 Guess we can move on? 19:40:08 thanks to lmacking for working on this 19:40:12 err, lmacken 19:40:16 And yeah, definitely 19:40:25 agreed. ;) 19:40:29 #topic #385 Zim / zim package issues. 19:40:29 .fesco 385 19:40:31 nirik: #385 (Zim / zim package issues.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/385 19:40:41 I'm just going to note here that things seem to be moving on this ticket ok. 19:40:59 The Current Zim maintainer is going to allow the new submitter to update to the new version with the existing Zim package. 19:41:07 So, nothing to see here. moving on. ;) 19:41:29 great 19:41:33 Yup, I think we're done there 19:41:34 toldja. 19:41:34 I'd like to hold the "Implementing Stable Release Vision" ticket to the end since it's likely to have longer discussion... 19:41:37 ;) 19:41:55 #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 19:41:55 .fesco 387 19:41:55 nirik: #387 (compile list of supported CPUs and react to recent loss of support for Geode LX on F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/387 19:42:08 so, this looks unfortunate for XO folks. 19:42:17 yes it is 19:42:43 i've asked this before and never really gotten a good answer: why are primitive x86s not treated as a secondary arch? 19:42:46 IMO probably to late to change things for F13 but would like to see it corrected for F14 19:43:13 Well, we're kind of limited by the code that gcc outputs 19:43:22 ajax: because no one would do the work and they would just die I suspect? 19:43:30 mjg59: -march=i386 is a pretty good control for that. 19:43:37 nirik: and that's an argument against? ;) 19:43:38 I investigated this last night, it CAN be changed for F13. See bug report https://bugzilla.redhat.com/show_bug.cgi?id=579838 19:43:45 ajax: Yeah, we could output for 586 and optimise for 686 19:43:49 well, i486 since pthreads, but. 19:43:50 s/686/core 19:43:57 All the executables are OK, only glibc is borked. 19:45:11 so, a) get gcc changed b) get glibc changed to not use that instruction c) get the kernel emulation of that instruction working/added, d) say we don't support this cpu anymore. 19:45:45 Previous attempts to implement missing instructions in the kernel have generally not been accepted by upstream 19:45:59 3 of those require us to mandate that people do work when we really are in no position to ask that. 19:46:03 There's several easy and wrong ways to do it. I don't know that anyone's done it in an upstream acceptable way. 19:46:11 re a), this doesn't appear to be a gcc issue. gas is generating NOPL for .align opcodes, probably because the glibc build told it we were building for i686. 19:46:20 (d) is not an option. Sugar has too much invested in working with Fedora for the XO-1 19:47:01 c's pretty much a nonstarter. that leaves 'b', which sounds like loads of fun. 19:47:06 If it is just glibc, would a custom glibc build for olpc be an option ? 19:47:20 SMParrish: Well, I think (d) is certainly an option at our level. I'd think that it's the board's responsibility to determine whether supporting a third party is worth making technical compromises. 19:47:28 yeah, upstream kernel or upstream glibc... which would more likely accept a fix? :) 19:47:45 Well, we could build glibc with different options 19:47:47 olpc wants to be able to use the standard Fedora repos. 19:48:01 well, we are not talking about upstream fixes but about build configuration, no ? 19:48:07 yeah, which is something we should try to encourage, not inhibit. 19:48:15 mjg59: Fedora has alot invested with the Sugar folks as well. RH was on original sponsor of the program 19:48:19 But if there's a performance hit, compromising glibc seems like a poor choice 19:48:29 i don't think d) is an option; we didn't intend to break geode in f13, so retroactively declaring it so is disingenuous. 19:48:51 mjg59: .align isn't something i'd expect to be a performance path 19:49:00 the 'performance hit' is on the No-ops that precede a loop start. Not in the inner loops. 19:49:00 i mean, that's the dead space between functions, right? 19:49:09 oh, loop align too, right. 19:49:12 still, whatever. 19:49:26 its not entirely limited to glibc. there were some mentions of other packages 19:49:49 providing alternative packages might be an option, but as things progress in future it would probably be hard to control 19:49:53 all the packages I found with nopl's were either generated from glibc sources, or were linked statically with glibc. 19:49:59 In an ideal universe, gcc would have a definition of 686 that matched reality 19:50:33 dsd_: what is the best solution for you. Would an i586 subarch work? 19:51:28 i dont know too much about subarchs 19:51:44 subarch = secondary architecture? 19:51:48 mjg59: competition in the cpu market is such a drag. Innovation that doesn't all go in one direction, bah. 19:51:54 dsd_: yes 19:52:17 is autoqa in a position to do checks like 'no NOPL' on our binary rpms ? 19:52:29 Guest62041: So the difference would be (i) a glibc built with -march=586, and (ii) a rebuild of everything that statically links glibc? 19:52:38 mclasen: I don't think so yet, but eventually I would think so. 19:52:50 I think you are correct. 19:52:57 mclasen: it certainly could. it has the binary payloads, and objdump knows how to disassemble. just needs writing. 19:53:05 So it would be a relatively small package overlay 19:53:10 so, our glibc maintainer(s) aren't willing to work around this? I only see the one comment pointing to the kernel work... 19:53:14 SMParrish: i dont know enough about what "secondary arch" means to say really.. and i guess my newbie questions would be outside of the scope of this meeting 19:53:37 Why build a sub architecture for three packages? Why not just fix glibc in the F13 repos? 19:53:57 Fix glibc how? 19:54:26 fix its configuration so that it uses the i686 instruction set minus NOPL 19:54:30 can anyone say with confidence (perhaps with a solid reference) that nopl is the only i686 instruction unsupported by Geode LX? 19:54:43 Guest62041: My fear is that over the next few years additional changes could be introduced which cause another issue with Geode 19:54:47 dsd_: nopl, and cmov, and ... 19:55:02 ajax: no, we have cmov. 19:55:08 i don't know of a list of what's definitely excluded from geode 19:55:19 there's a memory/memory CMOV missing, but we don't use it. 19:55:22 ...yet... 19:55:24 i'm just wondering if we'll see the same thing again in 6 months time with another weird instruction 19:55:29 probably. 19:55:37 so when i said "why is this not a secondary arch" i was trolling 19:55:48 it's because we don't actually have a meaningful secondary arch process 19:55:51 testing on Geodes would let us figure out early enough if something does come up in 6 months. 19:55:54 So, I don't think changing glibc is a sensible plan here 19:55:57 the problem was that the bug was reported and then ignored. 19:56:17 Because the code is correct, it just has undesirable effects on a given CPU 19:56:58 which leaves what? kernel or seperate i586 versions. 19:56:59 ? 19:57:03 And it's possible that updates *within* a release may cause applications that previously worked to suddenly contain these instructions 19:57:15 in several years, the only sigill we've seen when running i686 distros on the LX is from NOPL. (And NOPL is interesting because it's not actually a documented insn in i686, which is perhaps why the Geode designers chose not to bother.) 19:57:17 the high level question is: is the Geode LX a supported CPU? If so, glibc has a bug. If not, glibc is correct and the Geode has a, uh, problem. 19:57:37 i think by inertia lx _is_ supported. 19:57:41 * nirik notes we are at 15minutes into this discussion. Votes to keep going? or ask for more data/wiki writeups of proposals? 19:57:42 So we either need to stop gcc emitting nopl or we need nopl to work on the geode 19:58:03 It's trivial to stop gcc emitting nopl - we just change the default architecture again 19:58:17 ...and rebuild the entire archive 19:58:28 mjg59 ideally we'd fix it both ways -- patch the glibc makefiles, AND add a kernel workaround to avoid future problems 19:58:39 but it only seems to emit it for a handful of binaries now, so why rebuild everything ? 19:59:07 mjg59: For some reason we don't yet understand, only glibc binaries are affected. Standard package build process doesn't produce NOPLs. 19:59:08 mclasen: Yeah, I guess ABI isn't going to be impacted, so we could scan the entire binary archive and just rebuild them 19:59:15 folks? votes to keep going please? 19:59:20 nirik: keep going 19:59:23 nirik: +1 19:59:26 +1 19:59:29 * nirik is fine with going on. 19:59:46 My concern is that changing the architecture mid-release could trigger other issues 19:59:59 I think that'd be great. (Scan and rebuild affected binaries, which we currently believe to only be glibc.) 19:59:59 Updates of some libraries may start using different codepaths 19:59:59 mjg59: change it to what? i586? 20:00:02 keep going, yes 20:00:13 nirik: Yeah, unless there's some more fine-grained architecture control I'm unaware of 20:00:22 cjb: plus static linkers of glibc ? 20:00:33 Perhaps we could convince upstream to do a 686-nopl 20:00:47 But, like I said, there's a risk inherent in doing this mid-cycle 20:00:47 mjg59: it could be done for F14, perhaps. (i dont think that would bother OLPC too much, but other LX users might think differently) 20:00:52 would that be i686-nonopl ? 20:01:03 sounds like a nonopoly to me 20:01:04 The risk is lower if we just change the glibc spec file 20:01:27 or that. change arch for f14, hack glibc for F13 20:01:28 But there'd plausibly be a package update that broke things mysteriously 20:01:36 i'm a little confused why we're talking about glibc; .align is a macro in gas. 20:01:51 (i assume) 20:02:00 ajax: glibc or gcc? 20:02:20 i think really all we can say at this point is that we think it's broken, and we need to figure out where. 20:02:30 gcc generates .align sometimes, to line up loops on cache line boundaries. gas turns that into any of a dozen forms of NOP depending on what CPU was specified and tuned for. 20:02:43 Yeah, so when I say gcc pretend I said binutils 20:03:02 But either gcc isn't generating .align for most packages, or gas is being passed different flags for most packages than for glibc. 20:03:08 that's the part we don't understand. 20:03:29 * nirik thinks we should try and get gcc / glibc maintainers involved in this discussion... but not sure how best to do that. 20:03:34 Ok. Perhaps we should come back to this when the problem is better understood? 20:03:52 something like: we want to support this cpu. How can we most easily and safely make it so? 20:04:25 the CLOSED NOTABUG bug report has been reopened, so it should reenter the maintainers' radar. 20:04:34 did we definitively decide that we need to fix this in f13 and not tell olpc to use an overlay ? 20:04:47 so we all agree we'd rather continue supporting this, right? and then mclasen's question was my next one. 20:04:50 mclasen: I think definitively deciding that depends on what's actually happening 20:05:12 * nirik wants to support this cpu... but needs more info on what changes could do that and how risky they are. 20:05:13 ok, so we are still trying to figure out if we _can_ safely and acceptably fix it in f13 20:05:18 It'd be desirable, certainly 20:05:24 mclasen: I think the position is more that, since we thought it *was* a supported arch for the release, if we're going to drop it then that should happen with warning at the next release, not retroactively. 20:05:41 +1 on continuing support and if possible fixing in F13 20:05:51 cjb: I think that's fair, but I was asking about a stronger position of "we don't want to discontinue this" 20:05:55 any suggestions for who to reassign the now-opened WONTFIX bug to? 20:05:58 which it sounds like there's wide agreement on 20:06:19 well, is a bug the best way to get input from gcc/glibc folks? or can we contact them more directly? 20:06:37 the best thing is probably to find jakub on email or irc and ask him what can be done 20:06:46 It's a bit of an odd position to say, let's desupport 1.5M in-use machines to get a <1% speedup on NOPs in libc. 20:06:51 email might be preferable in that more of us can see it. 20:07:12 (he's currently idle 10 hours on irc, so... probably not around) 20:07:27 would someone be willing to take that action item and provide any info back to the fesco ticket/bug? 20:07:55 * mclasen can do that 20:07:55 I will 20:08:03 * mclasen steps back quickly 20:08:25 ha. 20:08:44 #action SMParrish will contact gcc maintainer and see what possible solutions to this problem are. 20:08:49 thanks SMParrish 20:08:53 thanks all 20:08:54 anything more on this now? 20:08:54 thx to all 20:09:17 cjb / Guest62041 / dsd_ : thanks for the input on the issue. ;) 20:09:38 nice to know somebody's listening! 20:09:50 * nirik is sorry it happened and wasn't caught before release. ;( 20:09:56 (well, wasn't acted on before release) 20:10:15 #topic #388 request for e2fsprogs-libs-static 20:10:15 https://fedorahosted.org/fesco/ticket/388 20:10:15 .fesco 388 20:10:15 nirik: #388 (request for e2fsprogs-libs-static) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/388 20:10:24 turns out I think this ticket can be closed... 20:11:05 or I guess it's not against the right package. 20:11:17 ie, yaboot should get approval for linking static. 20:11:36 bootloaders are exceptional, yeah 20:11:46 in any case, I am fine with this, it makes sense why it needs it. 20:12:06 so, +1 here. 20:12:18 +1 from notting in the ticket 20:12:22 Reading a shared object off a filesystem is hard if you need that shared object in order to read the filesystem, yeah 20:12:33 +1 to exception for yabooy 20:12:38 +1 20:12:38 +1 20:12:46 also, the package spelled correctly 20:13:09 #agreed yaboot can statically link here. 20:13:25 now on to f14 feature fun! :) 20:13:28 #topic #391 F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall 20:13:28 .fesco 391 20:13:29 nirik: #391 (F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/391 20:14:00 +1 from notting in the ticket. 20:14:29 +1 from here. Also not sure how many people will use it, but it's cool. ;) 20:14:31 I can't see any reason for anything but +1 here 20:14:36 same, +1 20:14:39 I'll be +1 on it I _guess_ 20:14:45 but consider that to be under duress. 20:14:46 +1 as well 20:14:56 pjones: odd. I was expecting you to kibosh it. ;) 20:15:06 #agreed feature is approved. 20:15:13 * mclasen added some comments on the feature 20:15:39 #topic #390 F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images 20:15:39 .fesco 390 20:15:40 nirik: #390 (F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/390 20:15:51 mclasen: that comment kindof makes me want to punch people. 20:16:00 fine with me 20:16:06 as long as you don't punch the messenger :-) 20:16:30 it's as if the people doing the work weren't consulted at all... oh wait ;) 20:16:53 I don't know that, and I didn't mean to imply that 20:17:02 man i sure would like it if squashfs would grow interface-stable tools, ever. 20:17:12 ajax: s/interface-// 20:17:26 yeah. ;( 20:17:43 * nirik is +1 here, we can yank it if it doesn't land or turns out to not work or be slow or whatever. 20:17:48 i think it's a reasonable thing to shoot for though. +1 20:18:03 * SMParrish agrees with nirik +1 20:18:11 Yeah, +1 20:18:14 +1 20:18:17 it's a pity the upstreaming is going so slowly. It was first submitted for .32 I think... or .31 20:18:34 #agreed Feature is approved. 20:18:44 #topic #392 F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo 20:18:44 .fesco 392 20:18:45 nirik: #392 (F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/392 20:18:45 Thanks. 20:18:58 brunowolff: sorry for forgetting to cc you on that ticket. ;( I failed. 20:19:26 +1 from notting on the ticket to libjpeg-turbo 20:19:34 I knew that it was going to be discussed at the meeting because the wrangler changed the wiki page to indicate that. 20:19:44 i love the "how to test" on this one. seeing artifacts is all jpeg _ever_ does. 20:20:28 It should produce identical output to libjpeg, right? 20:20:45 +1 from me. Again we can back it out pretty easily since no rebuilding needs to happen. 20:20:52 mjg59: yeah, should be. 20:21:07 mjg59: i think there's some wiggle room there, but at least perceptually yes. 20:21:07 Yeah, so it should be pretty obvious if it's grotesquely broken 20:21:08 mjg59: yeah, that should be testable 20:21:09 +1 20:21:30 perceptual diff... 20:21:51 istr one of the libjpeg replacements doing something different for iDCT which meant you got rescaling for free, but not pixel identical results. 20:21:57 might be this one, might not. 20:22:04 anyway, +1, looks plausible 20:22:36 Easy to revert if we find issues later +1 20:23:19 #agreed Feature is approved. 20:23:32 so, how is this going to work in practise btw 20:23:42 is libjpeg-turbo going to replace libjpeg ? 20:23:48 we run out of time and move whatever is finished to next release. 20:23:53 Oh, you meant that. 20:24:10 obsoletes/provides ? 20:24:20 yes 20:24:23 it does currently. 20:24:24 obsoletes/provides is probably the way 20:24:34 http://atkac.fedorapeople.org/libjpeg-turbo/libjpeg-turbo.spec 20:25:12 ok, anything more on this? 20:25:57 #topic FES ticket updates - https://fedorahosted.org/fedora-engineering-services/report/6 20:26:05 mmcgrath: anything to report this week? 20:26:13 Just a few things 20:26:29 1) we got a new contributor that knows C/C++ so that's good. 20:26:36 other then that there was one ticket /me gets it 20:26:56 https://fedorahosted.org/fedora-engineering-services/ticket/24 that one 20:27:09 josemm went through and wrote this but it's not so clear the data we're getting is particularly useful in that form. 20:27:32 nirik: did you have any additional thoughts on that? 20:27:33 yeah, I'd like more idea on what we could look for for 'very active bugs' 20:28:06 basically we want a way to note things that are hitting lots of users or have lots of activity, but not closed... so we could look at adding resources to get them fixed... 20:28:12 I'd think active bugs is less important then the number of cc's on a bug. 20:28:24 if lots of people care to watch it, they probably all want to know when its fixed. 20:29:09 yeah, so perhaps just 'number of cc's'... but I'm not sure we can get that from bugzilla easily. 20:29:28 * mmcgrath isn't sure either 20:29:31 I be josemm knows :) 20:30:05 If anyone else has any ideas or thoughts, chime right in. ;) 20:31:03 well, we can keep poking at it... and perhaps josemm can find a way to do things for us. 20:31:09 thanks mmcgrath. 20:31:32 As always, feel free to file tickets or add info to them... 20:31:42 yup yup 20:31:46 #topic #382 Implementing Stable Release Vision 20:31:47 .fesco 382 20:31:48 nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 20:32:07 so, mclasen added some ideas last week... 20:32:20 also poelcat would like us to come up with a timeline for implementation 20:32:27 https://fedorahosted.org/fesco/ticket/382#comment:6 20:33:23 * nirik taps the mic. Is this thing on? :) 20:33:57 oh, timelines. 20:34:14 "man, i need to measure this somehow... but how?" 20:35:18 yeah, they tend to be pretty bogus, especially when you're pretending they're schedules. 20:35:38 also, it's hard to say much until we have a list of things we would like to implement. ;) 20:35:46 i think mclasen's ideas are along the right track. but in saying that, i'm saying that i don't think we have tools to measure a lot of that. 20:36:04 was re: hot bugs from the FES tickets above. 20:36:19 yeah. 20:36:52 what i was trying to get at was a rough notion of when it will be implemented... a goal of some sorts 20:36:57 ? 20:37:01 I think it might be worthwhile to list out things to implement for each bullet point in the Board vision... perhaps setup a wiki page to collect things ? 20:38:08 yeah. it's probably worth trying to talk with the design people about what this would look like for a user trying to consume it. 20:38:09 poelcat: yeah, but it's really hard to estimate that when we don't yet have a full list of things that we would like to implement? 20:38:46 nirik: even thinking really broadly? e.g. end of F14, or end of 2010, or ? 20:38:50 some of that we already know, of course. things like abrt being able to tell you that your crash is fixed with a given update. 20:39:30 * poelcat subscribes heavily to the "if you shoot for nothing" principle 20:39:35 poelcat: the thing is I bet some of them would be pretty short term/before f14, but some might not be until later... 20:40:29 true 20:41:23 I can make a wiki page for a ideas container? 20:41:31 sounds good. 20:41:44 then we can have folks add to it and see which ones we can do at what time 20:41:44 ? 20:41:55 nirik: good idea 20:41:55 i think we should be able to come up with which bits we're going to aim for by f14 and which will be later. 20:42:37 yeah, so: before f14, f15 and 'pie in the sky' ? 20:42:59 that sounds like a good start 20:43:16 if we do something before f14, it would be for f13 updates, yes ? 20:44:03 nirik: that sounds about right, yeah 20:44:17 mclasen: I don't see why not 20:44:21 mclasen: well, or something to have ready for f14 gold. i guess those are different things. 20:44:24 mclasen: good question... I think a number of these things could be addressed in all active streams. 20:47:57 https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas 20:48:11 please edit/add/fold/spindle/mutilate. 20:48:46 excellent, thanks! 20:48:52 any other thoughts on this for now? 20:49:28 #topic Open Floor 20:49:35 Anything for open floor? 20:49:43 i do have the libiberty scanner running, but lord is it slow 20:50:08 9000 packages in F13, and i've got through 2000ish in the past two hours or so 20:50:09 not really surprising. 20:50:28 almost entirely blocked on read bandwidth to the lookaside cache 20:50:29 that's actually faster than I would have predicted. 20:50:32 cool. Update the ticket as you get info. ;) 20:50:48 * mclasen apologizes for being slightly unresponsive today, dueling meetings... 20:51:01 I guess the last time I tried to do something like that was on a sun ultra 2 (and rh7.1...), so... 20:51:09 ajax: any news on the mediawiki fun? 20:51:14 mclasen: no worries, thanks for making an attempt on the scheduling 20:51:50 mjg59: any update for https://fedorahosted.org/fesco/ticket/381 20:52:06 nirik: Nobody replied when I brought it up. I'll try harder. 20:52:14 nirik: i think i'm coming down on the side of mediawiki. it's a worthwhile change in principle but i don't think the implementation is good enough to be carrying. still thinking. 20:52:17 bummer. ;( 20:52:29 ajax: ok. 20:52:46 oh, does anyone object to me just closing https://fedorahosted.org/fesco/ticket/276 ? 20:52:55 thats the 'include cacert.ca' 20:53:08 boot it. 20:53:18 cool. 20:53:21 * nirik has nothing else. 20:53:41 keeeel 20:53:49 * mclasen ponders bringing up nss-softokn 20:53:53 nah 20:54:01 mclasen: yeah, it's a mess. ;( 20:54:02 next week 20:54:04 ok. 20:54:08 we could argue about that in public for another week before you do that ;) 20:54:13 Thanks for coming everyone! 20:54:26 #endmeeting