We currently run many test servers, 3 app servers and 10 Build servers
off of Fedora 6. Do we
A) Upgrade everything to Fedora 7
B) Upgrade nothing to Fedora 7
C) Upgrade things as needed.
I'm for C. I think the mash server may already have a request to be
upgraded. The others I don't think there is a compelling reason to
upgrade and we should wait for Fedora 8 or until something comes up that
may require it.
Hello, this is a repost of a message to fedora-devel, as this seems to
be the place for it.
> From: Jesse Keating <jkeating(a)redhat.com>
> On Friday 08 June 2007 14:24:47 Anthony Bryan wrote:
> > I was hoping Fedora could investigate using Metalinks for their ISO
> > downloads. Metalink is an XML format for listing all the ways you can
> > get a file or collection of files (mirrors + their location, rsync,
> > p2p) along with checksums to automatically repair a file in case of
> > error, signatures, language, OS/arch, and other metadata. It's mainly
> > used for large files like ISOs, where errors can be very frustrating.
> > It's supported by about 20 programs on unix, mac, and win, including
> > aria2 (already in the Fedora repos). It's used by openSUSE,
> > OpenOffice.org, cURL, and many other distributions.
> > Here's a screenshot of a Metalink download in the DownThemAll Firefox
> > extension (nightly build). What you don't see are all the mirrors and
> > checksums.
> > http://code.downthemall.net/maierman/metaselect4.png
> > http://en.wikipedia.org/wiki/Metalink
> This is something interesting, and I wonder if we could make use of
> MirrorManager ( https://hosted.fedoraproject.org/projects/mirrormanager ) to
> have dynamic .metalink files created with updated mirror readiness info.
> Certainly something that looks worth looking into.
That would be quite nice, no one else has dynamic .metalinks on a
large scale. When I got the F7 ISO, I noticed it would fit in well w/
the download pages which tell which mirrors have which releases. I
think it would make things less frustrating for end users trying to
get things, and hopefully create less strain on mirrors. Certain
metalink clients will download from domestic mirrors first, if country
info is in there, which should hopefully be more efficient for
What can we do to make this happen? Is this the type of thing that's
easier for the maintainer of MirrorManager to add, or should we supply
Here's the current tools people have done, if that helps -
Metalink Editor - in Python, GUI
cURL - they use a short Perl script that makes them based on location.
Simba/RoPkg::Metalink - Perl
Bouncer - there's a patch for it.
Metalink tools - CLI, C++
(( Anthony Bryan
)) Metalink [ http://www.metalinker.org ]
-----BEGIN PGP SIGNED MESSAGE-----
Hi, I'm Nigel Jones, I've been putting off sending this email for a
couple of weeks now (for various reasons), but as everyone is focused
again for the next release, I'd like to join in and help.
At the moment I'm an IT student at Computer Power Institute
(http://www.computerpower.ac.nz), doing a networking diploma.
I'm hoping to be able to help out with the development and testing of
PackageDB which Toshio is leading (I've already talked to him on IRC).
I think I've provided all the important bits.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
After looking at a traceback from Bodhi, I put together a new
python-fedora to hopefully address that. It's available from my home
directory on bastion:
I've only tested this on the pkgdb test machines so if you still have a
test instance, try it out there before loading it onto the main
instances of mirrormanager, Bodhi, etc.
With F8T1 fast approaching (it's currently scheduled to be released on 1
August 2007) we need to get cracking on a new VCS system. I've been
working on converting the CVS repositories to GIT on some spare hardware
that I've had laying around. I think that it's at a stage where input &
testing from the community is needed to move the project forward.
Therefore I'd like to request a test Xen host to move the repository
More information about the repository I've been setting up can be found
by Jasper, Brandon R CTN2 NSSC BANGOR WA,
NSSC Bangor N621
My name is Brandon Jasper and I'm a CTN2(SS) (Crypto Tech Networking,
submarine qualified) in the US Navy. I've been a Red Hat user for a
long time and in fact it was the first Linux distro I used. I saw the
infrastructure team and since I'm not heavy on programming it fits with
what I can do to contribute to the project. I've been a sysadmin on an
SSN (nuclear fast attack submarine) and in a detachment working on
underwater robotics. I'm currently the assistant information assurance
manager for the pacific SSBN (strategic missile submarines) fleet. I've
got a number of cast off servers sitting around my office and though I
can't make any firm commitments I am going to try to drop the paperwork
to get one. If I can get one I'll set it up to help out with the
project, if not I'll still be glad to help where I can.
Last summer we were tracking GSoC changes against the 1.5 trunk of Moin.
Those change never got merged, so did not make the 1.6 release. FWIW,
we're still looking for someone interested in Python, DocBook, and Moin
to help maintain those patches; if we did, we might get them accepted
into the trunk.
A current SoC project is working on providing a Wiki interface for
editing man/info pages. More details are found on Ville-Pekka's project
The question has come up from Ville-Pekka if we want to track our
changes against the current Moin version (1.6) or the upcoming (1.7),
and we need to have a decision within the week.
Any thoughts on this?
From the project page:
"* Finally decide on 1.6 vs. 1.7. This needs to happen this week as of
writing (week 23). No major changes will get to 1.6 anymore, so if I
based my project on it, then Fedora would need to run an unmerged branch
of the code. Probably not what we want? My suggestion is to work on 1.7
branch and hopefully get my changes merged into mainline eventually."
Karsten Wade, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProjectquaid.108.redhat.com | gpg key: AD0E0C41