devel October 2003

devel@lists.fedoraproject.org

203 participants
210 discussions

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

Bugzilla System Back
by Dave Lawrence 01 Oct '03

01 Oct '03

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

1 0

Idea for website
by Pekka Pietikäinen 01 Oct '03

01 Oct '03

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

6 6

PDR -- Package development repostory to replace SRPM's? (fwd)
by Chris Ricker 01 Oct '03

01 Oct '03

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

1 0

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: Kind request: Set release version to "10"
by Rex Dieter 01 Oct '03

01 Oct '03

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

1 0

Re: PowerPC support
by axel c 01 Oct '03

01 Oct '03

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>

3 4

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

For those with RHN applet rendering problems
by Daniel Veillard 01 Oct '03

01 Oct '03

Those who got hit by the "1 pixel wide" applet problem can test the 1.0.12 release which should incorporate a fix, if you still see the problem after upgrading and restarting the applet, please state so in bug #75225 : updated packages: http://people.redhat.com/~veillard/rhn-applet/ related bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75225 TIA, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

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

Jump to page:

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