* Thu Mar 25 2004 Anaconda team <bugzilla(a)redhat.com>
- built new version from CVS
* Tue Feb 24 2004 Jeremy Katz <katzj(a)redhat.com>
- buildrequire libselinux-devel
* Thu Nov 06 2003 Jeremy Katz <katzj(a)redhat.com>
- require booty (#109272)
How about this for an idea.
When doing a kickstart install instead of asking me which ethernet
device I want to use anaconda could just use the first interface with
link. I'm always doing network installs on dual NIC machines and I
have to specify the ethernet device which is annoying.
Now if I knew python I'd check it out, maybe I'll try anyway :)
Anybody else have this problem?
About six months ago, as the result of a conversation on IRC, I began
playing with the idea of a "tracker" for Fedora: Something to tie
together the many apt and yum repositories out there into a single,
simple to use framework.
There is, of course, a great deal of software available for Fedora
outside of the core package set. But the question I kept running into
was "How do I figure out which repository, if any, has the package I'm
looking for, assuming I even know the name of the package in the first
None of the answers to this question that I'd come across were really
satisfactory. They either required me to already have a comprehensive
list of third-party repositories (synaptic) or were too general (google,
rpmfind, etc). So, partly to scratch this itch and partly to teach
myself Python, I started work on a tool for easily indexing and
searching Fedora repositories.
I've been quiet about things because until now the Fedora Tracker was
mostly an educational project. But it's now at a point where I think it
could be of use to others and I'd appreciate some constructive
criticism. I'm announcing it on this list instead of fedora-list because
I'd don't know how much traffic my webhost can handle and I'd like to
stress-test it with a smaller group of well-clued people first.
The url is:
Since this is my first python project, any feedback regarding the
quality of the code would also be appreciated. I figured out a lot of
this stuff, like how to dissect the rpm headers, "by ear", so no doubt
there are many places where my approach could be improved upon. Should
anyone care to peruse it, the code is available here:
The app basically consists of two components: The web-based frontend
allows users to search indexed repositories and submit repos for
indexing. Another tool called tracker-process.py runs as a cron job and
pulls down the headers for each queued repo, storing that info in the
There is more that I plan to do, but since my work at Red Hat is
unrelated to the Tracker project (or development of any sort) how soon I
can do more is dependent upon how much free time I have (not much at the
moment). That said, here are the main items on my TODO list:
- Support for repo-side configuration. I would implement this by having
tracker-process.py look for a "tracker.conf" file in the headers or base
directory of a repo. By modifying this file, the administrator of a repo
could specify a list of mirrors for the repository, alter the repository
description, indicate when the repo should be re-indexed, etc.
- Support for updating a repository that has been indexed (see above)
- Support for storing a list of mirrors for a repository (see above)
- Support for the proposed common XML-based metadata format
- Improvements to the searching mechanism, such as protecting quoted
strings (currently the search is either done as a series of AND'ed
keyword matches or as one big regex match).
- Ability to display dependencies (for the life of me I cannot figure
out how to interpret the dependency data in the rpm headers). Any
reference to documentation would be appreciated.
- Improvements to the user interface. For example, currently if a search
yields multiple versions of the same package they are all listed. When I
have some time I'm going to change this so that packages with multiple
versions/architectures are displayed under one package name and only
expanded when the package is selected.
- Index Fedora Core packages. Currently this is a problem because the
default repository is too busy for tracker-process.py to be able to
reliably index it. Once support for mirrors is set up, this should not
be a problem. Alternately, I could just index a mirror and then change
the url in the database. =;)
- Comment things more thoroughly and convert existing comments to pydoc
- Re-arrange files so that the url is more accessible
- Whatever else comes to mind or is suggested to me =;)
Thanks to everybody who helps make Fedora such a fun distro to use!
I need help about constructing comps.xml and stage2.img for Fedora.
We build a new distro called Libertas (http://libertas.pbh.gov.br) based
on Fedora Core and we want to change files above.
Thanks in advance
* Wed Mar 24 2004 Bill Nottingham <notting(a)redhat.com> 1.3.8-1
- fix writing of config file if neither of --disabled or --enabled are
passed (#118667, redux)
* Wed Mar 24 2004 Mike A. Harris <mharris(a)redhat.com> 0.0.6.6-0.0.2004_03_11.9
- Really added the xorg-x11-Xft-freetype-bitmap-font-fix.patch patch this time
as it was inadvertently left out of 0.0.6.6-0.0.2004_03_11.8 by mistake
I purchased a cheap Actiontec USB 802.11b adapter for my daughter's
computer yesterday, so I adapted my kernel-module-hostap spec for the
at76c503a driver. I've submitted the result here:
The driver works fine, but I'm having a silly little problem where the
driver always builds for SMP on my SMP system, even if I tell it to
compile for UP.
I would appreciate some assistance with this. Unfortunately I don't
have time to dig into this any more than I have already at the moment,
and this issue is the only thing that I can see keeping this package
out of QA.
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
Bea's Jrockit is also fast as before on Fedora Core 2 Test 1.
======= 2004-03-25 08:55:26 Quote from your mail =======
>Carwyn Edwards writes:
>> Is there any cooperation or plan in relation to this? As and end user
>> it's imperative for me that I should at least be able to plug in either
>> of the Sun/Blackdown/IBM sdks and get a full SDK runtime/toolset.
>Sun's SDK works reasonably well on Fedora i386.
>Sun's SDK oopses Fedora's x86_64 kernel.
>I don't remember the exact reason, but I could not get Blackdown's x86_64
>SDK to install. I think there were some library dependency issues with
>When I get some spare cycles I'll try to backport a more recent arch/x86_64
>tree to Fedora's kernel, in a vain hope to fix the bleeping kernel crash.
>I'm not that eager to play with it, since every time the kernel oopses I
>have to wait four hours to rebuild the bleeping RAID volumes.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>-----END PGP SIGNATURE-----
>fedora-devel-list mailing list
Does anybody know of any good mirror for the x86_64 RawHide? I used to
use kernel.org, but it now seems to be about a week out-of-date.
Home Page: http://nogin.org/
E-Mail: nogin(a)cs.caltech.edu (office), aleksey(a)nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907