Status of Third Party Repositories for FC4
From FedoraNEWS.ORG
Written by Thomas Chung on 2005-06-22
| Table of contents |
[edit]
Status of ATrpms Repository
We asked Axel Thimm, the maintainer of a Third Party Repository - ATrpms (http://atrpms.net/), a short description of his repository and current status of YUM repository for FC4.
The ATrpms repo currently supports RH7.3-9, FC1-FC4 and RHEL3-4 for
i386 and x86_64 (ppc support may be added later, it is yet undecided
and will depend on user demand). FC4 is currently being rebuilt
against FC4 final, so it is not available online. Some of the older
distros may be dropped within this year.
The repo supports repomd, yum20 and apt metadata. It is currently
being moved to
http://dl.atrpms.net/fc4-i386/atrpms/{stable,testing,bleeding}
This new location is not yet public, as we are experimenting with
various scripts to recerate metadata and to join repos. The same
location will contain fc, updates, extras, freshrpms, dag etc. There
will also be a giant "medley" repo containing everything under the sun
and more.
Source: Email
[edit]
Status of Planet CCRMA Repository
We asked Fernando Lopez-Lezcano , the maintainer of a Third Party Repository - Planet CCRMA (http://ccrma.stanford.edu/planetccrma/software/), a short description of his repository and current status of YUM repository for FC4.
Planet CCRMA (CCRMA is pronounced ``karma'') at Home is an apt/yum repository that you can use to add packages to a computer running supported versions of RedHat or Fedora Core and transform it into an audio workstation with a low-latency kernel, current ALSA audio drivers and a nice set of music, midi, audio and video applications. Planet CCRMA is made up of two separate repositories, "planetcore" holds the low latency kernel, updated alsa drivers and associated packages, you will need this to be able to run the Jack server with good latency results and with realtime scheduling and memory locking as a non-root user. The rest of the packages (applications and libraries) are in the "planetccrma" repository. Planet CCRMA replicates most of the Linux environment we have been using for years here at CCRMA for our daily work in audio and computer music production and research. Planet CCRMA can be installed and upgraded over the network from the Planet CCRMA apt/yum repository or its mirrors, or from cdroms you can download. Planet CCRMA is in the middle of a complete rebuild on Fedora Core 4. There is already an experimental kernel with Ingo Molnar's patches and many applications are already built. Regretfully some are not yet patched to build with gcc4 so the recommended version for now is still Fedora Core 3. It will take a while for the Fedora Core 4 version to catch up...
Source: Email
[edit]
Status of NewRPMS Repository
Rudolf Kastl, the maintainer of a Third Party Repository - NewRPMS (http://newrpms.sunsite.dk/), was not available to answer our request but we were able to find some information on a mailing list.
Gerald B. Cox asks:
Date: 2005-06-16 Have a few questions. I've been using FRESHRPMS for many years and understand the repositories are merging into RPMFORGE. I haven't seen any reference on the FRESHRPMS home page for FC4. Has the merge already occurred? If not, what is the proper way to use? It appeared that for FC3, FRESHRPMS had its packages in the same way it has in the past, but DAG had it's packages, plus the FRESHRPMS packages, but the FRESHRPMS packages were named differently. When I would use DAG and FRESHRPMS using a YUM UPDATE, YUM would want to replace my FRESHRPMS packages with the DAG named version. So I would end up "deactivating" the DAG repo except when I wanted to download a specific package. Is this the way it is suppose to work? Until the repos are merged should the overlap be eliminated? I'm not griping, I think the repos are a great resource and am thankful they exist. Just trying to figure out the easiest/best way to use. Thanks!
Rudolf Kastl answers:
Date: 2005-06-16 well actually dag (DAG) is building matts stuff (FreshRPMS) too so its all in one repository. he's building some of my newrpms.sunsite.dk stuff (NewRPMS) too i will most probably need 2 days and a week until i can up newrpms for fc4. sorry to all for the delay but actually i am just plain to busy at the moment with other things. gonna try to complete it as soon as possible for fc4 x86_64 and i386 to get more info about the current status id recommend to use the freshrpms mailinglist or #rrpmforge on freenode. Hope that helped, Rudolf Kastl
Source: http://lists.freshrpms.net/pipermail/freshrpms-list/2005-June/013184.html
[edit]
Status of FreshRPMS Repository
Matthias Saou, the maintainer of a Third Party Repository - FreshRPMS (http://freshrpms.net/), was not available to answer our request at this time.
See Status of NewRPMS Repository for more information.
[edit]
Status of DAG Repository
Dag Wieers, the maintainer of a Third Party Repository - DAG (http://dag.wieers.com/home-made/apt/), was not available to answer our request but we were able to find some information on a mailing list.
Date: 2005-06-11 Hi, Dries and I have been populating our FC4 repositories, we hope to have most of the packages available by monday. (certainly with Dries his shining new x86_64 system) Like with previous releases I recommend the faint of heart to delay upgrading for at least 1 week. Since I'm still in the US and have limited time to respond to mails/problems it might even be better to wait 2 weeks. Regarding Fedora Extras compatibility, FE has been duplication some of the packages RPMforge provided and with every duplicated package the probability of incompatibilities grows, this will take a few weeks to settle and fix. If you plan to help out in this area, send us your feedback to: users at lists.rpmforge.net In the meantime it may be wise not to use Fedora Extras in combination with RPMforge unless you know what you're doing and can fix things yourself. BTW dag.wieers.com will be unavailable for possibly 6 hours. As result of the HEAnet resync of april we're moving the server away to prevent having additional expenses in the future. apt.sw.be is not affected. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
Source: http://lists.rpmforge.net/pipermail/users/2005-June/000032.html
Date: 2005-06-13 > Dries and I have been populating our FC4 repositories, we hope to have > most of the packages available by monday. (certainly with Dries his > shining new x86_64 system) As if the discussion on the CentOS mailinglist about failing harddisks was a signal, my main disk on my buildsystem died on me last night. Dries tried recovering it this morning but to no avail. This means the backup plan is that Dries will be the primary source for all FC4 RPMforge packages (both x86_64 and i386). It makes sense to start merging Dries and my repository now and think about the future. I will have to reinstall all my build environments and will take the opportunity to revise and document the process. If there are people that depend on eg. RH6, EL2, RH7, RH8, RH9, FC1, FC2 or another distribution, step forward now if you like to be closer involved or like to maintain an older distribution. If nobody steps up I will probably drop RH9 and FC1 support. New packages or updates in my repository are suspended until I have reinstalled my build environments and revised the tools. Don't expect this to be before July. I'll try though. Dries and FreshRPMS will still cover the important packages and are completely compatible. Sorry for any inconveniences. > BTW dag.wieers.com will be unavailable for possibly 6 hours. As result of > the HEAnet resync of april we're moving the server away to prevent having > additional expenses in the future. apt.sw.be is not affected. These 6 hours is actually on monday during European business hours :) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
Source: http://lists.rpmforge.net/pipermail/users/2005-June/000034.html
Date: 2005-06-25 > Is the a rpm such as "freshrpms-release" for "rpmforge" for FC4? If not, does > anyone have a template on what to use? freshrpms was nice in that it referred > to a mirrors rather than one specific server. We first have to merge all the RPMforge repositories and divide the work. Pasi will be doing some platforms (RHEL/ppc/s390/ia64/...), Dries will do some platforms (Fedora/i386/x86_64/alpha/sparc/...) and I will do whatever is left and makes sense (RHEL/Fedora/RH/i386/x86_64). Other people are welcome to join and support the things they require (like RH8, RH9, FC1) or whatever they want to help out with. We also would appreciate if people are willing to build in parallel, maintain packages or fix problems. (which do not necessarily require subversion commit access) But I do agree we need such a package once we have the directory layout and our first mirrors. > In a previous note Dag mentioned the tracking of changes with Fedora Extras and > others depending on people volunteering to help out. I'm not a RPM whiz by any > means but would be glad to assist if possible. > > It would be nice to make this as automagic as possible. Yes, this is key. I don't want to spend resources (volunteer's time) for manual processes. Programmers are very welcome. Small scripts can help doing most of the work and can be merged/improved as we learn more of what is required. Most of the QA can be automated by simple stand-alone checks that are sequentially performed. Much like unit-testing. For those interested to help out: http://svn.rpmforge.net/svn/trunk/ http://lists.rpmforge.net/ svn-commits at lists.rpmforge.net packagers at lists.rpmforge.net users at lists.rpmforge.net People that depend on some package/software for their company, let me know. I would prefer someone who uses it to maintain the package. People that want to help out with the infrastructure and website, please contact Dries or me. We definitely need some sort of wiki so centralize documentation and link to other project documentation. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
Source: http://lists.rpmforge.net/pipermail/users/2005-June/000038.html
[edit]
Status of Dries Repository
Dries Verachtert, the maintainer of a Third Party Repository - Dries (http://dries.studentenweb.org/apt/), was not available to answer our request at this time.
See Status of DAG Repository for more information.
[edit]
Status of Livna Repository
Damien Nadé, the maintainer of a Third Party Repository - Livna (http://rpm.livna.org/), was not available to answer our request at this time.
See Is Livna Repository Ready for FC4? for more information.
