19:35:11 #startmeeting FESCO (2010-06-15) 19:35:11 Meeting started Tue Jun 15 19:35:11 2010 UTC. The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:35:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:35:17 #meetingname fesco 19:35:17 The meeting name has been set to 'fesco' 19:35:36 #chair mjg59 mclasen notting SMParrish_mobile ajax pjones cwickert 19:35:36 Current chairs: SMParrish_mobile ajax cwickert mclasen mjg59 notting pjones 19:35:52 We're missing kyle and nirik 19:36:01 #topic init process 19:36:05 zodbot uses LC_COLLATE=en_US . Ew. 19:36:13 kyle said he might not make it (still in UK) 19:36:20 Yeah 19:36:22 Ok 19:36:30 #info kylem and nirik unable to attend today 19:36:37 Ok, shall we start? 19:36:47 #topic #351 Create a policy for updates - status report on implementation 19:36:48 oh, wait, I'm backwards. 19:36:50 .fesco 351 19:36:51 mjg59: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:37:02 Anyone got anything to say on this this week? 19:37:15 no change on my end from this week. jlaska was doing some critpath documentation 19:37:51 Anyone else? 19:37:57 did lukes bodhi update happen ? 19:38:06 lmacken: Around? 19:38:10 * mclasen should know this, but doesn't... 19:38:17 notting: feel free to make suggestions, I'm missing important critpath information for maintainers -- http://fedoraproject.org/wiki/Critical_Path_Packages 19:39:06 * mclasen will look it over after the meeting too 19:39:32 * cwickert is here... 19:40:02 mclasen: thx 19:40:18 #action mclasen to look over critpath documentation 19:40:33 Anyone else? Or shall we move on? 19:40:57 (going once.. twice...) 19:41:12 #topic #382 Implementing Stable Release Vision 19:41:13 * cwickert thinks that the KDE list of critical path is way to short 19:41:34 cwickert: We've had that conversation - unfortunately it seems difficult to come up with a better one that doesn't cover pretty much the entirity of KDE 19:42:18 And an overly broad critpath would likely serve as a deterrent to maintainers at the moment. If KDE ends up looking bad compared to the rest of the distribution, then with luck that's something they'll pay attention to 19:42:32 mjg59: well, the Xfce critpath covers half of Xfce, the LXDE one too 19:42:44 cwickert: sure, but those are both smaller than kde, right? 19:43:07 yes, but the percentage is way higher 19:43:12 anyway, lets move on 19:43:45 Ok, so we have the wiki page at https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas 19:43:56 We haven't really added much to that 19:44:29 I'm not convinced that IRC is the best way to discuss adding ideas, but a private mailing list also doesn't seem reasonable 19:44:43 Think I added something to it 19:44:49 Maybe people could just scribble some more stuff in there and annotate it on the discussion page if necessary? 19:44:57 It'd be nice to have something to bring to the board at some point 19:45:05 (Yeah, I know that I'm guilty here) 19:45:26 sorry for the stupid question, but I was away for the last weeks... what about the "only security updates and bugfixes" rule? are we trying to drive our users away from Fedora? 19:45:56 that's a bit of a bait-y question, but. 19:45:58 cwickert: you get the minus points for assuming bad faith. 19:45:58 here's the thing 19:46:32 if releases are continuously updated with new features, then what is to distinguish them from rawhide 19:46:37 I mean, new versions in a release are one thing that makes us different from the rest of the distributions and according to several polls, users want this. IMO this is a completely different issues from bad/no testing and low quality 19:46:53 cwickert: you skipped "far too many updated packages" 19:47:15 pjones: "too many" for whom? 19:47:21 for users? 19:47:39 If I obeyed packagekit I'd be rebooting my desktop machine 3 times per day for all of F13. 19:47:43 if the users want the updates, then it cannot be "too many" 19:48:01 strange, I only once a day if at all. 19:48:05 people for whom software updates are not the central piece of their fedora experience and interest 19:48:15 Wait. Hang on. 19:48:25 "Stable releases should not be used for tracking upstream version closely when this is likely to change the user experience beyond fixing bugs and security issues." 19:48:26 mclasen: updates are an offer, not a duty. 19:48:30 (also, this is far off topic at the moment) 19:48:31 This is from the Board's statement 19:48:46 mjg59: right. it's not up for discussion. 19:48:48 It's a position we've been asked to implement 19:49:04 mjg59: you have the link to the boards statement? 19:49:08 cwickert: until the next security update pulls them all in... 19:49:09 i last updated on 06-05. i have 141 updates waiting. 19:49:10 https://fedoraproject.org/wiki/Stable_release_updates_vision 19:49:19 cwickert, too many updates that add new features are not a good user experience 19:49:30 We've had this discussion many times now 19:49:36 I don't think there's a great deal we can add to it here 19:49:43 specially as it is, imho, more important to make sure our current stuff works 19:49:44 LinuxCode: again, this is your definition of "too many" updates 19:49:51 The Board have taken a position, and we get to implement it 19:50:02 cwickert, updates are fine, as long as they dont add too many new features 19:50:04 LinuxCode: making sure stuff works is a completely different issue 19:50:09 If we disagree with that position then we're free to tell them that we disagree, but unless they change their mind then we still get to implement it 19:50:22 cwickert, agreed 19:50:25 mjg59, yeh 19:50:29 But I don't think that this is the right place to have that conversation 19:50:34 LinuxCode: but the users WANT the new features, that's why they use Fedora and not Ubuntu, SUSE and whatnot 19:50:53 lets not repeat that discussion here and now 19:50:57 derail: success! 19:51:02 mjg59: unless we want to take the position that 'fesco refuses to work on it'. which, as of the last couple of meetings, we are *not* taking that position. 19:51:13 notting: Right 19:51:21 cwickert: that's a reasonable position, but i think what we're aiming for there is "if you want that, use rawhide" 19:51:41 ...or the branched release, if any 19:52:09 But in terms of the implementation, does anyone want to add anything at this point? 19:52:26 Or shall we just try to be better at sticking ideas in this week, and try to come up with a cohesive plan? 19:53:38 Ok, moving on? 19:54:02 one question and I will stop arguing. what abput parrot and rakudo for example. people want the monthly updates and they want it on a stable release and not in rawhide. what about these kind of updates? 19:54:21 cwickert: One option is to provide separate repositories for well-bounded package subsets 19:54:32 Let people opt-in to more active updates 19:54:45 mjg59: we already have a yum plugin for that 19:54:46 cwickert: if there's an overwhelming reason for some specific case, put it on the agenda and we can discuss it as an exception to the normal process? 19:54:49 As long as there's little interaction between them and the rest of the distribution, that should be pretty safe 19:55:02 cwickert: that is, write a specific proposal for an exception to the process and put it on the agenda? 19:55:21 And, yeah, if it's the case that basically all users of a package are going to want updates, then maybe it'd be outside the bounds of the proposal 19:55:23 pjones: I have asked this several times, it was discussed and there was no solution. 19:55:40 cwickert: We're still very much at the stage of trying to brainstorm out an implementation 19:55:42 but you're asking vague questions, not coming up with a specific proposal 19:55:46 cwickert: there's an option for updates-features on the wiki page referenced above 19:55:57 notting: sounds fair 19:55:58 We're not trying to make anything impossible at this point 19:56:41 #action fesco to continue to update https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas and aim to produce a comprehensive policy for the board 19:56:54 Sound ok? 19:56:56 n 19:56:58 oops 19:57:04 mjg59: yeah 19:57:18 #topic #387 19:57:24 #topic #387 compile list of supported CPUs and react to recent loss of support for Geode LX on F13 19:57:27 .fesco 387 19:57:28 mjg59: #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:57:52 So by the sounds of it, this problem is due to the glibc spec file passing more aggressive optimisation arguments to the linker? 19:58:10 not the spec file 19:58:15 but jakub seems to be unwilling to change that 19:58:17 the hand-crafted Makefile system inside of glibc upstream 19:58:19 the configure script or somesuch, but yeah 19:58:28 dsd_: right 19:58:29 Sorry, right 19:58:35 assembler, not linker 19:58:40 and its assembler optimizations 19:58:45 well, the problem is more general, but the symptom is caused by the glibc scripting. 19:59:14 Right, so other than the facts I was entirely correct 19:59:31 Jakub makes a reasonable point that it's entirely plausible that gcc will start doing the same at some point 19:59:45 well, not during f13 one would hope 19:59:49 One would hope 19:59:57 and if it does, ... 20:00:01 So we can either "fix" the glibc build system 20:00:10 (Which the maintainer is unenthusiastic about, but still) 20:00:18 Or we can change to start building for 586 again 20:00:21 notting: what are we winning by chopping off 586? 20:00:35 actual performance gains, as i recall 20:00:39 We made a conscious decision to go from 586 to 686, so that doesn't seem immediately appealing 20:00:48 i presume that if we fix both F13 and F14+, we are talking about 2 separate fixes. which one are we discussing? 20:00:49 as a f13 hotfix, patching glibc seems reasonable to me; long-term, jakub's argument is right 20:00:57 And I don't think it's worth dropping back to 586 just to support a cpu that's genuinely a 686 20:01:07 mclasen: I'm leaning that same way 20:01:36 Yeah, I think we should just make the change in F13 20:01:53 which change? 20:02:02 dsd_: are you interested in coming up with a glibc patch we could review? (the glibc makefile change to avoid asm optimizations.) 20:02:05 And I think we should encourage the binutils and gcc maintainers to let us know if optimisation parameters will change the set of supported CPUs 20:02:05 so the story for f14 is... secondary arch? i586? 20:02:23 a decision to not fix this in the long term = a decision to drop support for the Geode LX in Fedora. 20:02:25 ajax: Well, it's also entirely possible that f14 won't change things 20:02:27 dsd_: make glibc not pass -mtune=i686 to as 20:02:32 cjb: yes, its a trivial patch that i can make this afternoon 20:02:41 Guest13239: excluded middle, boo. 20:03:33 it's ok to decide that, just be aware of what you are deciding. 20:03:40 Guest13239: Correct, a decision not to support machines that don't implement 686 nopl is a ecision to drop Geode LX support 20:03:46 I don't think that it is right to do something because upstream will do it "at some point". we have a policy to follow upstream, but this means to honor upstreams decision and not to go ahead. dropping the support for the geode would be a shame as long as the OLPC is our largest deployment 20:04:11 mjg59: which is not the same as "build two, one for 586 and one for 686" 20:04:13 which is my point 20:04:19 cwickert: I'm not sure those numbers will stand up to scrutiny, but I agree with the sentiment. 20:04:22 In F12 the decision was explicitly made to drop the i586 but to retain the Geode LX. That is the decision that's being considered for revision if no fix is put in place for this bug. 20:04:33 Guest13239: yes, we know. 20:04:44 have we discussed with kylem and davej the possibility of carrying the emulation patch? 20:05:00 not really; last week we all pretty much all thought that was a non-started 20:05:00 Guest13239: ...we're explicitly talking about fixing this bug. 20:05:03 especially upstream 20:05:44 notting: upstream first, yadda yadda 20:05:56 we *do* carry the occasional patch, though 20:05:59 yeah 20:06:04 davej: any thoughts? 20:06:14 notting: according to https://bugzilla.redhat.com/show_bug.cgi?id=579838#c15 , this particular patch is very not a good idea. 20:06:16 (sorry, i have to drop off. will read scrollback) 20:06:21 notting: Thanks! 20:06:45 I tried to get it upstream a while back, but it turned into a wankfest of "we should generically support missing instructions" 20:07:24 Yeah, upstream has ideas about how they want this done 20:07:33 and it's a non-trivial amount of work 20:07:34 In theory it could be integrated with the kvm instruction emulation stuff 20:07:48 in practice maybe it'd be nice to have something that works instead. 20:07:59 you'd think that, but people suck 20:08:19 note that "works" doesn't really describe the emulation patch, since it's turning a NOP into a gigantic kernel trap. 20:08:39 and just like the kernel people don't like emulation, the toolchain people probably don't like a new IS for geode ? 20:08:52 mclasen: it's not geode only. 20:08:52 cjb: well you could always fix mmap(PROT_EXEC) to hunt for NOPL and patch... 20:08:59 (note: do not do this) 20:09:40 ajax: I think I just threw up a little. 20:09:56 pjones: there's pepto in the break room 20:10:22 * LinuxCode gets a glass of water for pjones 20:10:38 so: do we want to carry this patch (or a similar one) for f14, or do we want to drop geode from f14, or do we want to do something else to support geode in f14. 20:11:00 it seems like there's a better glibc fix we're missing in this discussion 20:11:51 but maybe there's not. 20:11:58 i can't really think of one. 20:12:07 I dunno, something that doesn't involve switching the definition of i686 every 10 minutes. 20:12:14 Is it worth lobbying for a "586+cmov" gcc and binutils architecture? 20:12:27 mjg59: that's never worked before... 20:12:34 pjones: to include an undocumented instruction that isn't in the spec. :/ 20:12:40 last week it was pointed out that geode LX does not support all types of cmov 20:12:41 cjb: exactly. 20:12:49 pjones: i think they've actually been pretty consistent, as long as you consider 686 to mean Pentium Pro 20:12:54 dsd_: is that actually an issue? 20:12:58 (another reason to stop pretending that geode LX is i686, in my opinion) 20:13:02 (do we emit any of the unsupported types?) 20:13:05 cjb: not sure.. and if it isnt, it might be in 6 months time 20:13:27 dsd_: seems separate to me.. I've never seen any problem with that. 20:13:30 Well, in any case. Are we decided on what to do for f13? 20:13:55 cjb: similarly Fedora worked up til F13, and now we have a problem. same could happen again 20:14:31 would it not be possible to just freeze glibc in terms of version ? 20:14:31 dsd_: (it could, but we don't have any evidence that it will from the last couple of years, so it's hardly likely.) 20:14:39 i think we were pretty clearly unanimous for f13: patch glibc. 20:14:42 just throwing this in 20:14:44 mjg59: sounds like dsd_ comes up with a patch and attaches to the bug 20:14:55 dsd_: that can always happen; best prevention against that is continuous integration 20:14:56 Yeah 20:15:01 i'll make that patch this afternoon 20:15:07 So then, there's a question for the long term 20:15:21 LinuxCode: not terribly effective. 20:15:21 We can't guarantee that this won't happen again unless we revert to i586 20:15:25 pjones, i see 20:15:32 just a wild idea 20:15:55 and it sounds like we do not want to revert to 586 for the distro as a whole. 20:15:58 mjg59: it sounds like none of us actually want that to happen :) 20:15:58 Right 20:16:18 yeah, I think we all agree that's generally undesirable. 20:16:22 so i'm just going to throw that whole "secondary arch" thing out there again 20:16:47 we haven't had one since ppc fell off the map, really. 20:16:47 I haven't figured out what's undesirable about 586 support. Tossing whole architectures over the wall to get a <1% speedup never struck me as wise. 20:16:50 So from my point of view, Geode developers get an emulation patch upstream, Geode developers get a geode architecture into gcc and binutils or we do secondary arch for i586 20:17:09 ajax: all of 32-bit x86 ? We've got no precedent for subarches as secondaries, and that might be... complicated. 20:17:14 don't we have some way to install IS-variants of libraries, anyway ? like no-mmx variants, etc 20:17:22 * mclasen fuzzy on how that works 20:17:39 mclasen: it's not especially clear, period. 20:17:45 mclasen: that's a good question - could we not do an i586 glibc? 20:18:05 pjones: Sure, but any other package that passes the same build options may hit the same issue 20:18:09 which would be fine unless kernel (or other things) start using the flags that get them nopl 20:18:09 * gholms rings the 20 minute bell 20:18:09 pjones: if gcc starts invoking gas with -march... 20:18:27 ajax: yeah 20:18:30 vote to continue (+1 from me) 20:18:34 +1 to continue 20:18:36 continue 20:18:51 continue 20:18:56 ajax: I think the gcc issue there might be a "ask them to not do that" and/or "kill that horse when we come to it" sortof thing. 20:18:58 Continue 20:19:43 that's four (dsd doesn't count, not fesco, sorry dude). but i'll take it as majority since we're short. 20:19:57 pjones: they're going to balk at that. every 0.1% on specint... 20:20:08 ajax: and anything else in userland gets to make a choice of "don't do that manually" or "also ship a i586..." 20:20:15 ajax: I'm still talking about F13 here 20:20:26 F14 may need a differently nuanced answer. 20:21:09 pjones: fair. we _could_ potentially do an i586 build of glibc for f13; we did it before, after all. 20:21:18 I think it's reasonable to ask gcc not to randomly switch stuff like that intra-release. 20:21:40 and i think that's actually a point in favor of subarch as secondary arch; yum knows that if you installed i586 it's probably because you meant it and can't do i686 20:21:40 yeah, stable updates, and all that... 20:22:03 ok. so would we apply dsd's patch to F13 and F14, pending a better outcome? 20:22:21 (I mean, F13 and devel) 20:22:50 f13 certainly. not sure devel is necessary yet. 20:22:55 ditto ajax 20:23:30 so maybe we should be discussing subarch secondary for F14 20:23:33 ajax, but would you push the packages into the same repos for i686 ? 20:23:39 but let's discuss F13 to completion _before_ we get on that. 20:23:55 LinuxCode: we certainly could. 20:24:05 IMHO F13 is most important, but if we want to encourage the OLPC folks to continue developing on Fedora, we need F14 as well 20:24:05 might make it more transparent 20:24:07 pjones: i think we _ought_ not, but we could. 20:24:32 ajax, question is if that technically works 20:24:47 alright then, f13 proposal: patch glibc to not emit nopl because geode lx is supported in f13. 20:24:52 (+1 from me) 20:24:57 +1 20:25:02 +1 20:25:02 +1 20:25:16 s/glibc/gcc/ no ? 20:25:26 davej: no because right now only glibc does it. 20:25:31 ugh 20:26:01 +1 20:26:15 +5, majority, motion carries. 20:26:17 so! f14. 20:27:06 F14 ... um... shit. 20:27:12 i don't think 586 belongs in the same repos as 686 anymore. the isos and boot images would conflict. 20:27:36 or you'd build them out of 586 and then something would have to figure out if you could do real i686 20:27:40 and that's dumb too 20:27:51 Is asking olpc to (help) maintain a secondary arch that's essentially "i686 + i586 rebuilds of anything that doesn't work as i686" going to cause them to run screaming to debian? 20:28:00 it's probably not all that much work... 20:28:05 pjones, hehe 20:28:14 Well, we should probably do a better job of documenting what building a secondary arch involves 20:28:19 they didn't seem enthusiastic last week... 20:28:53 pjones: if gcc changes to invoke gas with optimizations, "anything that doesn't work" is "everything" 20:28:53 Bootstrapping from 686 should be trivial - the only real problematic case I can think of is static libraries 20:28:53 pjones: (speaking as OLPC community member) i dont think anyone at OLPC has that experience. also OLPC resources are veeeery tight. 20:28:58 what kind of work is involved? 20:29:05 ajax: yes, but it's really simple rebuilds 20:29:09 jwb: You around? 20:29:27 mjg59, will be in a bit 20:29:41 dsd_: basically rebuilding every package inside an i586 mock builder and then doing a compose. 20:29:44 if i may make a comment as a debian user :) while i would welcome olpc users i can also share our solution: debian is 486+ but we allow optimized libs in e.g. /lib/i686/cmov/libc.so.6 20:29:48 jwb: Ok - we were just curious as to the amount of effort you'd guess would be involved in running 586 as a secondary 20:29:59 Would that proposal be similar to ppc64's being "ppc, with 64-bit exceptions?" 20:30:00 dsd_: I think spot + dgilmore have more details that make that a lot easier than I just made it sound. 20:30:13 mgoetze: thats the is-variant-libraries thing I alluded to earlier 20:30:15 gholms: unless gcc changes the options it passes to gas, yes 20:30:25 (koji-shadow can make it easier, aiui) 20:30:27 i'm quite ignorant about the Fedora infrastructure, but wouldnt this be trivial to do on the official koji side? 20:30:30 mgoetze: doesn't help for forbidden instructions in apps or kernels, though... 20:30:38 just adding 1 more build profile with 1 little change of -march flag 20:30:41 mgoetze: the "sunos 2.5" solution, eh? 20:30:56 mclasen: the question is, how badly do you need these optimizations... 20:31:03 mgoetze: think about openoffice 20:31:09 dsd_, but somebody still has to glance over things to make sure packages have built 20:31:20 mgoetze: We did some work on this in a previous release and decided it was worth it 20:31:29 dsd_: yeah, for i586 you wouldn't need to set up your own builders 20:31:32 LinuxCode: ok, the "glacing over and testing" can certainly be left to OLPC community 20:31:41 dsd_: the only issue with doing that (besides storage, which we may not have to burn) is that primary arches are mandatory for build success. 20:31:58 so a build failure on i586 would mean no update for any arch 20:32:09 ajax: sure, but the number of build failures that are i586 vs i686 only is going to be /fairly/ low. 20:32:16 i would suspect it would be tiny 20:32:16 puts a bigger burden on maintainers 20:32:22 pjones, yeh 20:32:28 minimal 20:32:29 So in the worst case scenario that i686 nopls become common, we're faced with two options - kernel emulation and a secondary arch, right? 20:32:31 we're talking about a pretty safe change, in my opinion 20:32:32 ajax: a x86 variant is not going to be a big issue for build failures, compared to ppc, no ? 20:32:38 mjg59: i mean would it still be good enough if you only have it in certain important/performance-critical libs 20:32:38 it's not going to be like sparc or ppc where helper binaries take a shit with a bus error 20:32:42 and fedora already shipped for a while with -march=i586 20:32:46 mclasen: exactly 20:32:48 pjones/mclasen: agreed, not likely to cause new failures. 20:32:48 * mgoetze goes back into his debian corner now :) 20:32:49 mgoetze: There's several binaries that matter 20:32:49 dsd_, well, if infra has capacity 20:32:54 mjg59: I think you'd take a performance nose-dive if you were emulating them *and* they were everywhere. 20:33:04 so 20:33:05 the storage thing is pretty real though. 20:33:14 ajax: yeah. 20:33:16 if you mean a full secondary koji instance 20:33:16 cjb: Yeah, so if that's a problem then an arch rebuild would seem to be it 20:33:21 Oxf13: hey, do you know anything relevant here? 20:33:34 jwb: then you could koji-shadow, right? 20:33:39 it's not trivial. there is setup, hardware, shadowing, and then doing the releng aspects all on your own 20:33:44 jwb: I think we just need to auto-rebuild them in the normal koji instance. 20:33:47 + mirrors 20:33:59 cjb: at best, you could fix up every page where you find nopls, as you hit them. so you'd only take the trap the first time. but that's a full disassembler in the kernel... 20:34:01 cjb, koji-shadow helps but it is not a perfect solution 20:34:02 jwb: they should build fine on x86 builders, after all 20:34:25 ajax: nod. 20:34:29 pjones, you mean reuse existing koji as a secondary instance? 20:34:36 jwb: yeah, basically 20:34:40 koji can't do that 20:34:40 *twitch* 20:34:43 builders talk to one hub 20:34:56 are we decided against adding i586 as a primary arch? 20:34:58 right, we don't have ways of having builders talk to multiple hubs, or having multiple builders on a single machine 20:35:00 I don't mean "set up another hub" either. 20:35:08 pjones, then you mean primary 20:35:13 dsd_: I think that's gone as an assumption so far. 20:35:19 i understand the concerns about storage on the current infra. apart from that, it would be a really good option i think 20:35:28 I think a whole lot more easier for all involved parties would be to revert back to i586 as main architecture 20:35:28 koji doesn't have the concept of 'primary/secondary' at the hub level 20:35:30 i am admittedly talking from the sidelines though, you guys are the expects 20:35:33 We could add i586 as another build arch, which would mean another compose arch and.... 20:35:44 what was this talk about 'subarch' earlier ? 20:35:59 is that a variant where we don't build everything, but only stuff that needs it ? 20:36:00 Oxf13: could we do it as another build arch without doing it as another compose arch? and then let them handle compose as a secondary arch? 20:36:02 mclasen: If we could just provide a subset of packages that were built with 586 20:36:04 do we have that capability ? 20:36:08 mclasen: Except that's potentially "everything" 20:36:18 you can't predict the future... 20:36:30 if it turns into everything, subarch turns into secondary arch... 20:36:31 pjones: maybe. I'm a bit fuzzy if we can have i586 and i686 show up as two completely separate arches 20:36:43 mclasen: no, but it stands to reason that there's a fairly high chance it'll turn to "everything" 20:37:07 mclasen: i think "subarch" before was being used in the sense of "rpm's notion of i686 being a superset of i586" 20:37:08 * gholms rings the 15-minute bell 20:37:27 ajax: mclasen: yeah, ajax is right about what I meant when I said "subarch as a secondary" 20:37:30 problem with doing i586 and i686 is that everything will end up getting the i686 rpms in teh buildroot and thinsg taht get statically linked will link against i686 and not i586 objects 20:37:34 i think we have things we need to know before we can move on: 20:37:40 (ie, decide on f14) 20:37:52 - whether we can do 586 and 686 separately within koji as primaries 20:38:02 - what running a secondary would really entail 20:38:09 - what the storage requirements would be 20:38:23 I concur. we need to do some fact-finding and revisit f14 next week 20:38:26 so i move to _not_ continue, and come back in a week with more info 20:38:32 Yeah, that sounds fair 20:38:41 sounds right to me too, thanks. 20:38:43 ajax: reasonable. 20:38:43 Anyone disagree? 20:38:44 who are we expecting to do this work? 20:38:45 (i won't be here next week, but that just makes it not my duty) 20:38:52 I won't either. 20:39:04 * gholms reminds mjg59 that the minutes still need an #agreed for f13 20:39:16 ajax: we cant do them seperatly in a single koji 20:39:26 * mclasen is willing to do some digging 20:39:30 #agreed dsd_ to post a patch to disable 686 assembler optimisations for glibc for f13 20:39:49 Thanks 20:39:52 mclasen: thanks! 20:40:00 thanks mclasen 20:40:17 (i'm testing the patch now) 20:40:18 #agreed more research on the details of building i586 separately to be carried out before deciding on f14 20:40:26 Everyone ok? 20:40:40 Yep, thanks for your time, all. 20:41:01 Ok 20:41:05 maybe we should add to ajax's list of things we need to know: - do gcc plan to change that switch by default? 20:41:18 #topic #394 F14Feature: MeeGo 1.0 https://fedoraproject.org/wiki/Features/MeeGo_1.0 20:41:35 * LinuxCode gets big eyed 20:41:49 pjones: (Jakub kinda threatened it in the bug -- "gcc should switch to telling as to use i686 optimized code for -march=i686, so all packages will eventually have i686 nops.") 20:41:51 Looks fine to me. Anyone have any concerns? 20:42:10 cjb: oh, pooh. 20:42:27 * mclasen is a bit dubious on this kind of feature in general 20:42:38 fedora is an OS, meego is an OS 20:42:47 meego-in-fedora is what ? 20:42:53 is this referring to Intels new chips or something ? 20:42:54 mclasen: likewise, but at the same time: so what? why stop them? 20:42:55 A trademark violation? 20:43:13 a sub OS ;) 20:43:16 * LinuxCode is confused 20:43:18 yeah, don't mean that as stop-energy 20:43:39 It may have to be something like "Fedora 14 implements the Meego software platform" or some such 20:43:42 just some lingering doubt about features that don't necessarily enhance fedora, but replace it 20:43:56 LinuxCode: this is a merger of moblin and maemo has nothing to do with "new chips" 20:44:02 drago01, I know 20:44:07 mclasen: they're talking about the "MeeGo Netbook UX", which is just a UI, I think. 20:44:20 I was just confused, why thats there in the first place 20:44:43