All,
I have recently finished a initial conversion of kpowersave to work without HAL, instead relying on the brand-new TDE hardware library, which in turn works straight off of the raw device nodes in /sysfs.
As this is the last remaining large HAL dependency in TDE, I would encourage the TDE developers to compile and test on their hardware, reporting bugs to this mailing list.
The source code is available here: http://git.trinitydesktop.org/cgit/kpowersave-nohal/
and can be obtained via: git clone http://scm.trinitydesktop.org/scm/git/kpowersave-nohal
If this works reliably, along with the udev-based media kioslave:/, I will seriously consider removing the TDE HAL dependency completely for R14.0.
Tim
If this works reliably, along with the udev-based media kioslave:/, I will seriously consider removing the TDE HAL dependency completely for R14.0.
Don't.
Darrell
There are many distributions that do not provide HAL, or worse on which HAL actually breaks basic functionality (i.e. keyboards/mice suddenly don't work, etc.). Sounds like we need to get R14.0 out the door ASAP, even if it it slightly buggy, so that we can start working on more fundamental problems.
Thoughts are welcome!
Tim
There are many distributions that do not provide HAL, or worse on which HAL actually breaks basic functionality (i.e. keyboards/mice suddenly don't work, etc.). Sounds like we need to get R14.0 out the door ASAP, even if it it slightly buggy, so that we can start working on more fundamental problems.
Thoughts are welcome!
From where is this idea derived that we need to get R14 out the door ASAP? Suddenly we have to push a "slightly" buggy release? Why? Who is keeping score?
My calendar says April, not May.
Which fundamental problems? Like a few hundred bug reports?
How are we supposed to test this new hardware support when half of us can't build a complete package set?
Are we again pushing a buggy release? Seems we have seen that story, what? twice now?
Trinity is not "slightly" buggy. Trinity is buggy. Many bug reports need resolution. Many build issues need attention.
Trinity is broken with respect to building with gcc 4.7.
If we spent time as a team addressing the bug tracker we could release a non buggy R14. If we spent time as a team helping and coaching one another we'd have fewer bugs. Almost every day David and I post build issues and bugs. We receive no meaningful help. We resign ourselves to posting the issues to the bug tracker and there the problems sit without resolution or motion.
We likely could resolve all build issues in less than a week if everybody pitched in and helped. We likely could resolve dozens of bug reports if everybody pitched in and helped.
And then, maybe, we actually would have stable foundations on multiple distros to thoroughly test the new hardware support system.
Please don't rip HAL support. Not everybody is using bleeding edge distros --- let people build whichever mechanism they want through build options.
Please don't push a buggy R14.
Darrell
There are many distributions that do not provide HAL, or worse on which HAL actually breaks basic functionality (i.e. keyboards/mice suddenly don't work, etc.). Sounds like we need to get R14.0 out the door ASAP, even if it it slightly buggy, so that we can start working on more fundamental problems.
Thoughts are welcome!
From where is this idea derived that we need to get R14 out the door ASAP? Suddenly we have to push a "slightly" buggy release? Why? Who is keeping score?
My calendar says April, not May.
Which fundamental problems? Like a few hundred bug reports?
My concern is that we are in some kind of soft freeze until R14.0 is pushed out the door, meaning that it is difficult/impossible to remove reliance on deprecated (and in many cases flat-out broken) systems such as HAL.
How are we supposed to test this new hardware support when half of us can't build a complete package set?
That's a problem. All I am asking for is that those who can try it out so that obvious bugs can be squashed and so that I can start to get some idea of its reliability for potential inclusion in the next release.
Are we again pushing a buggy release? Seems we have seen that story, what? twice now?
Trinity is not "slightly" buggy. Trinity is buggy. Many bug reports need resolution. Many build issues need attention.
Trinity is broken with respect to building with gcc 4.7.
If we spent time as a team addressing the bug tracker we could release a non buggy R14. If we spent time as a team helping and coaching one another we'd have fewer bugs. Almost every day David and I post build issues and bugs. We receive no meaningful help. We resign ourselves to posting the issues to the bug tracker and there the problems sit without resolution or motion.
We likely could resolve all build issues in less than a week if everybody pitched in and helped. We likely could resolve dozens of bug reports if everybody pitched in and helped.
And then, maybe, we actually would have stable foundations on multiple distros to thoroughly test the new hardware support system.
I don't disagree with any particular point, but very few of us can dedicate that amount of solid time. HAL was becoming a nuisance for me along with the persistent lack of a viable replacement hardware library (which I really, really need to fix other problems such as the age-old numlock issue), so I wrote a 5000+ line replacement. That is not a small task, but it really needed to be done for long term stability and support.
Please don't rip HAL support. Not everybody is using bleeding edge distros --- let people build whichever mechanism they want through build options.
The only place HAL support has to be "ripped" is in kpowersave--I may end up renaming kpowersave to something else for the non-HAL variant, but needed to gauge the reaction here first.
So, what should kpowersave be renamed to? "TDE Power Miser" is my current suggestion. :-)
Please don't push a buggy R14.
I'll try not to, but the clock is ticking to some extent. For now let's aim for at least resolving all the build issues and user-visible bugs within 3 months. Build bugs are a real problem as two developers rarely have the exact same kernel/distro/hardware--this is why I have been unable to offer much help when build bugs do come up. For what it's worth I'm running a rebuild on Ubuntu/Debian now (thanks in part to the donations received during the spring fundraiser), so there is half a chance that a build bug or two might be resolved in the near future.
Tim
My concern is that we are in some kind of soft freeze until R14.0 is pushed out the door, meaning that it is difficult/impossible to remove reliance on deprecated (and in many cases flat-out broken) systems such as HAL.
How are we supposed to test this new hardware support
when half of us can't build a complete package set?
That's a problem. All I am asking for is that those who can try it out so that obvious bugs can be squashed and so that I can start to get some idea of its reliability for potential inclusion in the next release.
Are we again pushing a buggy release? Seems we have
seen that story, what? twice now?
Trinity is not "slightly" buggy. Trinity is buggy. Many
bug reports need resolution. Many build issues need attention.
Trinity is broken with respect to building with gcc 4.7.
If we spent time as a team addressing the bug tracker
we could release a non buggy R14. If we spent time as a team helping and coaching one another we'd have fewer bugs. Almost every day David and I post build issues and bugs. We receive no meaningful help. We resign ourselves to posting the issues to the bug tracker and there the problems sit without resolution or motion.
We likely could resolve all build issues in less than a
week if everybody pitched in and helped. We likely could resolve dozens of bug reports if everybody pitched in and helped.
And then, maybe, we actually would have stable
foundations on multiple distros to thoroughly test the new hardware support system.
I don't disagree with any particular point, but very few of us can dedicate that amount of solid time. HAL was becoming a nuisance for me along with the persistent lack of a viable replacement hardware library (which I really, really need to fix other problems such as the age-old numlock issue), so I wrote a 5000+ line replacement. That is not a small task, but it really needed to be done for long term stability and support.
Please don't rip HAL support. Not everybody is using
bleeding edge distros --- let people build whichever mechanism they want through build options.
The only place HAL support has to be "ripped" is in kpowersave--I may end up renaming kpowersave to something else for the non-HAL variant, but needed to gauge the reaction here first.
So, what should kpowersave be renamed to? "TDE Power Miser" is my current suggestion. :-)
Please don't push a buggy R14.
I'll try not to, but the clock is ticking to some extent. For now let's aim for at least resolving all the build issues and user-visible bugs within 3 months. Build bugs are a real problem as two developers rarely have the exact same kernel/distro/hardware--this is why I have been unable to offer much help when build bugs do come up. For what it's worth I'm running a rebuild on Ubuntu/Debian now (thanks in part to the donations received during the spring fundraiser), so there is half a chance that a build bug or two might be resolved in the near future.
Fair enough. I'll post my list of build and usability issues. I'm sure others can do likewise. From that effort we'll know what is ailing us the most.
I suspect a significant number of build issues can be resolved in ten minutes --- if only an experienced person would look at the report.
David and I have shown that we can apply patches and rebuild just about as fast as anybody. All we need is help --- guidance --- and the bug reports will disappear like the dew on a hot sunny morning.
A 3 month plan is fine and doable. I always have preferred the "we release when ready" motto. If we adopt a fixed release date then quality assurance suffers. Always.
I'm aware of the demands on people's time. I have them too.
I'm now building for two different Slackware releases. I plan to expand that to three and add the respective 64 bit versions. That provides us more coverage and exposure to potential breakage.
I don't underestimate the HAL issue and appreciate the effort. As long as HAL remains a part of the basic build options then I am content. The upcoming release of Slackware has moved away from HAL but 13.1 will not and 13.1 remains in use. We need to build for both.
Let Calvin rename kpowersave.
Darrell
On 04/16/2012 12:55 AM, Darrell Anderson wrote:
My concern is that we are in some kind of soft freeze until R14.0 is pushed out the door, meaning that it is difficult/impossible to remove reliance on deprecated (and in many cases flat-out broken) systems such as HAL.
How are we supposed to test this new hardware support
when half of us can't build a complete package set?
That's a problem. All I am asking for is that those who can try it out so that obvious bugs can be squashed and so that I can start to get some idea of its reliability for potential inclusion in the next release.
Are we again pushing a buggy release? Seems we have
seen that story, what? twice now?
Trinity is not "slightly" buggy. Trinity is buggy. Many
bug reports need resolution. Many build issues need attention.
Trinity is broken with respect to building with gcc 4.7.
If we spent time as a team addressing the bug tracker
we could release a non buggy R14. If we spent time as a team helping and coaching one another we'd have fewer bugs. Almost every day David and I post build issues and bugs. We receive no meaningful help. We resign ourselves to posting the issues to the bug tracker and there the problems sit without resolution or motion.
We likely could resolve all build issues in less than a
week if everybody pitched in and helped. We likely could resolve dozens of bug reports if everybody pitched in and helped.
And then, maybe, we actually would have stable
foundations on multiple distros to thoroughly test the new hardware support system.
I don't disagree with any particular point, but very few of us can dedicate that amount of solid time. HAL was becoming a nuisance for me along with the persistent lack of a viable replacement hardware library (which I really, really need to fix other problems such as the age-old numlock issue), so I wrote a 5000+ line replacement. That is not a small task, but it really needed to be done for long term stability and support.
Please don't rip HAL support. Not everybody is using
bleeding edge distros --- let people build whichever mechanism they want through build options.
The only place HAL support has to be "ripped" is in kpowersave--I may end up renaming kpowersave to something else for the non-HAL variant, but needed to gauge the reaction here first.
So, what should kpowersave be renamed to? "TDE Power Miser" is my current suggestion. :-)
Please don't push a buggy R14.
I'll try not to, but the clock is ticking to some extent. For now let's aim for at least resolving all the build issues and user-visible bugs within 3 months. Build bugs are a real problem as two developers rarely have the exact same kernel/distro/hardware--this is why I have been unable to offer much help when build bugs do come up. For what it's worth I'm running a rebuild on Ubuntu/Debian now (thanks in part to the donations received during the spring fundraiser), so there is half a chance that a build bug or two might be resolved in the near future.
Fair enough. I'll post my list of build and usability issues. I'm sure others can do likewise. From that effort we'll know what is ailing us the most.
I suspect a significant number of build issues can be resolved in ten minutes --- if only an experienced person would look at the report.
David and I have shown that we can apply patches and rebuild just about as fast as anybody. All we need is help --- guidance --- and the bug reports will disappear like the dew on a hot sunny morning.
A 3 month plan is fine and doable. I always have preferred the "we release when ready" motto. If we adopt a fixed release date then quality assurance suffers. Always.
I'm aware of the demands on people's time. I have them too.
I'm now building for two different Slackware releases. I plan to expand that to three and add the respective 64 bit versions. That provides us more coverage and exposure to potential breakage.
I don't underestimate the HAL issue and appreciate the effort. As long as HAL remains a part of the basic build options then I am content. The upcoming release of Slackware has moved away from HAL but 13.1 will not and 13.1 remains in use. We need to build for both.
Let Calvin rename kpowersave.
Darrell
I missed this discussion mostly, but here are my thoughts.
Why not provide also a HAL based kpowersave just for R14, alongside with the new improved one that Tim wrote? This is a phasing out period. After R15, we drop it entirely. That gives everyone a heck of a lot of time to work out their issues.
I like the release mantra "make each release suck less" and that's what I think our goal needs to be. We can't ship a perfect release, but we can improve from every prior release. it may not seem like it, but many a bug has been sqaushed since November 1st. I don't have a great gauge on this, but 187 bugs have been modified, and are resolved since 3.5.13. barring any bugs that were modified, reopened or anything else, 187ish bugs have been resolved. I think this is tremendous progress. 29 bug reports sit with "Patch Avail" which I think should be all considered release blocking in a sense. We have those patches available, we should get them out in the wild by the next release.
Just some thoughts,
Calvin
PS. why not just call it TPowerManager? It's not really for "saving" like kpowersave, because my intent could well be to run my system at a maximum rate, what it's job is to manage the power related aspects of the system.
Why not provide also a HAL based kpowersave just for R14, alongside with the new improved one that Tim wrote? This is a phasing out period. After R15, we drop it entirely. That gives everyone a heck of a lot of time to work out their issues.
That is the issue I raised. I support the new hardware detection process but I don't want to see HAL ripped in the same move. There needs to be an overlap period. Let's add the new interface in R14, but don't remove HAL support in R14. Do that in R15. Document the build option requirements to build either or both. If building both causes conflicts then document those conflicts. There remains in use some older distro releases. They need to remain supported and that means HAL.
That's all.
I like the release mantra "make each release suck less" and that's what I think our goal needs to be. We can't ship a perfect release, but we can improve from every prior release. it may not seem like it, but many a bug has been sqaushed since November 1st. I don't have a great gauge on this, but 187 bugs have been modified, and are resolved since 3.5.13. barring any bugs that were modified, reopened or anything else, 187ish bugs have been resolved. I think this is tremendous progress. 29 bug reports sit with "Patch Avail" which I think should be all considered release blocking in a sense. We have those patches available, we should get them out in the wild by the next release.
When I review the bug tracker in different ways and sorting methods I too notice that we have resolved many bugs. We should not ignore that accomplishment.
Despite that noble effort, I am observing in this restlessness that we are not addressing long standing bugs and irritable bugs. I'll cite two bug reports, neither filed by me but irritating to me:
922 When logging out with unsaved file, trinity does not ask to save it 859 Kaffeine does not block screensaver
The TQt layer adds to the debate because some people believe the TQt layer is part of the problem. I can't argue against the people who say TQt has caused problems because several times I have resolved issues with some "inadvertent TQt" cleanup. A bug with kaffeine, for example, or more recently, getting digikam and gwenview to hook properly against the kipi-plugins.
The discussion goes deeper than superficial cleanup.
We do not address build issues in anything resembling a timely manner. When people post build issues to this list and receive nothing but silence, then we have a problem. This is the developer's list. We should be filing build related bug reports only seldom. Yet David and I often have to do the opposite because we seldom receive help in this list. Many times David and I have asked for guidance so we can learn how to resolve similar future issues. Silence. If not for David and me pushing our personal skills to the limit --- to the point of exhaustion, this list would be dead. That observation in itself does not bode well for the future of this project.
While some bug reports sit unresolved with proposed patches, I can't blindly push the patches. I have reviewed many of those patches. Some are distro specific. Some are over my head to understand. Some require reverting previous patches. I lack the technical expertise to decide whether to push those remaining patches. The patches I have pushed to GIT were trivial or easily confirmed as working on more than one distro. Somebody with the technical expertise needs to evaluate the remaining patches.
Yet even then, despite our having had discussed the concept of a sign-off process, several times I have posted to this list a request to review a patch and asked somebody to provide a sign-off. Silence.
Of those patches that revert previous patching, we need to determine why the original patch was pushed. Some "root cause analysis" is required to ensure reverting a patch does not restore a previous bug. I have discovered several patches like that. For myself I have reverted them in my build process, but I won't push those reverted patches to GIT because I don't know the implications on other distros.
I am well aware that this project is fueled by volunteer efforts. The compensation each of us receives is being able to use software that we prefer.
A challenge with many of these bug reports is each person uses the software in different ways. Some people never experience some of the bugs because they do not use the software in the same manner. An attitude of "works for me" only angers users. Occasionally a bug report is PEBKAC, but most of the time the bug reports are legitimate. People don't like thinking they are contributing to a project by filing a report only to be ignored. I can think of some large software projects where that happens regularly.
In summary: 1) people are not seeing positive motion with the bug tracker because important bugs remain unresolved, and 2) this list does not serve its purpose with generating help with build and development issues.
For the record, I continue to use KDE3 more than Trinity. Why? Bugs and build issues that remain unresolved. Despite all of my efforts I am unable to eat my own dog food. Between the two environments, my KDE3 system is less buggy and less frustrating.
We start acting like a team and start addressing bug reports and build issues or we let this project die. I'm willing to bust butt to make this software work --- and I have busted butt, but I also am willing to move on. The natives are getting restless. That is the heart of this discussion.
Darrell
On 04/15/2012 07:22 PM, Timothy Pearson wrote: Sounds like we need to get R14.0 out the door ASAP,
even if it it slightly buggy, so that we can start working on more fundamental problems.
Thoughts are welcome!
Tim
OK, 'tempered..'
NO, NO, NO, NO! I know I always come back to this, but it is always better to "get it right" even if it takes a bit longer, than to "get it out the door" and then pay the price of increased bug reports and support issues that can be completely avoided by simply taking a bit more time to begin with.
I would propose that R14 NOT be release until:
(1) libpng15 issues are fixed (digikam, etc..); and (2) it builds without '-fpermissive' on gcc47
Otherwise, we are releasing an R14 with no digikam, etc.. due to libpng15 and code that cannot be built on systems with the current gcc without fudging it. Also, there hasn't been confirmation that tde continues to operate normally with the dependencies built on gcc47.
I would rather see a tde 3.5.13-3 than a 3.5.14-1. It just make sense to me to have the next release be solid and build on the current gcc. I don't think we will see another gcc upheaval for some time. With many distros moving to gcc47, I think we iron those issues out before release.
That's just my cut on it. Spend a little more up-front, save a whole-lot-more on the backside...
On 04/15/2012 07:22 PM, Timothy Pearson wrote: Sounds like we need to get R14.0 out the door ASAP,
even if it it slightly buggy, so that we can start working on more fundamental problems.
Thoughts are welcome!
Tim
OK, 'tempered..'
NO, NO, NO, NO! I know I always come back to this, but it is always better to "get it right" even if it takes a bit longer, than to "get it out the door" and then pay the price of increased bug reports and support issues that can be completely avoided by simply taking a bit more time to begin with.
I would propose that R14 NOT be release until:
(1) libpng15 issues are fixed (digikam, etc..); and (2) it builds without '-fpermissive' on gcc47
Otherwise, we are releasing an R14 with no digikam, etc.. due to libpng15 and code that cannot be built on systems with the current gcc without fudging it. Also, there hasn't been confirmation that tde continues to operate normally with the dependencies built on gcc47.
I would rather see a tde 3.5.13-3 than a 3.5.14-1. It just make sense to me to have the next release be solid and build on the current gcc. I don't think we will see another gcc upheaval for some time. With many distros moving to gcc47, I think we iron those issues out before release.
That's just my cut on it. Spend a little more up-front, save a whole-lot-more on the backside...
OK, will do! You and Darrell have convinced me that this is the correct course of action.
I would ask this: Please make an Etherpad of prioritized non-build bug numbers so that we all know which bugs should be dealt with first. Seeing build bugs constantly crop up on this list doesn't help me, as TDE builds just fine here and I would like to start fixing bugs that are not build-related.
As an aside, including a replication procedure in each bug report really, really helps a developer pick it up to start repairing it. I know Darrell does a good job of this, but perhaps other members of the team could do some triage and append a bug replication process to bug reports that do not currently contain one?
Thanks!
Tim
As an aside, including a replication procedure in each bug report really, really helps a developer pick it up to start repairing it. I know Darrell does a good job of this, but perhaps other members of the team could do some triage and append a bug replication process to bug reports that do not currently contain one?
How about just looking through every bug report and making sure they are organized, still valid, and are actual issues? I mean i know it's dull and there are hundreds of bugs, but there's always a few that linger that have been solved or need status changes. I feel bad telling anyone to sit there for hours and look over each page, manually testing each problem, but it might be well worth it.
Calvin
As an aside, including a replication procedure in each bug report really, really helps a developer pick it up to start repairing it. I know Darrell does a good job of this, but perhaps other members of the team could do some triage and append a bug replication process to bug reports that do not currently contain one?
How about just looking through every bug report and making sure they are organized, still valid, and are actual issues? I mean i know it's dull and there are hundreds of bugs, but there's always a few that linger that have been solved or need status changes. I feel bad telling anyone to sit there for hours and look over each page, manually testing each problem, but it might be well worth it.
No need for exhaustive energy and time. Use the advanced search features. Here is what I see:
Blockers: 20 Critical: 31 Major: 74 Normal: 159 Minor: 72 Trivial: 18 Enhancement: 113 Wish list: 7
Granted, one person's "Blocker" is another person's "Works for me." Regardless, if a person takes the time to file a bug report, regardless of perceived category, then let's not waste time arguing category. Just fix the bugger.
No need to get fancy or get overwhlemed. Let's start with the Blockers.
As I mentioned in a previous post, there are patterns to many of these bug reports. For example, teach me how to resolve one of the "Sym Links Incorrect" reports and likely I can resolve the others. Teach me how to resolve one of the "unknown icon type" reports and likely I can handle the others.
This is the case for many of the bug reports. People like David and me need only an example or two and we are sufficiently motivated thereafter to resolve similar issues and propose a patch for related bugs.
That's what this list should do: help one another so we all learn. As we each learn we reduce the load against any one person. As we each learn we more quickly resolve future related bugs because more people know the solution. The faster we work as a team, the happier the users.
Note: I am updating all reports I filed that are related to building and added "Build issue:" as a description prefix, even if the package builds with work-arounds. I will browse the entire bug list and append obvious reports with the same prefix and provide an update to this list later.
Darrell
On 04/16/2012 04:00 PM, Darrell Anderson wrote:
Note: I am updating all reports I filed that are related to building and added "Build issue:" as a description prefix, even if the package builds with work-arounds. I will browse the entire bug list and append obvious reports with the same prefix and provide an update to this list later.
Darrell
I will have more information on the function of the core of tde built on gcc47 by lunch tomorrow. I have a build going currently that is building i686 on gcc47 that will hopefully answer that question at least for arch. After sorting the kcontrol/patch issue, I think that the core will function when totally built on gcc47, but I want to confirm that. Judging from the version info from other distros on this list, that should give us a good idea on the status on R14 and currently libraries and compilers.
The good news is that out of all the dependencies that get built up to 'tdebase', tdebase is the ONLY package that requires '-fpermissive'. That is out of the list:
'hal-info' 'hal' 'libutempter' 'xmedcon' 'libnjb' 'libkarma' 'mt-daapd' 'dependencies/tqt3' 'dependencies/tqtinterface' 'dependencies/arts' 'dependencies/dbus-tqt' 'dependencies/dbus-1-tqt' 'dependencies/tqca-tls' 'dependencies/libart-lgpl' 'dependencies/avahi-tqt' 'dependencies/libcaldav' 'dependencies/libcarddav' 'dependencies/sip4-tqt' 'dependencies/python-tqt' 'tdelibs' 'tdebase'
The list of packages after tdebase that currently require -fpermissive on gcc47 (some needed it with gcc46) are:
amarok: CXXFLAGS="${CXXFLAGS} -I/usr/include/ruby-1.9.1 -fpermissive" \ digikam: CXXFLAGS="${CXXFLAGS} -fpermissive" \ kaffeine: CXXFLAGS="${CXXFLAGS} -fpermissive" \ kipi-plugins: CXXFLAGS="${CXXFLAGS} -fpermissive" \ kmplayer: CXXFLAGS="${CXXFLAGS} -fpermissive" \ koffice: CXXFLAGS="${CXXFLAGS} -fpermissive" \ krusader: CXXFLAGS="${CXXFLAGS} -fpermissive" \ python-tqt: CXXFLAGS="${CXXFLAGS} -I/usr/include/tqt -I${TDEDIR}/include -I${QTDIR}/include -fpermissive" rosegarden: -DCMAKE_CXX_FLAGS="-fpermissive" \ tdeadmin: CXXFLAGS="${CXXFLAGS} -fpermissive" \ tdeedu: CXXFLAGS="${CXXFLAGS} -fpermissive" \ tdegames: CXXFLAGS="${CXXFLAGS} -fpermissive" \ tdegraphics: -DCMAKE_CXX_FLAGS="-fpermissive" \ tdepim: -DCMAKE_CXX_FLAGS="-fpermissive" \
Yesterday I ran a complete build for Slackware 13.37 (gcc 4.5.2.). I still need to create testing partitions for Slackware Current, which uses gcc 4.7. Consider Current the equivalent bleeding edge of Arch. :)
Darrell
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Timothy Pearson