devel September 2003

devel@lists.fedoraproject.org

139 participants
90 discussions

grub.conf, please?
by Chris Wilson 01 Oct '03

01 Oct '03

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?

3 3

redhat logo on gnome menu / menu bar.
by Trae McCombs 01 Oct '03

01 Oct '03

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

21 34

Fedora Project: Announcing New Direction
by Michael K. Johnson 01 Oct '03

01 Oct '03

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/

23 51

Re: Fedora Project: Announcing New Direction
by Jesse Keating 01 Oct '03

01 Oct '03

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

8 13

Re: Kind request: Set release version to "10" (was: Retain upgrade paths)
by Rex Dieter 01 Oct '03

01 Oct '03

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

3 2

HAL 0.1 available
by Havoc Pennington 30 Sep '03

30 Sep '03

Hi, I haven't looked at this implementation yet, but I've been cheerleading the idea. Havoc

4 5

release version numbers
by Paul Heinlein 30 Sep '03

30 Sep '03

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>

4 5

alpha sparc mips ?
by Balint Cristian 30 Sep '03

30 Sep '03

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_/

3 2

Re: PowerPC support
by Stephen Smoogen 30 Sep '03

30 Sep '03

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 --

1 0

Fedora security announce and discussion lists
by Nathan Grennan 30 Sep '03

30 Sep '03

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.

4 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2003