15 Apr
2012
15 Apr
'12
11:02 p.m.
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
12:22 a.m.
New subject: [trinity-devel] kpowersave now working without HAL
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 
12:55 a.m.
New subject: [trinity-devel] kpowersave now working without HAL
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
4:18 a.m.
New subject: [trinity-devel] kpowersave now working without HAL
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?
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
4:55 a.m.
New subject: [trinity-devel] kpowersave now working without HAL
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.
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
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. 
1:29 p.m.
On 04/16/2012 12:55 AM, Darrell Anderson wrote:
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.
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.
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
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.
7:45 p.m.
New subject: [trinity-devel] Re: kpowersave now working without HAL
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
6:30 p.m.
New subject: [trinity-devel] kpowersave now working without HAL
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...
--
David C. Rankin, J.D.,P.E.
8:11 p.m.
New subject: [trinity-devel] kpowersave now working without HAL
On 04/15/2012 07:22 PM, Timothy Pearson wrote:
Sounds like we need to get R14.0 out the door ASAP,
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
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...
8:13 p.m.
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
9 p.m.
New subject: [trinity-devel] Re: kpowersave now working without HAL
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.
11:01 p.m.
New subject: [trinity-devel] Re: kpowersave now working without HAL
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" \
--
David C. Rankin, J.D.,P.E.
11:15 p.m.
New subject: [trinity-devel] Re: kpowersave now working without HAL
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
4395
days inactive
4396
days old
13 comments
4 participants
participants (4)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Timothy Pearson