grub.conf, please?
by Chris Wilson
Could someone kindly sed me their grub.conf file?
I made a booboo and installed a redhat test kernel rpm and when
uninstalling it I got this msg:
grubby fatal error: unable to find a suitable template
I got the same error when yumming the original kernel back in.
thanks,
chris
PS: Where can I find a fedora 2.6 test kernel?
20 years, 6 months
redhat logo on gnome menu / menu bar.
by Trae McCombs
Sorry if this is off-topic... (If it is, please tell me what list I need
to direct this to).
I know a wee bit about marketing, and I don't know if anyone has brought
it to the attention of those in the know at RH's branding department
about the fact the RH logo is still present in the fedora test2 0.94
release.
I would suggest replacing it with the "favicon" that is present on the
fedora.redhat.com website.
The convention would be that under the Enterprise edition, the RH logo
would be present(on the menu bar and other places), and on Fedora Core,
a Fedora logo would be present. I think the [F] favicon would suffice
in this area unless there is work being done on an official fedora
logo.
The idea, from what I have gathered, is to split out the two identities:
a.) Fedora -- community distro
b.) Redhat -- Enterprise server
Sorry if I've missed something here.
-Trae
20 years, 6 months
Fedora Project: Announcing New Direction
by Michael K. Johnson
Red Hat and Fedora Linux are pleased to announce an alignment of their
mutually complementary core proficiencies leveraging them synergistically
in the creation of the Fedora Project, a paradigm shift for Linux
technology development and rolling early deployment models.
We are <...> *thud*
One two ... one two ... testing, is this thing on?
Hello, this is, um, the Engineers speaking. We are still really excited
about the project, but this time we have more than just dates. We hope
fedora.redhat.com will answer lots of your questions, and are sure it
will pose a few new ones.
Why Fedora?
Red Hat has a lot of experience in building solid dependable core
distributions while the Fedora Linux Project has lots of experience in
building effective infrastructure and policy to create many high quality
add on packages. Both groups decided to merge the two projects and build
outward using our shared experience, and to use the name "Fedora Project".
We don't pretend the merge will be smooth or immediate, but we firmly
believe that working with the Fedora Linux Project will get external
projects and add-ons up and running better and faster than we could on
our own and we are proud to be working with them.
The Fedora Project is something special. It enables Red Hat and the
community to work together to provide the community with rapid rolling
releases and to get new technology into the hands of developers.
With the solid establishment of Red Hat Enterprise Linux, Red Hat
now has a platform for predictable change and high quality support
for customers, and for our ISV and IHV partners. Fedora is about
the community, about cool new technologies, and extending existing
Red Hat tools in a collaborative community. Our new up2date, for
example, supports YUM and apt-get repositories.
Fellow Fedorans, a new dawn is upon us, let us begin.
Please note:
The http://rhl.redhat.com/ web site has been renamed
http://fedora.redhat.com/ and the mailing lists have all been renamed:
rhl-list(a)redhat.com -> fedora-list(a)redhat.com
rhl-beta-list(a)redhat.com -> fedora-test-list(a)redhat.com
rhl-devel-list(a)redhat.com -> fedora-devel-list(a)redhat.com
rhl-docs-list(a)redhat.com -> fedora-docs-list(a)redhat.com
Your subscriptions have been preserved, moved over to the new names
for the lists.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
20 years, 6 months
Re: Fedora Project: Announcing New Direction
by Jesse Keating
On Tuesday 23 September 2003 13:10, Paul Iadonisi wrote:
> I am not a Red Hat employee or a lawyer, but I think you would be
> in violation of Red Hat's contract for RHEL if you did that.
> (Whether or not Red Hat's contract violates the GPL *has* been
> brought up in other forums, but I think the fact that complete
> sources are available may be sufficient. In fact, the company even
> provides the sources to the non-GPL pieces that isn't required by
> most of the other licenses.)
I don't think it's RHEL's license in question, but what about RHN's?
Isn't it RHN's license that states if you have one hooked up, you must
have all, or is it RHEL's?
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
20 years, 6 months
Re: Kind request: Set release version to "10" (was: Retain upgrade paths)
by Rex Dieter
Sean Middleditch wrote:
> Could someone please explain why the distro version matters in any way
> shape or form for any packages save the two or three things like
> 'fedora-release' ?
(clean) Upgradability from packages currently in fedora, before Fedora Core
existed.
> If you're package is depending on the distro
> version, and not the actual components in the distro, your package is
> probably broken.
In general, I agree with you. I can also assure you, there are good
reasons for (sometimes) doing it, but I digress...
If you read the original post, Axel's concern to upgradability from the
previous fedora release naming standard. A concern of mine is that I
maintain packages for all redhat releases going back to rh73, and I do it
all from a single src.rpm, and dynamically generate a Release tag based
upon the contents of /etc/redhat-release. Like Axel, I also would like to
maintain upgradability from previous releases. I argue that having to
increment Epoch solely for the purpose overcoming the Release drop (9 ->
0.9 ) to maintain upgrade paths is yucky.
-- Rex
20 years, 6 months
HAL 0.1 available
by Havoc Pennington
Hi,
I haven't looked at this implementation yet, but I've been cheerleading
the idea.
Havoc
20 years, 6 months
release version numbers
by Paul Heinlein
I'd like to submit a patch to Mark Burgess so that cfengine can
correctly parse Fedora's /etc/redhat-release file. I'm wondering if
there's an official roadmap for version numbers. Currently, it's 0.94,
so I assume that the first release will be 1.00. Or will it be 1.0? Or
1.0.0? And how will the numbers progress?
seq 1 seq 2 seq 3
------- ------ -----
1.00 1.0 1.0.0
1.10 1.1 1.1.0
1.15 1.1p5 1.1.5
2.00 2.0 2.0.0
Or will there be a sequence altogether?
Thanks!
--Paul Heinlein <heinlein(a)madboa.com>
20 years, 6 months
alpha sparc mips ?
by Balint Cristian
Hi !
I know it was already clarifyed the situation on redhat list and IRC of these arch from
RedHat point of view but in new conjucture "Fedora" may i ask again
if there are some movements or not to build for these arch too (like debian)
cristian
--
Life in itself has no meaning.
Life is an opportunity to create meaning.
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
20 years, 6 months
Re: PowerPC support
by Stephen Smoogen
On Tue, 2003-09-30 at 13:43, Paul Iadonisi wrote:
> On Tue, Sep 30, 2003 at 06:20:43AM -0400, mike(a)flyn.org wrote:
> > Is there any plans to add a PowerPC build of Fedora?
>
> [snip]
>
> > Are there any like-minded folks out there?
>
> Yes. Me. ;-)
>
> Well, not just PowerPC, but also some other non-x86 platforms in general.
> One request I'd like to make to Red Hat (and any other package maintainers)
> is to please, please, please, don't make rpms ExclusiveArch unless absolutely
> necessary. I realize that may already be the case, but I'm just putting my
> two cents in for this. This comes up now as I notice that, though it appears
> from the changelog that it is temporary, today's errata for openssl is
> exclusive to x86 :-(. I have found on several occasions that rpms with the
> ExclusiveArch tag in the spec file build and work fine on both Alpha and
> Arm (netwinder) once the tag is removed. Isn't there an ExcludedArch tag
I think the reason for ExclusiveArch is that the software hasnt been
tested on any other arch. Since Red Hat gives SLAs for those errata..
making sure that people dont complain about broken RPMS (even if they
broke it themselves.. ) cuts support costs. Of course I might be smoking
up a fantasy here.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
20 years, 6 months
Fedora security announce and discussion lists
by Nathan Grennan
I strongly believe that Fedora needs lists for announcement and
discussion of security issues. This is to prevent the potential
nightmare of the Core gets patched as usual by Red Hat, but packages by
outside maintainers are stale for much longer because some maintainer
isn't on every security mailing list. I think the announcement list
should be low noise and controlled by someone at Red Hat, or a trusted
member of the community. Just make announcements of security problems in
a similar way to Red Hat's errata notes for security issues. Then there
can be a second list to discuss them to get the fixes working and tested
ASAP.
This idea came to be because of the issue with running things from
rawhide has always been a security risk. You never know when the
maintainer will make a new rawhide package with the necessary security
fix for the latest exploits. This especially becomes an issue for things
like Fedora Alternatives, Fedora Extras, and Fedora Legacy. Along with
maintainers outside of Red Hat doing Fedora Core packages.
I am a strong advocate of full disclosure. I think both lists should
be open to the public for subscription. This is meant to be a community
project and I think the whole community should be able to stay informed.
I have heard others mention they are generally for full disclosure, but
not in all cases. I don't see how you can exactly draw a line. The idea
behind full disclosure is to motivate whoever is responsible to get it
done ASAP. I also think in general full disclosure is less of an issue
in most cases, because most exploits effect all distributions or
operating systems that use a certain piece of software, not just a
certain distribution. We will be more reacting to outside information
than reacting to problems we discover ourselves. I think that informing
all the the community about how we are reacting to outside information
on the lists outweighs the risk posed by disclosing information we
discover ourselves.
Another idea I just had while writing this is for a security-audit
team be created from members of the community to volunteer to review
code for exploits. Also verify that patches for exploits were while not
creating new exploits.
20 years, 6 months
