17:00:01 #startmeeting 17:00:10 #meetingtopic FESCo Meeting 17:00:21 #meetingname fesco 17:00:28 #chair bpepple dgilmore dwmw2 jwb notting nirik sharkcz jds2001 j-rod 17:00:39 who all is here for the fesco meeting? 17:00:55 * sharkcz is here 17:00:57 * bpepple is here. 17:01:00 * jnovy is here 17:01:05 * j-rod waves 17:01:13 * subfusc points on nirik 17:01:40 * notting is here 17:02:11 ok, I guess we can go ahead and get started... 17:02:15 #topic Feature: F12X86Support - https://fedoraproject.org/wiki/Features/F12X86Support 17:02:26 notting: care to introduce this? 17:02:43 sure 17:03:13 back when we did i586 for F-11, we agreed in a FESCo vote to do i586 for F-11 and i686 likely for F-12. i was asked to write up the feature last week, so i did 17:03:31 the original feature specified a minimum of a SSE-2 capable cpu. it was ... not received well. 17:03:42 notting: yeah, I noticed. ;) 17:03:57 so, what does moving from i586 -> i686 really buy us? dropping old stuff we don't want to support? 17:04:02 so the current proposal is to just built for basic i686-class CPUs, but optimize for Atom, as it's the currently available model 17:04:25 nirik: 1-2% performance in benchmarks, fewer kernel builds 17:04:27 * nirik has to step away for just a min. back in a minute. 17:04:42 but is it really? it would be i686 instead of i586? so same #? 17:05:30 we also make the compiler guys happier 17:05:42 nirik: no, we build separate i586 and i686 kernel packages ATM 17:06:04 notting: we build kernel.i586 and kernel-PAE.i686 17:06:08 (iirc) 17:06:17 according to uli, the -march=i686 code paths are more tested that -march=i586 17:06:29 for base i686, the geode in the XO still works 17:06:56 the one potentially relevant CPU that we would be dropping support for is the Via C3 17:07:06 so yeah, no less kernels built, we don't have a kernel.i686 atm 17:07:45 notting: one possibility, is that someone once did a patch to provide cmov emulation for userspace. 17:07:53 my only c3 board has cmov. everyone else be damned. 17:08:00 j-rod: less builds, i.e. not tying up two build machines. also, shared debuginfo-common 17:08:05 j-rod: ...? are you sure it's not a c5 17:08:29 ah, yes, there's slightly less build output then... 17:08:38 pretty sure its a c3 17:08:39 the later C3's had cmov (nehemiah steppings onwards iirc) 17:08:42 Via Nehemiah 17:09:22 the older ones were used in those epia and other mini-itx boards a lot though. 17:09:26 (the board is actually sitting on the shelf in my cube, its way too slow to be worth playing with when you're spoiled w/quad-core stuff...) 17:10:10 mine's an epia mini-itx as well, but yeah, I know plenty of the earlier ones had no cmov 17:10:23 davej: is the cmov emulation patch slow-as-molasses? 17:10:56 notting: you're using a c3, speed isn't really your concern. 17:11:01 ...but faster than not working at all 17:11:46 one other thing: the benefits do rely on a mass rebuild. jwb, f13 - you had concerns? (this applies to the later xz feature as well) 17:12:00 sidenote: I thought I read somewhere that gcc doesn't emit cmov's when tuned for atom because it's not a perf win any more? 17:12:13 davej: uno momento 17:13:25 davej: one of my test binaries shows 73 cmov instructions for -mtune=atom 17:13:43 ok 17:15:30 anyone have any other questions/concerns? 17:15:32 if someone wants the raw data that went into my numbers, http://notting.fedorapeople.org/benchfu.gnumeric. ignore the openssl numbers, they're not a valid benchmark 17:16:25 notting: I had concerns with fitting in a every package rebuild within the F12 cycle 17:16:42 or an every package with arch change rebuild 17:16:55 start now 17:16:56 :) 17:17:17 since we dropped the point release previously known as alpha this is less of a concern 17:17:21 but still a lot of bit shuffle 17:17:27 the executive summary is: -mtune=atom is a win for both i586 and i686 on atom, and a (small) loss on other cpus. -march=i686 is a win on all CPUs except for P4 17:18:41 atom scheduling actually helps p4 17:18:51 (although that may be noise) 17:19:06 f13: the mass rebuild for f11 took... one week? 17:19:25 technically it's still not done 17:19:31 there are things which haven't been rebuilt. 17:19:48 but yes, the scripted part was less than a week 17:19:51 erm, ok. i mean, 'the automated part for packages that aren't broken' :) 17:21:08 yeah 17:21:42 depending on the status of the CVS server that will either go quicker for F12, or I need to work on better threading of the script to create the builds 17:21:47 CVS was the limiting factor 17:22:02 davej: was your mentioning of a cmov emulation patch a statement of willingness to do the integration of it? >:) 17:24:37 17:25:37 is there any other questions, or are we ready to vote on this proposal? 17:26:06 * sharkcz has no questions 17:26:24 I got nothin'. 17:26:27 +1 to F12X86Support proposal. 17:26:46 +1 17:26:49 +1 17:27:21 nirik, notting, dgilmore, jwb: ? 17:27:50 +1 17:27:59 * notting will help with the rebuild script if necessary 17:29:11 * bpepple wonders if we have a majority of FESCo present. 17:29:18 I'd offer to help w/the cmov emu support, but its probably over my head... 17:29:43 j-rod: http://lkml.indiana.edu/hypermail/linux/kernel/0206.3/0631.html is probably the start 17:29:44 * j-rod hasn't paid a lot of attention to assembly since working on a z-80 ~10 years ago 17:30:18 j-rod: although there's also some sort of cmov emulation in the kvm code? 17:30:32 sigh. My laptop blew up totally. Sorry for dropping off. 17:30:38 * notting notes dgilmore and jwb may not be here 17:30:59 nirik9999: we're voting on the x86support proposal. we've got 4 '+1'. 17:31:24 so, I was going to ask... what does this really get us? 17:31:45 notting: oy. that's painful to read... wonder what kvm's looks like... 17:31:45 can't we just stick with i586 for now and get more people to just go to x86_64? 17:32:14 * nirik9999 's proxy might reconnect in a minute and I can read scrollback. 17:33:05 we get a decrease in complexity 17:33:18 no i586 and i686 openssl and friends, just i686 17:33:32 32-bit x86 kernels all built in a single pass (so shared debuginfo) 17:34:00 we use better tested -march=i686 codepaths 17:34:18 * bpepple notes he has a hard stop at 25 minutes. 17:34:22 * nirik reads backscroll 17:34:52 don't forget the minor (but significant) speed increases 17:35:16 I'm really not sure this buys us enough, but on the other hand, I doubt we have many i586 users left... 17:35:52 ok, I guess I am +1 on it... noting that anyone that really objects should work to form a i586 secondary arch...(we want to allow that right?) 17:36:17 i'm all for willing secondary arch teams 17:37:52 ok, so is that enough to pass it? let me look. 17:38:04 nirik: we're at 5 '+1'. 17:38:07 yeah, +5 it looks like. 17:38:10 nirik: that's 5 +1s from the 5 members here 17:38:37 ok, thats enough to pass it, but do we want to give those not present a chance to weigh in? 17:38:50 also, is this the last fesco meeting with the current lineup? 17:39:00 nirik: there's also the cmov emu patch option, which I *think* would at least make things still functional for most i586 users 17:39:00 nirik: the schedule was published, and there were no replies as far as I'm aware. 17:39:29 j-rod: just slower? 17:39:30 j-rod: I think that's worth investigating (and possibly trying to get upstream if it works out) 17:39:40 bpepple: true. ok. 17:39:50 nirik: yeah 17:40:00 davej: yeah, definitely 17:40:02 nirik: there was also the thread on devel. ;) 17:40:08 yeah, thats worth persuing. 17:40:14 ok, so this is approved. 17:40:17 if we can still support i586 w/just a patch vs. an entire secondary arch... 17:40:23 seems worthwhile 17:40:32 #agreed The feature is approved. 17:40:37 j-rod: totally. 17:40:50 j-rod: just need to find a machine without cmov to test it on :) 17:40:51 #topic Feature: NFSClientIPv6 - https://fedoraproject.org/wiki/Features/NFSClientIPv6 17:40:57 .fesco 168 17:41:02 nirik: #168 (Feature: NFSClientIPv6 - https://fedoraproject.org/wiki/Features/NFSClientIPv6) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/168 17:41:14 davej: all of my went to recycling early this year. ;) 17:41:32 davej: yeah, there would be that... the most slothful thing I have here is my c3, but its got cmov... 17:42:01 this seems fine. i don't like the 'need a opensolaris server to test against', but i understand it 17:42:02 j-rod: I might still something ancient somewhere. will need to go digging 17:43:03 notting: I'm working on the linux server now, but it's not completely there yet 17:43:17 mostly waiting on chuck lever to finish overhauling rpc.statd 17:43:26 yeah, this feature sounds fine to me. Not sure it's something most people will notice or care about tho 17:43:44 * notting is +1 17:44:03 +1 here 17:44:07 +1, being IPv6 ready is good thing 17:44:12 +1 17:44:15 nirik: not at the moment no, but hey solaris has had ipv6 support for 10 years or so, so we might as well get on board ;) 17:44:18 +1, ipv6 will be relevant some day. right? ... :) 17:44:29 hehe... 17:44:39 probably about the time the ipv8 spec is released 17:45:14 ok, so thats 5 +1's 17:45:23 #agreed This feature is approved. 17:45:30 * jlayton cheers 17:45:31 thx! 17:45:32 #topic Feature: XZRpmPayloads - https://fedoraproject.org/wiki/Features/XZRpmPayloads 17:45:44 .fesco 169 17:45:47 nirik: #169 (Feature: XZRpmPayloads - https://fedoraproject.org/wiki/Features/XZRpmPayloads) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/169 17:45:54 thanks for coming jlayton. Sorry it was so short and boring. ;) 17:46:16 nirik: meh, no worries I hadn't attended one of these before 17:46:29 a request about that feature: 17:46:42 I'd really like to see step 6 (complete rebuild of the distro) dropped. 17:47:08 that kind of, uh, defeats the purpose, doesn't it? 17:47:15 I wonder how this affects presto/deltas? 17:47:20 as rpm is backward compatible and sitll understands the old compression we can just have the whole distro roll over "naturally" or wait for the next glibc rebuild to require a bump. 17:47:21 ixs: we're probably going to doing a rebuild anyhow due to the x86support feature. 17:47:27 and is the format finally stable? 17:47:51 nirik: deltarpm will need some work 17:47:57 but yes, the file format is stable 17:48:27 I'm glad to see f10 rpm should support this too... 17:48:29 notting: the xz format, not the lzma format, right? Just so that we're clear. 17:48:33 ixs: yes 17:48:36 but then there are the el machines/builders/etc 17:48:42 nirik: yup, the fileformat specsare final, upstream sais it won't change 17:48:56 s/sais/says/ 17:48:58 nirik: for el, you'd set the same flags you'd set for hases 17:49:02 erm, 'hashes' 17:49:32 i.e., for an EL-compatible rpm, you set two macros instead of one. 17:49:51 yeah. 17:50:03 test section should probably include testing that deltas work. 17:50:34 added 17:51:21 +1 to XZRpmPayloads feature. 17:51:41 +1 17:51:42 +1 here, it seems fine... the sooner it lands the better as always. 17:51:49 it may even speed up deltas... 17:52:29 +1 17:52:50 +1 17:52:58 ok, +1, this feature is approved. 17:53:06 #agreed This feature is approved. 17:53:13 #topic Open Floor 17:53:25 Thats all I had on the agenda... anyone have additional items? 17:53:30 #action notting - work with rel-eng around scheduling of potential mass rebuild for fedora 12 17:54:48 nirik: today we removed mcepl from sponsors, at his request. he had no sponsorees. 17:54:49 I guess this is the last meeting with this fesco? I'd like to say it's been fun to work with all you guys. ;) 17:55:23 * bpepple wonders what it will be like not having to attend a FESCo meeting? ;) 17:56:47 when specifically are they announcing the results? 17:57:03 yeah, sounds good... if someone doesn't want to be a sponsor they should feel free to step back. ;) 17:57:09 not sure. 17:57:46 Oh, I got an email from the gnaughty packager... he wanted fesco to address that package, but it's still blocking FE_LEGAL, so I thought we would wait until spot was back and specifically sent it to fesco. 17:58:13 nirik: that sounds good. 17:58:14 sounds reasonable. (i don't think it's a fesco issue) 17:58:43 ok, if no one has anything else I will go ahead and close things out in 60seconds. 17:59:00 one more thing 17:59:09 * nirik waits for notting 17:59:14 who is responsible for doing the housekeeping for added & removed fesco members after the elections? 17:59:27 (group, mailing list, etc.) 17:59:29 notting: on the fesco page. usually the chair. 17:59:47 I can do it as a leaving gift. 18:00:04 :) 18:00:07 heh, ok 18:00:14 bpepple: I hope you will continue to be active in fedora... 18:00:53 nirik: I will, though I haven't had much free time the last 6 months or so. 18:01:01 i hope bpepple will make an appearance at OLF 18:01:01 yeah, time is always an issue. ;( 18:01:10 ok, will go ahead and close out in 60 18:01:14 Southern_Gentlem: plan to be there. 18:02:12 #endmeeting