| --- jds2001 has changed the topic to: FESCo meeting --init | ||
| jds2001 | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| * nirik is here. | ||
| sharkcz here | ||
| * bpepple is here. | ||
| jds2001 | hmm, any reason no one else is here? | |
| bpepple | jds2001: they saw the agenda? ;) | |
| jds2001 | hehe :D | |
| jds2001 | well i guess with notting here we have enough to get started, even though I don't like having just 5..... | |
| jds2001 | ahh, theres #6 :D | |
| sharkcz | jds2001: I pinged notting and j-rod in internal irc | |
| jds2001 | sharkcz: thx | |
| j-rod | (fwiw, I'm over on #fedora-devel and #fedora-kernel most of the time too) | |
| but thank you sharkcz :) | ||
| sharkcz | j-rod: np | |
| --- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets | ||
| jds2001 | .fesco 28 | |
| zodbot | jds2001: #28 (Stronger Hashes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/28 | |
| jds2001 | any questions for mitr on this? | |
| jds2001 | where are we with it? | |
| nirik | mitr: is there any update on the status? thats a low % and hasnt been updated in a while | |
| * nirik doesn't like the 'no preupgrade from f9->f11'. thats going to bite a lot of people. | ||
| mitr | nirik: There are way too many packages to ever get 100% :) | |
| bpepple | nirik: yeah, I find that a little troubling, too. | |
| notting | can we push a rpm update for f9 w/the hash change backported? | |
| mitr | nirik: The difficult (RPM-related) parts are almost done: patch for rpm exists, createrepo/yum use SHA-256 already, a patch for koji exists as well. | |
| notting: panu said we can't. | ||
| jds2001 | is it possible for F10? | |
| then we hold off on this til F12? | ||
| so that we can upgrade from lowest maintained -> current? | ||
| * notting takes the action item to harass panu | ||
| jds2001 | er, preupgrade | |
| nirik | I assume since it's rpm, that would also apply to yum upgrades... | |
| mitr | Right. | |
| jds2001 | like it or not, lots of folks do yum upgrades. | |
| nirik | any status on rsync/scp or backup tools? I don't see any of those on the tracker bug. | |
| mitr | scp probably already supports this, only needs non-default configuration. | |
| rsync does not support SHA-256, that's #483056 | ||
| bacula supports SHA-256 for verifying restored backup files, amanda doesn't do any verification AFAICS. | ||
| notting | mitr: if the backport's too big, why not push back 4.6 with some config changes? | |
| mitr | notting: I didn't think of that and didn't ask. | |
| nirik | or can we do everything but rpm for now, and then push the rpm change as jds2001 said in a later release? | |
| mitr | notting: I assume the stricter rpmbuild (--fuzz 0) could be a problem. | |
| notting | mitr: that has to be configurable | |
| mitr | nirik: That's possible. | |
| jds2001 | it's configurable in a spec, so should be fine in /etc/rpm/macros or whereever | |
| nirik | well, I am all for this feature, but I would like to find a way to not mess up preupgrade/yum upgrades from f9... | |
| jds2001 | same here, but not sure how to vote like that :D | |
| nirik | how about we defer and mitr works on some way to make that happen and we revisit next week? mitr: would that be ok? | |
| the release notes need a note about the .rpmnew thing for sure. | ||
| * j-rod likes nirik's suggestion | ||
| mitr | nirik: I'd prefer immediate approval of course :) but it is probably a good idea. | |
| jds2001 | oh, I almsot forgot - nirik your turn for summary this week :) | |
| mitr | nirik: A release note is on my todo list already. | |
| nirik | jds2001: oh. ok :) | |
| sharkcz | +1 to nirik's suggestion | |
| jds2001 | +1 to nirik's suggestion, defer til next week. | |
| bpepple | +1 here also to nirik's suggestion. | |
| notting | +1 to defer | |
| nirik | +1 also to my suggestion. Oh wait... :) | |
| jds2001 | i see five +1's that we defer to next week, so I'll keep it on the schedule. | |
| jds2001 | .fesco 36 | |
| zodbot | jds2001: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36 | |
| bpepple | +1 to ArchitectureSupport Feature. | |
| notting | any questions? | |
| jds2001 | dgilmore had a concern that this would break the XO. I'm not 100% clear on that. | |
| notting | dgilmore brought up XO - cjb told me that it should work OK with i686 packages | |
| * nirik notes this will be unpopular with the i586 folks, but it's not clear how many there are. | ||
| jds2001 | but afaik it lacks things like mmx? | |
| sharkcz | XO is now using the i686 live image | |
| jds2001 | ok. | |
| notting | jds2001: as there are eleventy-billion separate 32-bit streaming instructions, i don't think gcc emits them by default | |
| (mmx, sse, sse2, sse3, whatever-the-amd-ones-are) | ||
| jds2001 | cool, +1 here then. | |
| abadger1999 | Two years ago the i586 folks were talking embedded. | |
| *embedded systems | ||
| notting | abadger1999: going by the stats we have available, the i586 userbase is miniscule | |
| abadger1999 | <nod> | |
| nirik | I have some i586 machines here... but they are off in the garage awaiting recycling. ;) | |
| bpepple | less than 1% wasn't it? | |
| jds2001 | but embedded probably wouldnt show up in any of those stats | |
| * abadger1999 gets ready to junk his three old i586 boxes. | ||
| notting | bpepple: much less. .04% | |
| notting | (of active hosts) | |
| nirik | anyhow, +1 from me... | |
| sharkcz | +1 | |
| bpepple | reaffirms his +1. | |
| jds2001 | i think this might be unpopular among the "ZOMG Fedora only support new hardware!" crowd. | |
| but +1 anyways | ||
| notting | +1 from me | |
| * nirik notes there will be yelling from alan cox most likely. | ||
| notting | jds2001: 'new' is a relative term here :) | |
| jds2001 | notting: :) | |
| sharkcz | I got an i686 in '98 ... | |
| notting | yeah, my first was in '97 | |
| jds2001 | i see five +1's, so we've approved the architecture support feature. | |
| unrelated, it may lead to lots of queries in #fedora/etc about x86_64 kernels on i686 installs. | ||
| sharkcz | and anybody can start i586 as secondary arch | |
| nirik | notting: this will require a mass rebuild? | |
| notting | nirik: yep. and if we decide to undo it, will require another :/ | |
| jds2001 | yes, but a few other things on the agenda today will too. | |
| * davej gets ready to nuke the 586 kernel from orbit. | ||
| bpepple | nirik: I think we're already going to be doing one for the new gcc anyway. | |
| nirik | notting / bpepple: yeah, just want that all to get coordinated to have just the one. ;) | |
| notting | exactly, wanted to make sure to get this approved/disapproved before we start the gcc4.4 mass rebiuld | |
| bpepple | nirik: right. | |
| jds2001 | yep. | |
| jds2001 | .fesco 37 | |
| zodbot | jds2001: #37 (Crash catcher - https://fedoraproject.org/wiki/Features/CrashCatcher) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/37 | |
| jds2001 | where are we on this, 10% looks worrisome. | |
| nirik | is CrashCatcher already in? or under review? or not yet written? | |
| jds2001 | and how does it actually work, out of curiosity? | |
| notting | it's in-progress | |
| jmoskovc` | yes, we already have some code | |
| notting | (there's a lot more detail on the fedorahosted page) | |
| jmoskovc` | and we are abel to detect a crashing C program and show an systray icon | |
| *able | ||
| * dgilmore is here | ||
| jmoskovc` | I was trying to push it to fedorahosted today, but I had some difficulties with git :( | |
| dgilmore | notting: rpm correctly refuse to install i686 rpms | |
| notting | dgilmore: are you running the i586 kernel at the time? | |
| j-rod | crap, got side-tracked... tardy +1 to the arch change thing | |
| dgilmore | notting: whetever kernel olpc ships | |
| nirik | jmoskovc`: how usable is this going to be for f11? It sounds like you are in pretty early development... perhaps f12 would be a better target? | |
| dgilmore | notting: however the cpu is not i686 compatiable | |
| warren | Hi, I don't mean to be difficult here, but are you aware that i686 only effectively kills LTSP clients? | |
| I didn't know this was being voted on. | ||
| notting | dgilmore: cjb says it works | |
| jds2001 | warren: sorry for the late agenda. | |
| dgilmore | notting: he is wrong | |
| jmoskovc` | nirik: we should be able to get backtrace from core dump and send it to BZ (or somewhere) | |
| warren | jds2001: was it voted to drop i586 kernel and userspace or only kernel build? | |
| dgilmore | notting: there is a reason the rpm has a .geode rpm | |
| * nirik guesses this means we should revisit the i586 thing again? | ||
| dgilmore | notting: it sits between i586 and i686 | |
| jds2001 | yeah, lets go back :) | |
| notting | warren: if we drop the kernel, there's no point in keeping the userspace around | |
| nirik | jmoskovc`: is there any filtering on that? or it just always sends them? | |
| warren | notting: right | |
| dgilmore | the geode cpu is i586 + the cmov extention | |
| bpepple | how about we finish the CrashCatcher feature, and then go back Architecture feature? | |
| warren | Are we dropping i586 builds because it was adding actual maintenance burden? | |
| dgilmore | if we consider that to be i686 then rpm will need to be told so | |
| notting | dgilmore: what specific instructions? as he's the XO/OLPC software guy, i figured he has a handle on it | |
| jmoskovc` | nirik: yes there will be (at least we'd like to have it), we're goign to have a mtg with tools team to help us with duplicate checking of coredumps | |
| nirik | bpepple: +1 | |
| warren | notting: (looking back at the earlier conversation) stats wont include smolt reports from innumerable thin clients | |
| notting | warren: innumerable is a meaningless number without stats, though | |
| warren | notting: sure. | |
| bpepple | +1 to CrashCatcher feature. | |
| nirik | jmoskovc`: and would this be opt in or default? ie, would users need to go install CrashCatcher or are you saying it should be default installed? | |
| zprikryl | Hi | |
| * dgilmore wonders how it will report to Bugzilla | ||
| dgilmore | especially when the user does not have an account? | |
| jmoskovc` | nirik: the main idea was to have it as default in alfas and betas | |
| * dgilmore likes the idea, but wonders how it will work in practice | ||
| nirik | jmoskovc`: is there a package for it under review? it would need to be added into the collection, right? | |
| warren | jds2001: will fesco go back to discuss i586? | |
| jds2001 | warren: sure, when we're done with crashcatcher | |
| warren | jds2001: If this is a final vote, then LTSP and k12linux effectively ends with Fedora 10. | |
| zprikryl | dgilmore, you have to have a fedora account, anonymous reports will not be allowed | |
| dgilmore, bigzilla account | ||
| dgilmore | zprikryl: fedora account doesnt mean bugzilla account | |
| zprikryl: they are dispariate systems | ||
| jmoskovc` | nirik: ?? we dont have an rpm yet | |
| dgilmore | zprikryl: are we planning to make uses sign up for multiple accounts to use this system? | |
| s/uses/users/ | ||
| nirik | jmoskovc`: well, I am just worried that this is too early for f11... we already have passed Alpha... I like the idea a lot, I just don't know if it's ready for this cycle. | |
| jmoskovc` | nirik: me neither :) | |
| notting | warren: so, k12linux only supports 10-year old hardware? | |
| tibbs|h | s/only// | |
| warren | notting: most of the hardware people are still using today are i586 | |
| nirik | I would prefer it to get developed in this cycle and all working, then we can add it in early in f12 and use it for alpha/beta there at least... | |
| zprikryl | nirik, jmoskovc: imho we can finish version 1.0.0 :-).... but it will be hard | |
| warren | notting: and some of the top selling thin clients today are geode and another no-name brand of i586 | |
| notting | warren: *today*. so why would the project end? they'll be using better hardware tomorrow | |
| bpepple | jmoskovc`: will it be in a testable state by the Beta? | |
| nirik | I guess we could always do that later in this cycle if it's not ready. | |
| jmoskovc` | bpepple: beta is in March, right? | |
| nirik | http://fedoraproject.org/wiki/Releases/11/Schedule | |
| warren | notting: the clients outlive the server since software bloat on the server doesn't necessarily mean the client doesn't work anymore. | |
| nirik | jmoskovc`: march 3rd is feature freeze. | |
| bpepple | jmoskovc`: yeah, it would need to be in a testable state by March 3rd. | |
| jds2001 | so lets talk about one thing at a time. | |
| warren | notting: I would suggest dropping i586 only for F12+, to give a chance for CentOS6 to have one usable release for legacy hardware to be usable for a number of years thereafter. | |
| jds2001 | lets get back to crashcatcher, finish that, and then we can talk about architecture support | |
| jmoskovc` | zprikryl: can wa make it? | |
| zprikryl | jmoskovc`, I think so | |
| bpepple | I'm fine with approving this, and if it's not in a testable state by Beta we push it to F12. | |
| nirik | if you guys think you can, I am +1... we can always bump back to 12 | |
| jds2001 | yeah | |
| +1 here, review at Beta | ||
| j-rod | +1 to that as well | |
| sharkcz | +1 | |
| nirik | zprikryl / jmoskovc` : do remember to keep the feature page updated with your progress. ;) | |
| jmoskovc` | nirik: ok, we'll try :) | |
| notting | +1 to crashcatcher | |
| zprikryl | nirik, ok ok :-) | |
| jds2001 | i see five +1's, so we've approved the crashcatcher feature, and will review at beta. | |
| nirik | also you might get your rpm package into the review queue sooner rather than later... even if it's not too complete... so you can get it reviewed and in. | |
| jds2001 | ok, back to | |
| jds2001 | .fesco 36 | |
| zodbot | jds2001: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36 | |
| warren | Key question here... | |
| * nirik thanks zprikryl and jmoskovc` for coming and providing us info. | ||
| warren | Is i586 creating actual maintenance burden? | |
| dgilmore | so, while the geode cpu is i586 +cmov extention. it is technically not i686, but can run i686 optimised code as long as the only cpu extention used is cmov. | |
| bpepple | by keeping i586 in the kernel it's adversely affecting performance for the majority of our users. | |
| jds2001 | so i just booted my xo into fedora | |
| notting | it's an extra kernel, extra glibc, openssl, etc. builds. it pessimizes some bits of performance, it causes arguments on the mailing lists from people who think fedora should target older cpus (i'd argue that's not part of our mission) | |
| dgilmore | OLPC shoves i686 glibc and openssl on at image compose time. they are never upgradeable | |
| jds2001 | it claims it is Linux localhost.localdomain 2.6.27.5-94.fc10.i686 #1 SMP Mon Nov 10 15:51:55 EST 2008 i586 i586 i386 GNU/Linux | |
| dgilmore | jds2001: because it technically is i586 | |
| jds2001: but a big feature of i686 is cmov which the geode has | ||
| it just doesnt have the rest of the cpu instructions added in i686 | ||
| we can make rpm install i686 rpms on a geode | ||
| warren | oh, all RPMS will be rebuilt to .i686.rpm as well? | |
| dgilmore | im scared that we will end up using instructions that just wont work on a geode cpu | |
| we could also build everything .i586 and .i686 but the mirrors will kill us | ||
| notting | dgilmore: but if glibc and openssl don't (and they're built with -march=i686), why would other things randomly? | |
| dgilmore | notting: corner cases | |
| notting: and more likely with things the use multimedia based instructions | ||
| notting | things that use multimedia instructions that aren't using run-time tests are already broken, as you have different ones for amd and intel | |
| abadger1999 | dgilmore: Are you saying that OLPC builds glibc and openssl as -march=i586 and makes them nonupgradable or that they test the specifc i686 versions and then make those non-upgradable. | |
| dgilmore | notting: will optimising for i686 though turn off support for i586 checking | |
| notting | shouldn't... you have to do this stuff by hand anywaty | |
| dgilmore | abadger1999: im saying they shove fedora's i686 glibc and openssl packages in | |
| abadger1999: and rpm correctly refuses to update the rpms | ||
| abadger1999 | ah okay. | |
| warren | What exactly was voted upon earlier? | |
| warren | kernel/glibc/openssl only? Or all packages become i686.rpm? | |
| notting | warren: um, read the feature page? | |
| bpepple | warren: https://fedoraproject.org/wiki/Features/ArchitectureSupport | |
| nirik | https://fedoraproject.org/wiki/Features/ArchitectureSupport | |
| dgilmore | i think that there will be cases where fedora on the XO will blow up if its i686 only. | |
| but without trying we will not know | ||
| warren: the feature is for all packages | ||
| abadger1999 | warren: All packages. basically changes to default compiler flags | |
| nirik | so I assume adding a .i586 repo/branch/etc would be beyond pain? | |
| warren | nirik: yes. | |
| bpepple | nirik: yeah, the mirrors would probably revolt. ;) | |
| warren | nirik: effectively secondary arch | |
| dgilmore | nirik: we could have koji build everything for .i686 and .i586 and we could even not push the i586 and have it for a fall back in case things go bad | |
| but mirrors would be really really mad if we added all the i586 and i686 content | ||
| * nirik runs a mirror and wouldn't care... but yeah, I'm sure some would. | ||
| warren | I understand the benefits of doing this, I am just pointing out that the smolt statistics do not even come close to representing the scope of fedora hardware we will no longer be able to support. | |
| cebbert | this is just as bad as deciding to release only DVD images | |
| sharkcz | well, I still think that i586 as secondary arch is doable | |
| warren | cebbert: as kernel maintainer you don't mind building i586? | |
| dgilmore | sharkcz: its totally doable | |
| j-rod | hell, i586 probably has a better chance of flying as a secondary arch than any other currently-being-attempted secondary arch | |
| nirik | warren: is there some subset of packages that lstp uses? ie, not everything just X server/kernel? or ? | |
| cebbert | warren: I proposed we get rid of the 686 kernel and have only 586 and PAE kernels for 32-bit | |
| warren | cebbert: huh? | |
| nirik: generating list | ||
| sharkcz | cebbert: 686 <=> 586 ?? | |
| j-rod | i686 w/pae -> kernel-PAE | |
| i586 and i686 w/o pae -> kernel.i586 | ||
| dgilmore | i would like to see a fall back plan if .i686 optimisation fails on the gedoe | |
| notting | dgilmore: it's in the contingency section of the feature page | |
| warren | Could we please reconsider dropping i586 for F12 instead? I mean, why now? | |
| nirik | dgilmore: is there any way to test that without commiting ourselves? "some things might break" doesn't sound easy to test. | |
| mjw | sorry about the process question, but how long do these fesco meeting last normally? (waiting for our feature to be discussed before going to dinner) | |
| bpepple | mjw: 1 to 2 hours. | |
| dgilmore | notting: id like something inbetween | |
| jds2001 | mjw: 2 hours, but what feature is that? | |
| nirik | mjw: 2 hours... but we have a full schedule, so who knows? | |
| dgilmore | notting: like building .i686 and .i586 but ignoring the .i586 until we determine its needed | |
| mjw | 41, systemtap static probes. But I can stay it out another hour. OK. | |
| abadger1999 | So...Jakub's original email was very keen to move to -march=i486 but gave -march=i586 asan option. | |
| notting | dgilmore: that sounds painful | |
| jds2001 | mjw: we can do that next, should be fast i think. | |
| abadger1999 | Why not -march=i486? | |
| warren | abadger1999: hmm, something must have changed, it was his team years ago that said i386 instructions with i686 optimized code was faster than i586. | |
| abadger1999 | warren: I think that was -mtune | |
| Rather than -march | ||
| warren | nod | |
| abadger1999 | But I could be misremembering. | |
| warren | dgilmore: would building i586 and i686 for everything add a burden to storage and build servers? | |
| sharkcz | or gcc did changed | |
| abadger1999 | Jakub's message: https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01661.html | |
| * warren reads | ||
| dgilmore | warren: yes | |
| warren: it is effectively adding another arch | ||
| warren | Has FESCO considered Jakub's recommendation of -march=i486 or i586 instead of this? | |
| warren | That seems to be very reasonable, not a burden on infrastructure, and wont break geode. | |
| I mean Jakub recommended this for a reason? | ||
| notting | because fedora is about providing the latest free and open source software, and being a platform for innovation, and you don't innovate by pessimising for 10-year-old hardware? | |
| dgilmore | https://bugzilla.redhat.com/show_bug.cgi?id=200330 | |
| bzbot | Bug 200330: high, medium, ---, jakub@redhat.com, CLOSED RAWHIDE, i686 openssl broken on AMD Geode | |
| nirik | notting: 10 year old is an improvement over the current 15 or 20 year old? | |
| abadger1999 | notting: Well.... you do when the latest software is meant to take old, obsolete hardware and turn it into a productive, cost-saving computing environment for your school. | |
| tibbs|h | So finding a way to support scrap hardware no longer supported by Microsoft or Apple is explicitly not an innovation? | |
| warren | i486 or i586 for all packages sounds very reasonable. Could we please consider this for F11 and reconsider for F12? | |
| nirik | notting: how much benifit do we loose doing that? just i586 instead of i686? and drop i586 in f12? | |
| warren | notting: many popular thin clients selling today are still not i686, due to very low per-unit cost when they buy thousands... | |
| bpepple | abadger1999: but is Fedora the best choice for that? | |
| notting | ... why does leaving i586 in f11 help? | |
| (rhel5 does not ship a i586 kernel. rhel6 certainly won't) | ||
| tibbs|h | How does RHEL come into this? | |
| davej | warren: what cpu's typically are they using? | |
| nirik | true I guess... it does allow more time for 'upgrade your hardware or switch distros', but there will always be some that won't. | |
| abadger1999 | bpepple: Well... when I was working on ltsp I certainly wanted to run Fedora on them :-) | |
| * jds2001 notes that CentOS5 *does* ship an i586 kernel. | ||
| notting | tibbs|h: "<warren> notting: I would suggest dropping i586 only for F12+, to give a chance for CentOS6 to have one usable release for legacy hardware ..." | |
| jds2001 | I would guess due to folks wanting it? | |
| warren | davej: Vortex86 System on Chip (video and CPU and motherboard chipsets all on one die) at the low end and Geode GX2 or Geode LX. | |
| bpepple | abadger1999: yeah, but I always thought CentOS or RHEL with longer support cycles worked better for those types of installations. | |
| abadger1999 | bpepple: Usually, people wanted newer end-user apps.... the labs are desktop machines.... just run as thin clients. | |
| warren | bpepple: Thin clients tend to out live the servers. | |
| dgilmore | http://wiki.laptop.org/go/Geode_instruction_set | |
| notting | abadger1999: then the thin clients can still run an older release | |
| abadger1999 | bpepple: So we tried the CentOS based ltsp but customers were interested in Fedora or Ubuntu on the thin client. | |
| warren | notting: the current older release has kernel and X drivers from 2004. | |
| bpepple | abadger1999: yeah, I guess I'm projecting what I'd be willing to support if I was in charge of installing that. ;) | |
| notting | abadger1999: wait, they wanted newer end-user apps, so they wanted the thin client base to be newer? that makes no sense (or they misunderstand how thin clients work) | |
| warren | -march=i586 minimum is an improvement in of itself. | |
| sharkcz | warren: you want to have both client and server side be the same Fedora? | |
| notting | warren: if you hardware is that old....? | |
| dgilmore: that implies that -march=i686 should work, if the base CPU insn set is i686/ppro | ||
| dgilmore | notting: yes. but ive been told in the pas that is not true. and the cpu itself says its not true. as does the bugrepot i posted earlier | |
| notting: i think we need to get a more definitive answer | ||
| abadger1999 | warren: Please correct me if I'm wrong... the current ltsp build system builds the ltsp client from the current server packages, yes? | |
| warren | abadger1999: yes | |
| abadger1999: chroot is installed from the same fedora repo | ||
| notting | dgilmore: which was fixed, and shouldn't be an issue. interetsingly, it also says "In our benchmarking tests using the EEMBC benchmark, -march=i686 scored the highest" | |
| abadger1999 | notting: So that's the problem. In the olden days, the ltsp client and ltsp server could have been separated but these days, the ltsp build infrastructure ties them together at one level. | |
| warren | old LTSP had its own glibc, kernel and userspace built from source tarballs to build the chroot. Basically Linux from scratch. They abandoned that in favor of building the chroot from the distro's own packages. | |
| notting: RHEL6 will rebuild all packages to i686.rpm? | ||
| notting | warren: don't know. but if they're only building an i686 kernel, why wouldn't they? | |
| nirik | warren: would there be enough interested people in the lstp community to get i586 running as a secondary arch? | |
| abadger1999 | We didn't build everything with -march=i486 even though the kernel only supports 486+ | |
| * abadger1999 notes only 40 minutes left.... | ||
| bpepple | yeah, we need to resolve this. There's still a lot on the agenda. | |
| notting | want to table this for next week and have more discussion? | |
| bpepple | notting: +1 | |
| abadger1999 | Mass rebuild needs to block on this. | |
| nirik | notting: +1. More info on olpc would be good. | |
| warren | nirik: I decided in this past week that I achieved my goal with LTSP in Fedora and I'm moving on to other parts of the distro to prepare for RHEL6. LTSP will only pull upstream changes into Fedora from now on. I'm training an upstream developer to do fedora packaging. (I could use another Fedora developer to help survise.) It was my intent to let it coast in maintenance mode into a CentOS6 release which was the goal of my past year. | |
| abadger1999 | Just so people are aware of that too. | |
| bpepple | abadger1999: correct. | |
| I think the gcc stuff isn't ready for the rebuild yet either. | ||
| drago01 | there is one problem with this some people install 32bit because they want to use 32bit kernel modules (binary only stuff or ndiswrapper) | |
| but they can just install kernel.i686 from the repos | ||
| warren | nirik: CentOS6 based LTSP will likely be the last long term support release of this decade old design. If it has i586 kernel, then it can support pretty much all usable thin client hardware from the beginning of LTSP through modern intel/radeon supported by Fedora's modern drivers (modulo bugs). | |
| notting | drago01: i am... not concerned... about those users | |
| warren | nirik: So I suppose someone will go through the effort of rebuilding all RHEL6 packages as i586 for this, but it wont be well maintained therefter. | |
| notting | drago01: other people may feel differently, i'm sure | |
| jds2001 | warren: rhel5 didn't support i586 | |
| drago01 | notting: yeah and there is a workaround , but might be worth adding to the rel notes | |
| warren | jds2001: I know. | |
| bpepple | ok, let's table this for now, and bring the discussion to the mailing list, and plan to make a decision at next week's meeting. | |
| jds2001 | warren: the i586 support in centos5 was done by centos. | |
| warren | jds2001: but the feasibilty of doing it is very different if all packages are i686. | |
| jds2001 | warren: understood :) | |
| warren | If RHEL6 has decided on i686 everywhere then I don't care what Fedora 11 decides. | |
| nirik | well, there may be enough interest for those folks to make a i586 secondary arch... time will tell. | |
| * nirik has no idea what RHEL6 will do. | ||
| jds2001 | ok, let's table this for now, take discussion back to the last, discard the previous vote. | |
| sound reasonable? | ||
| warren | fesco's private list? | |
| jds2001 | no, of course not. | |
| nirik | fedora-devel ? | |
| jds2001 | yeah | |
| bpepple | warren: devel list should be fine, though I'm sure there will be a lot of noise about it. | |
| warren | alrighty. sorry about the disruption. | |
| I totally understand the desire and benefits of this. | ||
| jds2001 | alright, let's get the systemtap folks able to eat dinner :) | |
| jds2001 | .fesco 41 | |
| zodbot | jds2001: #41 (SsytemTap Static Probes - http://tinyurl.com/btqjno) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/41 | |
| bpepple | warren: np. | |
| notting | sorry, be back in 5-10. question - you have to patch your userspace to support this? | |
| jds2001 | yeah, you have to put .d files in aiui | |
| mjw | notting, yes, a user space package needs to be recompiled to support it. | |
| jds2001 | just recompile, or put instrumentation in and recompile? | |
| fche | the instrumentation is already in there - we just need to activate it | |
| nirik | mjw: are you going to have this testable by feature freeze? still at 5%? | |
| mjw | So, we will be providing patches for packages that want to support it. For example for postgres to support this we will supply a patch for the spec file to add BuildRequires: systemtap-sdt-devel and a configure --enable-dtrace | |
| nirik, yes, we certainly plan to. | ||
| jds2001 | right, but package foo with function bar() we won't be able to trace bar() | |
| without doing something special to the foo package | ||
| or am i misunderstanding? | ||
| mjw | Put in 5% since we need to get a new system upstream release and put the new subpackage systemtap-sdt-devel in first. | |
| We have some test builds (outside the repo of course) already though. | ||
| jds2001, yes, you misunderstand :) | ||
| nirik | cool. +1 from me. | |
| fche | jds2001, this is for static instrumentation that upstream developers have already put into their code | |
| mjw | jds2001, That is actually already possible with fedora 10! | |
| fche | jds2001, we can already do dynamic instrumentation via debuginfo | |
| bpepple | +1 from me also. | |
| mjw | http://gnu.wildebeest.org/diary/2008/11/27/observe-systemtap-and-oprofile-updates/ | |
| j-rod | +1 | |
| sharkcz | +1 | |
| mjw | ^ fedora 10, doing simple user space tracing. | |
| jds2001 | fche: awesome, the last time I used stap it was for kernel stuff | |
| +1 from me. | ||
| mjw | But that is on function level. | |
| dgilmore | +1 | |
| jds2001 | i see six +1 | |
| mjw | This feature is about adding support on a higher level in applications itself, by reusing upstream dtrace marker support and enabling systemtap to recognize it. | |
| jds2001 | so we've approved the SystemTap static probes feature | |
| * mjw stops hyping then :) | ||
| jds2001 | mjw: hotness, thx :D | |
| no way we're going to get to nearly everything on the agenda. | ||
| but this is going to stack up into a pile o' doom. | ||
| fche | thanks guys | |
| bpepple | mjw: thanks for taking the time to answer our questions. | |
| fcami fche | ||
| nirik | thanks for coming mjw / fche | |
| jds2001 | i guess i'll move on to a feature that we need to approve today or doom happens. | |
| jds2001 | .fesco 42 | |
| zodbot | jds2001: #42 (GCC 4.4 - https://fedoraproject.org/wiki/Features/gcc4.4) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/42 | |
| nirik | jds2001: lets try and get thru a few more, and then if need be we can do a special session next week? | |
| jds2001 | nirik: sounds good | |
| bpepple | +1 to gcc feature. | |
| nirik | +1 here, but again, lets do only the one mass rebuild once we have in all the things that require it. ;) | |
| jds2001 | yeah, that's why i wanted to get to it today | |
| +1 | ||
| bpepple | nirik: agreed. | |
| dgilmore | +1 | |
| sharkcz | +1 | |
| notting | +1, but we can't do a mass rebuild without closing out the other feature | |
| jds2001 | right | |
| * nirik nods | ||
| jds2001 | i see 6 +1's, so we've approved the GCC4.4 feature. The mass rebuild will wait until Architecture Support is worked out. | |
| warren | cjb: the topic was tabled for reconsideration next week, too much indecision this week | |
| cjb | Hi, warren mentioned you are/were talking about i586. I asked our Geode expert at AMD, who says that OLPC's LX should be compatible with 686 instructions. (And that seems borne out by when we've booted standard Fedora media on the XO.) | |
| warren: okay, great | ||
| bpepple | cjb: thanks for the update. | |
| warren | cjb: discussion on this topic should be on fedora-devel-list until the next meeting. | |
| cjb | so, my input as OLPC software dude is that we're probably okay with dropping 586, but it would be great if someone heled us test that everything's looking okay first. I can't get Rawhide to boot on an XO at the moment. | |
| </done> | ||
| or rather, <done/>. :) | ||
| jds2001 | anything else we absolutely need to cover this week? | |
| bpepple | jds2001: when is our deadline for approving features? | |
| nirik | well, I was hoping we would hit on renaming and ovm, but oh well, if we don't have time we don't. | |
| jds2001 | feature freeze, 3/3 iirc | |
| nirik: yeah, i thought renaming would be a long protracted thing. | ||
| bpepple | good, couldn't remember what it was. | |
| nirik | it could be. | |
| notting | should we hit the non-feature thing about vmware? | |
| jds2001 | yeah, and ovm | |
| jds2001 | .fesco 35 | |
| zodbot | jds2001: #35 (vmware-requirements, and other 'crutch-for-proprietary-software' packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/35 | |
| jds2001 | so this was a review request for a metapackage to pull in vmware's requirements. | |
| sharkcz | IMO it's rpmfusion stuff | |
| jds2001 | i guess the question is if we want to allow such things. | |
| yeah, I'm leaning the same way. | ||
| dgilmore | jds2001: /me says no | |
| * notting votes -1 to it ... we should not be adding packages solely to deal with broken third-party packages | ||
| nirik also says no too | ||
| bpepple | -1 here also. | |
| dgilmore | -1 | |
| sharkcz | -1 | |
| dgilmore | just to be clear | |
| jds2001 | -1 here | |
| i see five -1,'s so we will not allow the vmware-requirements package into Fedora. | ||
| tibbs|h | Is this a specific rejection of this package, or a general rejection of the concept? | |
| * notting was voting -1 to the concept. not speaking to metapackages in general, though | ||
| jds2001 | good question. | |
| tibbs|h | Could we perhaps get a guideline, or should these things be examined on a case-by-case basis? | |
| nirik | I guess the question is: Does something like this "enhances the OS user experience" or not. | |
| jds2001 | i think case-by-case. | |
| * dgilmore thinks that any meta-package that has the goal of fixing brokenness in 3rd party packages is a nogo | ||
| * bpepple was also voting -1 to the concept. | ||
| * jds2001 too. | ||
| jds2001 | 3rd party packages shouldn't be "fixed" by Fedora, IMO | |
| nirik | I say no, because we should consider our user experence to be based on our packages/free software, not any 3rd party thing we don't ship. | |
| jds2001 | but metapackages I think we'd have to visit case-by-case. | |
| if that makes sense. | ||
| bpepple | Though to play devil advocate, haven't we shipped some stuff to fix flash? | |
| notting | bpepple: iirc, fesco voted to drop that | |
| dgilmore | jds2001: i know we have one for fedora-ds | |
| bpepple | notting: ah, forgot. | |
| nirik | I think metapackages is another discussion... | |
| jds2001 | it is. | |
| dgilmore | generally metapackages probbaly should be fixed by adding a comps group | |
| jds2001 | so the guideline would be "no packages to fix 3rd party packages brokeness" | |
| dgilmore | jds2001: +1 | |
| nirik | if so, then that answers the ovm thing as well, right? | |
| jds2001 | not really, i dont think. | |
| nirik | ok, lets take that seperate. Sorry for derailing things. | |
| jds2001 | well, we're done here. | |
| jds2001 | .fesco 13 | |
| zodbot | jds2001: #13 (FESCo needs to determine whether ovm is acceptable content) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/13 | |
| dgilmore | nirik: i think our guidelines are very clear for ovm. we need some free tool to use the data in. | |
| nirik | thats what I thought as well... but I was confused to what we really agreed to. | |
| jds2001 | yeah, we have iverilog right now. https://admin.fedoraproject.org/pkgdb/packages/name/iverilog | |
| nirik | jds2001: but it can't use it, can it? | |
| dgilmore | I really do not understand why they object so stronly to getting iverilog in | |
| jds2001 | supposedly this thing has some hope of working with iverilog, but it can't use it *right now* | |
| and from what I saw from the link that was posted, iverilog upstream has higher priorities than supporting this content. | ||
| nirik | I think that provides somewhat of a bad user experence if we allow ovm in now. | |
| jds2001 | yeah, "hey look at this neat thing! Oh wait, I can't actually use it" | |
| nirik | yum install ovm iverlog. 'oh, it doesn't work.' I need to go buy $EXPENSIVE tool | |
| jds2001 | so we have nothing that can use it, nothing that appears to be on the way to being able to use it. | |
| nirik | so, where are we? (aside from over time)? anyone have any other thoughts? | |
| dgilmore | jds2001: i propose that we continue to not allow it in. that when it can be used with free tools in some capacity we will warmly welcome it then. | |
| nirik | dgilmore: +1 | |
| jds2001 | +1 | |
| sharkcz | +1 | |
| notting | +1 | |
| bpepple | +1 | |
| jds2001 | i see five +1's (well six assuming dgilmore votes for his own proposal), so we continue to not allow ovm until some suitable consumer is in Fedora. | |
| dgilmore | yes im +1 | |
| jds2001 | alright, what times are folks available next week for a special session to clear this monstrosity of an agenda? | |
| hold on call from $DAYJOB | ||
| sharkcz | jds2001: this time +-1 hour any day | |
| bpepple | jds2001: Any day next week works for me. | |
| jds2001 | OK, I'll throw something out on the fesco list and try and work out a time. | |
| * nirik is mostly open as well... | ||
| nirik | how about tuesday? | |
| notting | mon 10-12, tues noon-2.. | |
| jds2001 | both are bad for me. | |
| * jds2001 is available wednesdays and fridays, most of the time. | ||
| nirik | wed? | |
| jds2001 | i have physical therapy from ~11-2 on monday, tuesday thursday | |
| notting | wednesday works for me, any point after 11est | |
| bpepple | ^ works for me also. | |
| jds2001 | alright | |
| * jds2001 will sned something out for wednesday | ||
| nirik is fine with that | ||
| sharkcz | there is an empty slot on Wed ;-) | |
| dgilmore | i cant do wedesday | |
| jds2001 | oh, right - forgot about that. | |
| * notting can also do monday after 2pm/releng, but that's probably a bit late for sharkcz | ||
| dgilmore | i cant do monday or thursday either | |
| bpepple | how about friday at 12EST? Oh, wait. | |
| dgilmore | actually can do thusday | |
| helps to look at the right calander | ||
| jds2001 | we'll work it out on the list. | |
| Hopefully have atime by monday so I can announce it. | ||
| nirik: you got the summary, just as a reminder :) | ||
| * jds2001 ends the meeting in 5 | ||
| jds2001 | -- MEETING END -- | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!