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
Bugzilla System Back
by Dave Lawrence
Due to technical failures, bugzilla.redhat.com was down for a period of
time on Wednesday morning EST, Oct 1st. It has since been resolved and
should be accessible again. Unfortunately there was some slight data
loss involved. If you filed a bug report or made any bug changes from
4:00 am EST Sept 30th to 9:00 am Oct 1st, please refile them if
possible. Sorry for the inconvenience.
Thanks
David Lawrence
Red Hat, Inc.
--
fedora-list mailing list
fedora-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-list
20 years, 6 months
Idea for website
by Pekka Pietikäinen
After downloading a 32MB kernel .src.rpm for the n+1:th time just
to look at a 4k patch, I came up with a pretty useful feature for
the website. Basically a "rpm2html" thing (not the existing one, which
does something different), which just basically lets you browse
.src.rpm's in rawhide and grab invidual files from inside the archive.
Or am I the only one who grabs .src.rpm's all the time to figure out
what exactly have they done this time? :-)
--
Pekka Pietikainen
20 years, 6 months
PDR -- Package development repostory to replace SRPM's? (fwd)
by Chris Ricker
Jeff posted this to rpm-list, but it seems of interest to many on here who
might not be on the rpm list....
later,
chris
---------- Forwarded message ----------
Date: Wed, 01 Oct 2003 15:59:56 -0400
From: Jeff Johnson <n3npq(a)nc.rr.com>
Reply-To: rpm-list(a)redhat.com
To: rpm-list(a)redhat.com
Subject: PDR -- Package development repostory to replace SRPM's?
In the interest of looking seriously at build dependency
loops involved in bootsrapping a distro, I've set up a
publci CVS repository for exploded severn2 *.src.rpm's at
:pserver:anoncvs@cvs.colug.net:/home/cvs
The following commands should get anyone who is interested
in using the public package development repository started:
$ cd /var/tmp
$ cvs -d :pserver:anoncvs@cvs.colug.net:/home/cvs login
Logging in to :pserver:anoncvs@cvs.colug.net:2401/home/cvs
CVS password:
$ cvs -d :pserver:anoncvs@cvs.colug.net:/home/cvs get severn2/severn2
U severn2/severn2
The entire repository was set up with the severn2 script checked out
above in approximately one hour, not hard at all.
Note: The cvs.colug.net repository is ~2GB in size. *Please* make sure
you have the bandwidth and diskspace (and attention span ;-) to
handle that large a checkout before attempting the entire repository.
I expect to have cvsweb set up in the next day or so. See the severn
repository at
http://cvs.fedora.us
for what will be at cvs.colug.net soonish.
The severn2 script (aka "mkrpm") is a toy, but was quite fun to write.
Invoke the script with no arguments for a usage message. You will need
to edit the script to reflect the location of your local checkout.
Please note that the script is merely a prototyping toy, and
will probably be discarded in favor of better tools soon.
My goal with mkrpm is to try and establish conventions
for file organization, a vendor branch, and tag structure
for a package repository. If the conventions can be
established, then it will become possible to attempt
distro level build systems and to teach rpmbuild some
new tricks.
Another reason for exploding *.src.rpm's into a repository
is that I believe that src.rpm's are not the most effective
means for distributing software.
Don't misunderstand me, src.rpm's make very good bricks, and src.rpm
bricks usually come with the implicit rpm guarantee that the src.rpm
was produced by taking virgin sources, applying patches, and running
a spec file through rpmbuild from soup to nuts. That is a very sensible
guarantee for a brick.
However, src.rpm bricks, just like *.tar.gz, hide the internals. Say
a package has been rebuilt, and the Release: tag has been incremented
to reflect the change. There is no way to discover that nothing else
of interest has changed in the src.rpm without downloading the entire
brick. Brick's are bandwidth heavy.
Another problem with src.rpm's is that they do not mirror well with rsync.
Since the file name changes with each new brick produced, rsync usually
lacks the proper end point references to attempt deltafication, so
mirroring src.rpm's with rsync often has no bandwidth savings at all.
Yet another problem with src.rpm's is that it is difficult to
merge patches together from independent lines of development.
Well, it's not difiicult, just more tedious than necessary. ;-)
In order to address the lack of patch coherency from independent
development efforts, I've also set up a cvsup (yes, modula3) mechanism
for mirroring repositories.
There are cvsup packages at http://fedora.us if you are interested.
I've also added cvsup to the severn2 repository so you should
be able to build your own cvsup packages (assuming that your
machine is set up to build packages) by doing:
$ cd /var/tmp
$ cvs -d :pserver:anoncvs@cvs.colug.net:/home/cvs login
Logging in to :pserver:anoncvs@cvs.colug.net:2401/home/cvs
CVS password:
$ cvs -d :pserver:anoncvs@cvs.colug.net:/home/cvs get severn2/severn2
U severn2/severn2
$ cvs -d :pserver:anoncvs@cvs.colug.net:/home/cvs get severn2/cvsup
cvs server: Updating severn2/cvsup
U severn2/cvsup/cvsup-contrib.patch
U severn2/cvsup/cvsup-snap-16.1h.tar.gz
U severn2/cvsup/cvsup.spec
U severn2/cvsup/cvsupd.conf
U severn2/cvsup/cvsupd.logrotate
U severn2/cvsup/cvsupd.rc
U severn2/cvsup/ezm3-1.1-LINUXLIBC6-boot.tar.bz2
U severn2/cvsup/ezm3-1.1-src.tar.bz2
$ cd /var/tmp/severn2/cvsup
$ ../severn2 topdir=/var/tmp/severn2 build >& x
$ ls *.rpm
cvsup-16.1-1.i386.rpm cvsupd-16.1-1.i386.rpm
cvsup-16.1-1.src.rpm cvsup-debuginfo-16.1-1.i386.rpm
cvsup-contrib-16.1-1.i386.rpm
and then install cvsup from those packages.
To use cvsup to mirror the "testing" collection, put the following in
/var/tmp/testing.sup:
*default host=cvs.colug.net
*default base=/var/tmp/ncvs
*default release=severn2
testing
and invoke as
$ mkdir /var/tmp/cvscolog
$ cvsup -g testing.sup
Connected to cvs.colug.net
Updating collection testing/severn2
Mkdir time
Create time/time-1.7.tar.gz,v
Create time/time.spec,v
SetAttrs time
Finished successfully
to get your own "testing" subset of the cvs.colog.net repository.
The cvscolog repository mirror can then be used (including check-in's)
locally just like any local cvs repository, for example,
cvs -d /var/tmp/cvscolog get severn2/time
etc etc.
At the moment there are only 2 collections:
testing as above
all everything
I'll be happy to add other reasonable collections and am looking
for suggestions.
Enjoy!
73 de Jeff
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: Kind request: Set release version to "10"
by Rex Dieter
Axel wrote:
> > I don't know about you Axel, but until I see a better alternative,
> > I'll personally be inflating Fedora X.Y to rh(X+10)Y in the release
> > tag of packages I maintain. The only other alternative is to simply
> > increment Epoch for everything, which is yucky, yucky.
>
> Exaclty. As packagers we have been painfully tought not to use epochs
> unless WW3 is about to emerge.
>
> I'll also go with your suggestion, Rex. I'd call it the "it's written
> rh10, but it is pronounced Fedora Core 1" idiom ...
Hmm, on further consideration, I think I'll probably cave in on using rh10
and instead go with fedora's guidelines, but only because I desperately
want the packages I maintain to continue to be provided by fedora (and my
packages will most likely be rejected if I don't "follow the rules"). In
doing so, I'll still have to change my once relatively clean rpm macros
from:
%define rhversion %(perl -pe '/(\\d+)\\.?(\\d)?/; $_="$1".($2||0)' \
/etc/redhat-release)
%define fedora_release .fdr.1.rh%{rhversion}
...
Release: 0%{fedora_release}
to something conditional like:
%if "%(grep "Red Hat Linux" /etc/redhat-release )" != "%{nil}"
# legacy Red Hat Linux releases
%define rhrelease %(perl -pe '/(\\d+)\\.?(\\d+)?/; $_="$1".($2||0)' \
/etc/redhat-release )
%define release_tag .fdr.%{fedora_release}.rh%{rhrelease}
%else
# Fedora Core, etc...
%define rhrelease %(perl -pe '/(\\d+)\\.?(\\d+)?/; \
$_="$1".(defined($2)&&".$2")' /etc/redhat-release )
%define release_tag .fdr.%{fedora_release}.%{rhrelease}
%endif
...
Release: 0%{release_tag}
*Sigh*.
-- Rex
20 years, 6 months
Re: PowerPC support
by axel c
On Tue, 2003-09-30 at 21:43, Paul Iadonisi wrote:
> Given that Fedora is intended for
> the hobbyist, developer, enthusiast, I'm hoping that the answer is yes.
> Just trying to keep my custom src rpms to a minimum.
I'm a bit confused by that bit. If Fedora is focused on the 'developer,
hobbyist, enthusiast', does that mean there won't be a RedHat for the
Basic, Unskilled, Clueless Joe Desktop User?
Cheers,
--
axel c <axel(a)banzais.org>
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