--- jds2001 has changed the topic to: FESCo meeting --init
jds2001FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
* nirik is here.
sharkcz here
* bpepple is here.
jds2001hmm, any reason no one else is here?
bpepplejds2001: they saw the agenda? ;)
jds2001hehe :D
jds2001well i guess with notting here we have enough to get started, even though I don't like having just 5.....
jds2001ahh, theres #6 :D
sharkczjds2001: I pinged notting and j-rod in internal irc
jds2001sharkcz: thx
j-rod(fwiw, I'm over on #fedora-devel and #fedora-kernel most of the time too)
but thank you sharkcz :)
sharkczj-rod: np
--- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets
jds2001.fesco 28
zodbotjds2001: #28 (Stronger Hashes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/28
jds2001any questions for mitr on this?
jds2001where are we with it?
nirikmitr: 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.
mitrnirik: There are way too many packages to ever get 100% :)
bpepplenirik: yeah, I find that a little troubling, too.
nottingcan we push a rpm update for f9 w/the hash change backported?
mitrnirik: 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.
jds2001is 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
jds2001er, preupgrade
nirikI assume since it's rpm, that would also apply to yum upgrades...
jds2001like it or not, lots of folks do yum upgrades.
nirikany status on rsync/scp or backup tools? I don't see any of those on the tracker bug.
mitrscp 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.
nottingmitr: if the backport's too big, why not push back 4.6 with some config changes?
mitrnotting: I didn't think of that and didn't ask.
nirikor can we do everything but rpm for now, and then push the rpm change as jds2001 said in a later release?
mitrnotting: I assume the stricter rpmbuild (--fuzz 0) could be a problem.
nottingmitr: that has to be configurable
mitrnirik: That's possible.
jds2001it's configurable in a spec, so should be fine in /etc/rpm/macros or whereever
nirikwell, I am all for this feature, but I would like to find a way to not mess up preupgrade/yum upgrades from f9...
jds2001same here, but not sure how to vote like that :D
nirikhow 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
mitrnirik: I'd prefer immediate approval of course :)  but it is probably a good idea.
jds2001oh, I almsot forgot - nirik your turn for summary this week :)
mitrnirik: A release note is on my todo list already.
nirikjds2001: 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... :)
jds2001i see five +1's that we defer to next week, so I'll keep it on the schedule.
jds2001.fesco 36
zodbotjds2001: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36
bpepple+1 to ArchitectureSupport Feature.
nottingany questions?
jds2001dgilmore had a concern that this would break the XO. I'm not 100% clear on that.
nottingdgilmore 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.
jds2001but afaik it lacks things like mmx?
sharkczXO is now using the i686 live image
nottingjds2001: 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)
jds2001cool, +1 here then.
abadger1999Two years ago the i586 folks were talking embedded.
*embedded systems
nottingabadger1999: going by the stats we have available, the i586 userbase is miniscule
nirikI have some i586 machines here... but they are off in the garage awaiting recycling. ;)
bpeppleless than 1% wasn't it?
jds2001but embedded probably wouldnt show up in any of those stats
* abadger1999 gets ready to junk his three old i586 boxes.
nottingbpepple: much less. .04%
notting(of active hosts)
nirikanyhow, +1 from me...
bpepplereaffirms his +1.
jds2001i 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.
nottingjds2001: 'new' is a relative term here :)
jds2001notting: :)
sharkczI got an i686 in '98 ...
nottingyeah, my first was in '97
jds2001i 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.
sharkczand anybody can start i586 as secondary arch
niriknotting: this will require a mass rebuild?
nottingnirik: yep. and if we decide to undo it, will require another :/
jds2001yes, but a few other things on the agenda today will too.
* davej gets ready to nuke the 586 kernel from orbit.
bpepplenirik: I think we're already going to be doing one for the new gcc anyway.
niriknotting / bpepple: yeah, just want that all to get coordinated to have just the one. ;)
nottingexactly, wanted to make sure to get this approved/disapproved before we start the gcc4.4 mass rebiuld
bpepplenirik: right.
jds2001.fesco 37
zodbotjds2001: #37 (Crash catcher - https://fedoraproject.org/wiki/Features/CrashCatcher) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/37
jds2001where are we on this, 10% looks worrisome.
nirikis CrashCatcher already in? or under review? or not yet written?
jds2001and how does it actually work, out of curiosity?
nottingit'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
* dgilmore is here
jmoskovc`I was trying to push it to fedorahosted today, but I had some difficulties with git :(
dgilmorenotting: rpm correctly refuse to install i686 rpms
nottingdgilmore: are you running the i586 kernel at the time?
j-rodcrap, got side-tracked... tardy +1 to the arch change thing
dgilmorenotting: whetever kernel olpc ships
nirikjmoskovc`: 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?
dgilmorenotting: however the cpu is not i686 compatiable
warrenHi, 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.
nottingdgilmore: cjb says it works
jds2001warren: sorry for the late agenda.
dgilmorenotting: he is wrong
jmoskovc`nirik: we should be able to get backtrace from core dump and send it to BZ (or somewhere)
warrenjds2001: was it voted to drop i586 kernel and userspace or only kernel build?
dgilmorenotting: there is a reason the rpm has a .geode rpm
* nirik guesses this means we should revisit the i586 thing again?
dgilmorenotting: it sits between i586 and i686
jds2001yeah, lets go back :)
nottingwarren: if we drop the kernel, there's no point in keeping the userspace around
nirikjmoskovc`: is there any filtering on that? or it just always sends them?
warrennotting: right
dgilmorethe geode cpu is i586 + the cmov extention
bpepplehow about we finish the CrashCatcher feature, and then go back Architecture feature?
warrenAre we dropping i586 builds because it was adding actual maintenance burden?
dgilmoreif we consider that to be i686  then rpm will need to be told so
nottingdgilmore: 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
nirikbpepple: +1
warrennotting: (looking back at the earlier conversation) stats wont include smolt reports from innumerable thin clients
nottingwarren: innumerable is a meaningless number without stats, though
warrennotting: sure.
bpepple+1 to CrashCatcher feature.
nirikjmoskovc`: 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?
* dgilmore wonders how it will report to Bugzilla
dgilmoreespecially 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
nirikjmoskovc`: is there a package for it under review? it would need to be added into the collection, right?
warrenjds2001: will fesco go back to discuss i586?
jds2001warren: sure, when we're done with crashcatcher
warrenjds2001: If this is a final vote, then LTSP and k12linux effectively ends with Fedora 10.
zprikryldgilmore, you have to have a fedora account, anonymous reports will not be allowed
dgilmore, bigzilla account
dgilmorezprikryl: fedora account doesnt mean bugzilla account
zprikryl: they are dispariate systems
jmoskovc`nirik: ?? we dont have an rpm yet
dgilmorezprikryl: are we planning to make uses sign up for multiple accounts to use this system?
nirikjmoskovc`: 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 :)
nottingwarren: so, k12linux only supports 10-year old hardware?
warrennotting: most of the hardware people are still using today are i586
nirikI 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...
zprikrylnirik, jmoskovc: imho we can finish version 1.0.0  :-).... but it will be hard
warrennotting: and some of the top selling thin clients today are geode and another no-name brand of i586
nottingwarren: *today*. so why would the project end? they'll be using better hardware tomorrow
bpepplejmoskovc`: will it be in a testable state by the Beta?
nirikI guess we could always do that later in this cycle if it's not ready.
jmoskovc`bpepple: beta is in March, right?
warrennotting: the clients outlive the server since software bloat on the server doesn't necessarily mean the client doesn't work anymore.
nirikjmoskovc`: march 3rd is feature freeze.
bpepplejmoskovc`: yeah, it would need to be in a testable state by March 3rd.
jds2001so lets talk about one thing at a time.
warrennotting: 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.
jds2001lets get back to crashcatcher, finish that, and then we can talk about architecture support
jmoskovc`zprikryl: can wa make it?
zprikryljmoskovc`, I think so
bpeppleI'm fine with approving this, and if it's not in a testable state by Beta we push it to F12.
nirikif you guys think you can, I am +1... we can always bump back to 12
+1 here, review at Beta
j-rod+1 to that as well
nirikzprikryl / jmoskovc` : do remember to keep the feature page updated with your progress. ;)
jmoskovc`nirik: ok, we'll try :)
notting+1 to crashcatcher
zprikrylnirik, ok ok :-)
jds2001i see five +1's, so we've approved the crashcatcher feature, and will review at beta.
nirikalso 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.
jds2001ok, back to
jds2001.fesco 36
zodbotjds2001: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36
warrenKey question here...
* nirik thanks zprikryl and jmoskovc` for coming and providing us info.
warrenIs i586 creating actual maintenance burden?
dgilmoreso,  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.
bpeppleby keeping i586 in the kernel it's adversely affecting performance for the majority of our users.
jds2001so i just  booted my xo into fedora
nottingit'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)
dgilmoreOLPC shoves i686 glibc and openssl on at image compose time.  they are never upgradeable
jds2001it claims it is Linux localhost.localdomain #1 SMP Mon Nov 10 15:51:55 EST 2008 i586 i586 i386 GNU/Linux
dgilmorejds2001: 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
warrenoh, all RPMS will be rebuilt to .i686.rpm as well?
dgilmoreim 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
nottingdgilmore: but if glibc and openssl don't (and they're built with -march=i686), why would other things randomly?
dgilmorenotting: corner cases
notting: and more likely with things the use multimedia based instructions
nottingthings that use multimedia instructions that aren't using run-time tests are already broken, as you have different ones for amd and intel
abadger1999dgilmore: 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.
dgilmorenotting: will optimising for i686 though turn off support for i586 checking
nottingshouldn't... you have to do this stuff  by hand anywaty
dgilmoreabadger1999: im saying they shove fedora's i686 glibc and openssl packages in
abadger1999: and rpm correctly refuses to update the rpms
abadger1999ah okay.
warrenWhat exactly was voted upon earlier?
warrenkernel/glibc/openssl only?  Or all packages become i686.rpm?
nottingwarren: um, read the feature page?
bpepplewarren: https://fedoraproject.org/wiki/Features/ArchitectureSupport
dgilmorei 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
abadger1999warren: All packages.  basically changes to default compiler flags
nirikso I assume adding a .i586 repo/branch/etc would be beyond pain?
warrennirik: yes.
bpepplenirik: yeah, the mirrors would probably revolt. ;)
warrennirik: effectively secondary arch
dgilmorenirik: 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.
warrenI 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.
cebbertthis is just as bad as deciding to release only DVD images
sharkczwell, I still think that i586 as secondary arch is doable
warrencebbert: as kernel maintainer you don't mind building i586?
dgilmoresharkcz: its totally doable
j-rodhell, i586 probably has a better chance of flying as a secondary arch than any other currently-being-attempted secondary arch
nirikwarren: is there some subset of packages that lstp uses? ie, not everything just X server/kernel? or ?
cebbertwarren: I proposed we get rid of the 686 kernel and have only 586 and PAE kernels for 32-bit
warrencebbert: huh?
nirik: generating list
sharkczcebbert: 686 <=> 586 ??
j-rodi686 w/pae -> kernel-PAE
i586 and i686 w/o pae -> kernel.i586
dgilmorei would like to see a fall back plan if .i686 optimisation fails on the gedoe
nottingdgilmore: it's in the contingency section of the feature page
warrenCould we please reconsider dropping i586 for F12 instead?  I mean, why now?
nirikdgilmore: is there any way to test that without commiting ourselves? "some things might break" doesn't sound easy to test.
mjwsorry about the process question, but how long do these fesco meeting last normally? (waiting for our feature to be discussed before going to dinner)
bpepplemjw: 1 to 2 hours.
dgilmorenotting: id like something inbetween
jds2001mjw: 2 hours, but what feature is that?
nirikmjw: 2 hours... but we have a full schedule, so who knows?
dgilmorenotting: like building .i686 and .i586  but ignoring the .i586 until we determine its needed
mjw41, systemtap static probes. But I can stay it out another hour. OK.
abadger1999So...Jakub's original email was very keen to move to -march=i486 but gave -march=i586 asan option.
nottingdgilmore: that sounds painful
jds2001mjw: we can do that next, should be fast i think.
abadger1999Why not -march=i486?
warrenabadger1999: hmm, something must have changed, it was his team years ago that said i386 instructions with i686 optimized code was faster than i586.
abadger1999warren: I think that was -mtune
Rather than -march
abadger1999But I could be misremembering.
warrendgilmore: would building i586 and i686 for everything add a burden to storage and build servers?
sharkczor gcc did changed
abadger1999Jakub's message: https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01661.html
* warren reads
dgilmorewarren: yes
warren: it is effectively adding another arch
warrenHas FESCO considered Jakub's recommendation of -march=i486 or i586 instead of this?
warrenThat seems to be very reasonable, not a burden on infrastructure, and wont break geode.
I mean Jakub recommended this for a reason?
nottingbecause 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?
bzbotBug 200330: high, medium, ---, jakub@redhat.com, CLOSED RAWHIDE, i686 openssl broken on AMD Geode
niriknotting: 10 year old is an improvement over the current 15 or 20 year old?
abadger1999notting: 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|hSo finding a way to support scrap hardware no longer supported by Microsoft or Apple is explicitly not an innovation?
warreni486 or i586 for all packages sounds very reasonable.  Could we please consider this for F11 and reconsider for F12?
niriknotting: how much benifit do we loose doing that? just i586 instead of i686? and drop i586 in f12?
warrennotting: many popular thin clients selling today are still not i686, due to very low per-unit cost when they buy thousands...
bpeppleabadger1999: 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|hHow does RHEL come into this?
davejwarren: what cpu's typically are they using?
niriktrue I guess... it does allow more time for 'upgrade your hardware or switch distros', but there will always be some that won't.
abadger1999bpepple: Well... when I was working on ltsp I certainly wanted to run Fedora on them :-)
* jds2001 notes that CentOS5 *does* ship an i586 kernel.
nottingtibbs|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 ..."
jds2001I would guess due to folks wanting it?
warrendavej: Vortex86 System on Chip (video and CPU and motherboard chipsets all on one die) at the low end and Geode GX2 or Geode LX.
bpeppleabadger1999: yeah, but I always thought CentOS or RHEL with longer support cycles worked better for those types of installations.
abadger1999bpepple: Usually, people wanted newer end-user apps.... the labs are desktop machines.... just run as thin clients.
warrenbpepple: Thin clients tend to out live the servers.
nottingabadger1999: then the thin clients can still run an older release
abadger1999bpepple: So we tried the CentOS based ltsp but customers were interested in Fedora or Ubuntu on the thin client.
warrennotting: the current older release has kernel and X drivers from 2004.
bpeppleabadger1999: yeah, I guess I'm projecting what I'd be willing to support if I was in charge of installing that. ;)
nottingabadger1999: 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.
sharkczwarren: you want to have both client and server side be the same Fedora?
nottingwarren: if you hardware is that old....?
dgilmore: that implies that -march=i686 should work, if the base CPU insn set is i686/ppro
dgilmorenotting: 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
abadger1999warren: Please correct me if I'm wrong... the current ltsp build system builds the ltsp client from the current server packages, yes?
warrenabadger1999: yes
abadger1999: chroot is installed from the same fedora repo
nottingdgilmore: 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"
abadger1999notting: 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.
warrenold 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?
nottingwarren: don't know. but if they're only building an i686 kernel, why wouldn't they?
nirikwarren: would there be enough interested people in the lstp community to get i586 running as a secondary arch?
abadger1999We didn't build everything with -march=i486 even though the kernel only supports 486+
* abadger1999 notes only 40 minutes left....
bpeppleyeah, we need to resolve this.  There's still a lot on the agenda.
nottingwant to table this for next week and have more discussion?
bpepplenotting: +1
abadger1999Mass rebuild needs to block on this.
niriknotting: +1. More info on olpc would be good.
warrennirik: 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.
abadger1999Just so people are aware of that too.
bpeppleabadger1999: correct.
I think the gcc stuff isn't ready for the rebuild yet either.
drago01there 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
warrennirik: 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).
nottingdrago01: i am... not concerned... about those users
warrennirik: 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.
nottingdrago01: other people may feel differently, i'm sure
jds2001warren: rhel5 didn't support i586
drago01notting: yeah and there is a workaround , but might be worth adding to the rel notes
warrenjds2001: I know.
bpeppleok, 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.
jds2001warren: the i586 support in centos5 was done by centos.
warrenjds2001: but the feasibilty of doing it is very different if all packages are i686.
jds2001warren: understood :)
warrenIf RHEL6 has decided on i686 everywhere then I don't care what Fedora 11 decides.
nirikwell, 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.
jds2001ok, let's table this for now, take discussion back to the last, discard the previous vote.
sound reasonable?
warrenfesco's private list?
jds2001no, of course not.
nirikfedora-devel ?
bpepplewarren: devel list should be fine, though I'm sure there will be a lot of noise about it.
warrenalrighty.  sorry about the disruption.
I totally understand the desire and benefits of this.
jds2001alright, let's get the systemtap folks able to eat dinner :)
jds2001.fesco 41
zodbotjds2001: #41 (SsytemTap Static Probes - http://tinyurl.com/btqjno) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/41
bpepplewarren: np.
nottingsorry, be back in 5-10. question - you have to patch your userspace to support this?
jds2001yeah, you have to put .d files in aiui
mjwnotting, yes, a user space package needs to be recompiled to support it.
jds2001just recompile, or put instrumentation in and recompile?
fchethe instrumentation is already in there - we just need to activate it
nirikmjw: are you going to have this testable by feature freeze? still at 5%?
mjwSo, 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.
jds2001right, 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?
mjwPut 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 :)
nirikcool. +1 from me.
fchejds2001, this is for static instrumentation that upstream developers have already put into their code
mjwjds2001, That is actually already possible with fedora 10!
fchejds2001, we can already do dynamic instrumentation via debuginfo
bpepple+1 from me also.
mjw^ fedora 10, doing simple user space tracing.
jds2001fche: awesome, the last time I used stap it was for kernel stuff
+1 from me.
mjwBut that is on function level.
jds2001i see six +1
mjwThis feature is about adding support on a higher level in applications itself, by reusing upstream dtrace marker support and enabling systemtap to recognize it.
jds2001so we've approved the SystemTap static probes feature
* mjw stops hyping then :)
jds2001mjw: 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.
fchethanks guys
bpepplemjw: thanks for taking the time to answer our questions.
fcami fche
nirikthanks for coming mjw / fche
jds2001i guess i'll move on to a feature that we need to approve today or doom happens.
jds2001.fesco 42
zodbotjds2001: #42 (GCC 4.4 - https://fedoraproject.org/wiki/Features/gcc4.4) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/42
nirikjds2001: lets try and get thru a few more, and then if need be we can do a special session next week?
jds2001nirik: 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. ;)
jds2001yeah, that's why i wanted to get to it today
bpepplenirik: agreed.
notting+1, but we can't do a mass rebuild without closing out the other feature
* nirik nods
jds2001i see 6 +1's, so we've approved the GCC4.4 feature.  The mass rebuild will wait until Architecture Support is worked out.
warrencjb: the topic was tabled for reconsideration next week, too much indecision this week
cjbHi, 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
bpepplecjb: thanks for the update.
warrencjb: discussion on this topic should be on fedora-devel-list until the next meeting.
cjbso, 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.
or rather, <done/>. :)
jds2001anything else we absolutely need to cover this week?
bpepplejds2001: when is our deadline for approving features?
nirikwell, I was hoping we would hit on renaming and ovm, but oh well, if we don't have time we don't.
jds2001feature freeze, 3/3 iirc
nirik: yeah, i thought renaming would be a long protracted thing.
bpepplegood, couldn't remember what it was.
nirikit could be.
nottingshould we hit the non-feature thing about vmware?
jds2001yeah, and ovm
jds2001.fesco 35
zodbotjds2001: #35 (vmware-requirements, and other 'crutch-for-proprietary-software' packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/35
jds2001so this was a review request for a metapackage to pull in vmware's requirements.
sharkczIMO it's rpmfusion stuff
jds2001i guess the question is if we want to allow such things.
yeah, I'm leaning the same way.
dgilmorejds2001: /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.
dgilmorejust to be clear
jds2001-1 here
i see five -1,'s so we will not allow the vmware-requirements package into Fedora.
tibbs|hIs 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
jds2001good question.
tibbs|hCould we perhaps get a guideline, or should these things be examined on a case-by-case basis?
nirikI guess the question is: Does something like this "enhances the OS user experience" or not.
jds2001i 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.
jds20013rd party packages shouldn't be "fixed" by Fedora, IMO
nirikI 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.
jds2001but metapackages I think we'd have to visit case-by-case.
if that makes sense.
bpeppleThough to play devil advocate, haven't we shipped some stuff to fix flash?
nottingbpepple: iirc, fesco voted to drop that
dgilmorejds2001: i know we have one for fedora-ds
bpepplenotting: ah, forgot.
nirikI think metapackages is another discussion...
jds2001it is.
dgilmoregenerally metapackages probbaly should be fixed by adding a comps group
jds2001so the guideline would be "no packages to fix 3rd party packages brokeness"
dgilmorejds2001: +1
nirikif so, then that answers the ovm thing as well, right?
jds2001not really, i dont think.
nirikok, lets take that seperate. Sorry for derailing things.
jds2001well, we're done here.
jds2001.fesco 13
zodbotjds2001: #13 (FESCo needs to determine whether ovm is acceptable content) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/13
dgilmorenirik: i think our guidelines are very clear for ovm.  we need some free tool to use the data in.
nirikthats what I thought as well... but I was confused to what we really agreed to.
jds2001yeah, we have iverilog right now. https://admin.fedoraproject.org/pkgdb/packages/name/iverilog
nirikjds2001: but it can't use it, can it?
dgilmoreI really do not understand why they object so stronly to getting iverilog in
jds2001supposedly 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.
nirikI think that provides somewhat of a bad user experence if we allow ovm in now.
jds2001yeah, "hey look at this neat thing!  Oh wait, I can't actually use it"
nirikyum install ovm iverlog. 'oh, it doesn't work.' I need to go buy $EXPENSIVE tool
jds2001so we have nothing that can use it, nothing that appears to be on the way to being able to use it.
nirikso, where are we? (aside from over time)? anyone have any other thoughts?
dgilmorejds2001: 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.
nirikdgilmore: +1
jds2001i 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.
dgilmoreyes im +1
jds2001alright, what times are folks available next week for a special session to clear this monstrosity of an agenda?
hold on call from $DAYJOB
sharkczjds2001: this time +-1 hour any day
bpepplejds2001: Any day next week works for me.
jds2001OK, I'll throw something out on the fesco list and try and work out a time.
* nirik is mostly open as well...
nirikhow about tuesday?
nottingmon 10-12, tues noon-2..
jds2001both are bad for me.
* jds2001 is available wednesdays and fridays, most of the time.
jds2001i have physical therapy from ~11-2 on monday, tuesday thursday
nottingwednesday works for me, any point after 11est
bpepple^ works for me also.
* jds2001 will sned something out for wednesday
nirik is fine with that
sharkczthere is an empty slot on Wed ;-)
dgilmorei cant do wedesday
jds2001oh, right - forgot about that.
* notting can also do monday after 2pm/releng, but that's probably a bit late for sharkcz
dgilmorei cant do monday or thursday either
bpepplehow about friday at 12EST? Oh, wait.
dgilmoreactually can do thusday
helps to look at the right calander
jds2001we'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!