Le mar 22/07/2003 à 21:58, Havoc Pennington a écrit :
> On Tue, Jul 22, 2003 at 12:47:47PM -0700, Howard Owen wrote:
> > How do you propose a package for inclusion under the new regime?
> > I have an auditing package called sudoscript that's been in contrib
> > since 1.0.something. It's now at version 2.2.1 with 3.0 in testing.
> > I'd like to maintain in RHL. What's the process?
> Well, that's the catch. We don't have the infrastructure in place yet.
> We've started by putting up a lot of our internal devel docs on
> rhl.redhat.com, and moving our devel discussion from internal forums
> to rhl-devel-list and #rhl-devel. So joining those is probably a good
> The problem is that our infrastructure for all the aspects of
> maintaining a package is still partially internal. So over the next
> months, we will be trying to break down the barriers to external
> Right now, to accept an external package we'd basically need someone
> internal to act as a proxy for you to build your SRPMs, we may do this
> for two or three packages, but it isn't going to scale at all.
Can we expect that this infrastructure will be an "open projet" in the
RedHat Linux Projet ?
> Rhl-list mailing list
Féliciano Matias <feliciano.matias(a)free.fr>
I'm a user of gtkmm for my internal development work, redhat releases currently
do not include a version of gtkmm-2 and this causes me a lot of problems.
Judging by the following bugzilla entry, I'm not alone.
With the announcement of the redhat linux project I was wondering what would be
required to get gtkmm (and the gnomemm packages) added to the redhat linux
Some of us on the mailing list have already indicated that we'll be able to
help with testing the spec files, builds, dependencies etc.
There's still some work to be done with the spec files, but the newly published
guidelines make this much easier to do. Once we have the spec files updated
and tested by a few of us with the new beta, what is the process we should
follow to get the package officially included?
This mail sent through IMP: http://horde.org/imp/
On Tue, 22 Jul 2003, Havoc Pennington wrote:
> On Tue, Jul 22, 2003 at 10:40:21AM -0700, Lawrence Mao wrote:
> > Just wondering whether RedHat or somebody else is
> > thinking about adding other lightweights window
> > managers besides that BlueCurve like Xfce, Fluxbox, or
> > Fvwm! BlueCurve is nice but I don't need all those
> > bells and whistles. I want something (window manager)
> > that is fast and doesn't take up a lot of system
> > resources...
> We aren't thinking of doing this ourselves at Red Hat, but alternative
> WMs are a prime example of the kind of package we'd like to see added
> to Red Hat Linux by others.
<hijacked this thread to a more appropriate mailing list ;-) >
Okay. I've got a fairly complete package of Openbox
<http://www.openbox.org/> -- IMHO probably the best of the Blackbox family
(blackbox, fluxbox, etc.) -- that I put together for fedora.
How do I go about submitting this package? I'll bugzilla it against the
distro for now, but what happens then?
Is xdirectfb installed in X by default? if not it should be, It's a tiny patch
but alot of work to recompile all of X every time there is a RH update for those
of us on low-end machines, or just not tech savy enough to install it.
[paul@uruk src]$ export
[paul@uruk src]$ cvs -z3 login
Logging in to :pserver:email@example.com:2401/usr/local/CVS
cvs [login aborted]: connect to rhlinux.redhat.com(188.8.131.52):2401
Connection timed out
I assume this just isn't setup yet.
I'm browsing through http://rhl.redhat.com/ -- looks good.
Under the Participate section, there's a "Developer's Guide" and a
"Documentation Guide". Any chance of those being posted in a format that's
easy to download / print (pdf, single inline html, or similar)?
I have a good idea for a big project,
any developer care to listen?
The development of Linux is always
depend on chance, not certainity.
It maybe the biggest hinderance for
Linux to become a real competitive
For Linux to run well, either kernel
and softwares has to be tested on
many different hardwares platform
(combination of CPU and other
components). Currently, if some developer
has developed a program, s/he
will post it in E-mail/mailing list,
then wait for someone of unknown
hardware platform to test it. S/he:
1.) Can NOT TARGET a certain
hardware platform for beta-test,
it all depend on his/her luck;
2.) Can NOT expect a response within certain time limit;
3.) May NOT able to test the program on ALL hardware platform
for a long time.
To overcome this, how do we TURN every
Linux user automatically a beta-tester without
ANY technical background?
The answer lie in a specially made kernel:
It will allocated a protected area of CPU which
is open for ALL developer in the world for
beta-testing his/her program. For instance, if
a developer is writing a program called K which
he want to test on hardware platform A,B and C, he
will just have to activate a searcher in his Linux,
then the searcher will look at the hardware profile
of all Linux in the world to find a match; if a match
is made, then the program is travel through www to
these specific computer; the program is executed in
the special area of CPU which will NOT affect what
the owner is doing, then the result is sent back
to the original developer for comparison. Now the
developer can get results for ANY specified hardware
platform in an expect time, it does NOT depend on
luck or chance! S/he could get MANY MANY MANY
results from MANY MANY MANY different hardware
platform within a short time, and s/he should
NEVER worry about un-tested platforms since the
whole Linux community's CPU is open for him/her.
Moreover, instead of waiting for some human to
pick it up from a list then test it then post the
result, everything is now done AUTOMATICALLY
without the help of owner, the developer can
COUNT on getting the result within hours or even
minutes, how much it will SPEED UP the Linux
development? Any taker of this idea? Anyone want
to write a new chapter of Linux development?
I believe developmental process is key aspect
to improve and refine if Linux want to stay ahead.
Thanks in advance!