December 2010 - devel - lists.centos.org

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

Interested in IA64 build.
by James A. Peltier 22 Jan '13

22 Jan '13

I noticed on the SIG that people interested in other ports of interest. I'd like to express interest in the IA64 port. What is the best way to get started? I have two SGI Itanium 2 based machines. One 64 processor x 64GB SGI Altix and a 32 processor x 32GB RAM SGI Prism. They are currently running CentOS 4.8 and I would love to be able to run CentOS 5.5 on them to get them into compliance with the rest of the cluster. -- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier(a)sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca MSN : subatomic_spam(a)hotmail.com Does your OS has a man 8 lart? http://www.xinu.nl/unix/humour/asr-manpages/lart.html

9 53

are there any chances to see finished CentOS6 in 2011?
by Michał Piotrowski 10 Jan '11

10 Jan '11

Hi, I checked the website http://wiki.centos.org/QaWiki/6/AuditStatus so far only one package was centosified. So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?) -- Best regards, Michal Sent from my fscking awesome Black Hole Generator

36 94

tracking packages in a Release, through the life of the release
by Karanbir Singh 06 Jan '11

06 Jan '11

hi, one thing that I'd like to do with 5.6 and 6.0 is to have centos-release carry repo info for the debuginfo and the vault repo's for the same Release. For 6.0 it would be fairly slim to start with but for 5.6 it could look like this : Enabled by default: [base] [updates] Available, but not enabled: [5.5] [5.5-updates] [5.4] [5.4-updates] .. [5.0] [5.0-updates] Allowing people to get specific packages from anywhere in the Release's past. the baseurl for these will point at vault.centos.org/ Similarly would be the debuginfo .repo's. For /5/ we have a single debuginfo repo, for /6/ we can, and i think we should, split these up into repo's that match the release's. so 6.0's debugs end up in debuginfo.c.o/6.0/ and 6.1 goto d.c.o/6.1/ etc. Just as with the older release's .repo files - these would be present but disabled. Also, I'm trying to plumb in debuginfo signing. But it might end up being a different key to the main distro signing key[1], cross signed by the distro key and master keys. lets see how that pans out. thoughts ? - KB

2 2

CentOS-6 repositories: *-devel, *-debuginfo, contrib-{unstable, testing, stable}
by Brian Schueler 05 Jan '11

05 Jan '11

Hi, As I have seen there is only a subset of development libraries included on the upstream's el6 DVD. While packaging my additional software with mock I needed to put some distro SRPMs into my local SRPMs directory to get the *-devel pkgs. (But it would make no sense when the distro packages are updated.) Will be there all *-devel packages included in the CentOS-6 [base]/[update] repositories and will be there a *-debuginfo repo, too? What about contributer repositories? My idea is to have 3 stages of user contrib repositories (two of them controlled by the CentOS dev team): [contrib-unstable] where everyone may upload software packages via web (requiring only a simple registration), that are not well tested and not targeted to a production system. [contrib-testing] packages that have been selected by the developer team that needs to be tested. [contib] packages that are fully tested and confirmed to be stable and which does not have any side-effects to the CentOS base installation. All these points would make C6 fantastic for everyone (for engineers, developers, administrators, end-users and even artists). Cheers, Brian.

3 2

rhel-6 rebuild summary
by Farkas Levente 04 Jan '11

04 Jan '11

hi, i write this mail after more people ask me in private. and since the centos core devel team not share any info about it's build system, status, there modifications, doesn't have any public revision system and not really accept any help or advice for outside. but i still believe these are useful info for many others so i try to summarize our rhel-6 rebuild experience. first question is the build host and base repo selection. it's advice to choose both the build system and the base repo as close as to rhel-6 as possible. unfortunately even with official rhel-6 isos you can't get the optional packages in binary. so imho the best base system and base repo is a union of rhel-6 rc2 and rhel-6 beta. both are available freely in binary but only the beta include the optional packages in binary from. after you finish you can rebuild packages on itself again. another important note that most update packages (there're a few dozens) have higher buildreq packages then in the base repo, but these buildreqs are not versioned in the specs. so you've to add the updates pacakges to the build system's base packages otherwise you'll get build errors. i recommend mock-1.1.7 for building. unfortunately at rh it's not required to be able to build src.rpm is mock, they use only rpmbuild (!) which of course cause a few dozen of packages won't build:-( imho it'd be useful something like this for rhel too: http://fedoraproject.org/wiki/FTBFS so let we see what's are the problematic packages (fortunately most of the packages build clean). all of these packages bellow has a bugzilla entry and most of them already contains the solutions. so just go and search for it (i'd not like to link all bz entry:-() - virt-top (missing ocaml-camomile-data) - spice-client (missing pixman-devel) these two packages can't be rebuild on rhel-6 since they has such buildreq which is not shipped in rhel-6 (simple rh forget about it:-) so you can either add to the base repo these packages from epel or from a rebuild from fedora or simple drop them. - bash - zsh can't be rebuild in mock-1.x since a mock tty bug. in this case imho the easiest solution: mock <params> --rebuild bash... ctrl-c during build, then mock <params> --shell rpmbuild --rebuild /builddir/build/originals/bash... - nss can't be rebuild in mock since during %check try to connect to the localhost to test ssl, but it's not working in mock. i suggest the above solution plus ctrl-c during the rpmbuild when the build hang at the ssl connection test and after the you'll got a successful build:-) - kernel unfortunately kernel spec is not updated to the new noarch subpackage style. which means you've to build the arch and noarch packages separately (as in rhel-5). but the new spec file even worst then the rhel-5 was so eg: a simple: mock <params> --target "noarch,i686" --rebuild kernel... no longer works, but mock <params> --target "noarch" --rebuild kernel... mock <params> --target "i686" --rebuild kernel... works:-) imho the best would be to update the kernel spec to the new noarch style subpackage, but afais rh so conservative about kernel spec it won't be happened in the rhel-6.x series:-( - opal has a wrong rh patch which cause ekiga not compile, so you've to fix opal first. - java-1.6.0-openjdk-1.6.0.0-1.21.b17.el6 can't be build, unfortunately bz with fixes for this package are not public, but there's an update which can be build (may be we'd have to leave this package out). and the remaining packages has different problems in the spec file, but all has (mostly a simple) solution in bz, but doesn't have update package: - guile - openmpi - foomatic - hivex - mod_auth_kerb - gnome-doc-utils - pilot-link - linuxdoc-tools - perl-Sys-Virt - perl-Test-MockObject - perl-Test-Memory-Cycle - perl-GSSAPI - perl-Makefile-Parser - perl-CGI-Session - perl-IPC-Run3 - python-lxml - python-sqlalchemy - rome - epydoc - kdepim-runtime i hope it can help for a few poeple. anyway happy xmas! -- Levente "Si vis pacem para bellum!"

7 14

Re: [CentOS-devel] Collecting data
by derleader __ 26 Dec '10

26 Dec '10

>I have a hard time trying to figure out why you would want to write a kernel module for all >of this. There are userland tools that can do just about everything you describe. I know that there are many tools. This C program is developed with special task. Can you help me? Regards Peter

3 2

Collecting data
by derleader __ 24 Dec '10

24 Dec '10

Hi, I'm developing C plugin for Centos which will be installed as kernel module. The problem is how to collect the data about: CPU Check – Utilization, Model, Number of Cores RAM Check – Total Memory, Free Memory, Memory Load HDD Check – Number of physical HDDs, Number of logical partitions, Total space, Free space Running processes – Total number of processes Logs – system logs such as error logs System uptime Users logged in and last login – total list of users Total network connections Check hardware parts model and number The kernel module will check the status of the OS every 5 minutes. What is the most efficient way to collect these data? Regards Peter

3 2

fyi, first el6 live .iso's available based on SL6alpha
by Douglas McClendon 18 Dec '10

18 Dec '10

FYI, today both I[1] and Urs Beyerle[2] announced some early releases of x86 Live .iso images based on the SL6 rolling alpha. Urs's is I think their equivalent of what Patrice will be releasing. Mine is an independent platform, primarily highlighting the rebootless installation method. And later, after I've submitted a spec here for your contrib repository, I hope my 'VirOS' toolset will prove to be a useful alternative in at least some use-cases to Fedora's livecd-tools. I'll aim not to spam this list again. If you are interested- http://cloudsession.com/dawg/downloads/xzyx http://cloudsession.com/dawg/projects/viros http://viros.sourceforge.net viros-devel(a)lists.sourceforge.net Happy Holidays, Cheers, -dmc Douglas McClendon [1] http://listserv.fnal.gov/scripts/wa.exe?A2=ind1012&L=scientific-linux-devel… [2] http://listserv.fnal.gov/scripts/wa.exe?A2=ind1012&L=scientific-linux-devel…

1 0

Re: [CentOS-devel] CentOS and rhn tools
by Marcus Moeller 17 Dec '10

17 Dec '10

Dear Baptiste. > I used cobbler to manage my CentOS 5.x repos and kickstarts, but Spacewalk > is now a more mature project and so I start to use it, but as you know it > works with rhn-* tools. > > Do rhn tools becomes available in future versions of CentOS (CentOS 5.6, > CentOS 6...) ? If you Kickstart your systems through Spacewalk (that's what it's meant for) you can associate a Channel containing the Tools to the Kickstart Profile. The packages in there will be available during installation phase (before system registration) as well. So there is not need for having them in CentOS. Kind Regards Marcus

2 1

CentOS and rhn tools
by Baptiste AGASSE 17 Dec '10

17 Dec '10

Hi all, I used cobbler to manage my CentOS 5.x repos and kickstarts, but Spacewalk is now a more mature project and so I start to use it, but as you know it works with rhn-* tools. Do rhn tools becomes available in future versions of CentOS (CentOS 5.6, CentOS 6...) ? Regards. Baptiste.

1 0

Why does CentOS 5 claim to be i386 compatible when it's really not?
by Martin Jungowski 15 Dec '10

15 Dec '10

Hi everybody, I've tried to install CentOS 5.5 i386 on an AMD Geode LX 800 processor. That processor, being of the much more recent i586 family, is fully i386- compatible. However, my attempt was brutally shattered when I had to discover that CentOS takes a rather open and surprising attempt at defining x86 compatibility: while claiming to be i386-compatible CentOS 5 requires an i686 processor and does not support the fully i386 but not the least i686 compatible i586 architecture. This is more of a general issue. i386 does not generally refer to "whatever x86-compatible processor is the most recent" but a very well defined and standardized architecture. Specifically, i386 refers to Intels 80386 processor and its 32-bit x86 architecture (which is why x86 are i386 are often used interchangeably when x86 should instead be referring to the 8086 architecture). Code that claims to be i386 compatible has to run on any given microprocessor that claims to be i386 compatible. It's as simple as that: if it doesn't run on i386 processors then it's not i386 compatible. That's industry standard and thus universally valid. If one would claim i386 compatibility but require a x86_64 compatible processor, which of course would be capable of executing standard i386 code, it'd be the exact same issue. It'd be more radical but at its core not different from CentOS's unmet claim of i386 copmpatibility. I guess my question is thus quite simple: why does CentOS 5 claim to be i386 when it's not even remotely i386 compatible? And shouldn't the name reflect code and/or processor family compatibility and affiliation? And in a closely related question of more personal interest: what exactly is it that makes CentOS require an i686 processor? Thanks, Martin -- Rieke Computersysteme GmbH Hellerholz 5 D-82061 Neuried Email: martin[at]rhm[dot]de

9 13

please submit all work-in-progress status's
by Karanbir Singh 10 Dec '10

10 Dec '10

hi guys aiming to wrap the first tree build today, so if you have any work in progress, please get it into the issue tracker before midnight UTC Thur 9th Dec. This isnt the end of all efforts, its just a milestone, so if you are doing stuff please keep on doing the 'stuff'. - KB

6 8

MacBook Air 3.1
by Marcus Moeller 10 Dec '10

10 Dec '10

http://dentifrice.poivron.org/laptops/macbookair3,1/ -- Greets Marcus

1 1

build errors with some RHEL6 packages
by Sergio Rubio 10 Dec '10

10 Dec '10

Good morning everyone, I'm having some problems rebuilding some RHEL6 packages from: http://ftp.redhat.com/pub/redhat/linux/enterprise/6/en/source/SRPMS/ in particular, mock building python-2.6.5 results in: Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/python-2.6.5-3.el6.x86_64 error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug-gdb.py /usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug-gdb.pyc /usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug-gdb.pyo RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug-gdb.py /usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug-gdb.pyc /usr/lib/debug/usr/lib64/libpython2.6.so.1.0.debug-gdb.pyo Child returncode was: 1 My build-env is a RedHat Workstation 6, beta2 release, mock 1.1.5-1. I'm looking for suggestions here, as this is my first foray into building recently released upstream RHEL packages: 1. Looks like a bug in the source RPM, but I might be wrong. If so, is it Ok to report it to bugzilla.redhat.com? 2. Something weird in my env being it beta2? My mock profile config attached. Thanks.

12 23

CentOS 5 or 6
by Filip Bartmann 09 Dec '10

09 Dec '10

I need to start my server in Janurary 2011, so I need to know when it's planned to release CentOS 6 to make decisiion if I use current CentOS 5 or CentOS 6 on this server. Plan you release CentOS 6 to January 2011? Thank's for your response Filip Bartmann

4 3

Rebranding Help
by James Stull 09 Dec '10

09 Dec '10

Greetings, a couple weeks ago I sent an email to Ralph and he pointed me to the dev list. Long story short, I would like to help with the Centos 6 release any way I can and was told that you are currently working on rebranding. And that this is the process I needed to follow: http://wiki.centos.org/QaWiki/6/Round1 I've been reading through the wiki on how to get started but honestly I don't know where to start and I'm asking for some direction. Is their a dev repo where I can download the current version of "Centos 6" or do I simply download RHEL 6 and look through the bug list and try to find more packages/man pages/etc that need to be rebranded?? Some direction would be great. If I can help out in any way please let me know. If their are any documents/processes I need to review please let me know. I don't have any programming experience but I can do some minor scripting. I'm familiar with Red Hat/Fedora/Centos and currently Admin a handful of boxes. Thanks for the help and direction. --James

2 4

pastebin.centos.org broken
by Phil Schaffner 08 Dec '10

08 Dec '10

http://pastebin.centos.org/ is saying "Unable to connect to database" today. Phil

2 1

CentOS - rawhide
by Filip Bartmann 07 Dec '10

07 Dec '10

Why there is no CentOS rawhide repo such in Fedora? Thanks, Filip Bartmann

5 7

[Florian.LaRoche@gmx.net: Re: Reality V/s Fantasy]
by Florian La Roche 07 Dec '10

07 Dec '10

Seems this email didn't go through to the mailinglist, so I'll resend it now. regards, Florian La Roche ----- Forwarded message from Florian La Roche <Florian.LaRoche(a)gmx.net> ----- From: Florian La Roche <Florian.LaRoche(a)gmx.net> To: "The CentOS developers mailing list." <centos-devel(a)centos.org> Date: Thu, 2 Dec 2010 10:31:55 +0100 Subject: Re: [CentOS-devel] Reality V/s Fantasy Hello KB, > One of the main things that the QA team needs to work with is > whitelisting for release, the branding stuff. That intself means the qa > team needs to stay small, non public access to early code builds. Also Red Hat distributes the source without restrictions and e.g. kernel.org is mirroring it out on all its mirror systems, so there is no requirement to keep the CentOS source hidden due to branding/whitelisting issues AFAIK. I agree that binaries should maybe be kept until the branding and major patching items are resolved, but clearly all this is a chicken-egg situation on how to grow the participation for CentOS, right? regards, Florian La Roche ----- End forwarded message -----

1 0

11IEA-AIE-SS-ROS
by Savaş TAKAN 03 Dec '10

03 Dec '10

Dear potential author, we are organising a special session on robot operating systems: http://dive.iyte.edu.tr/11IEA-AIE-SS-ROS/RobotOS.html Please consider submitting a paper. Sincerely, Bora -- Savaş TAKAN

1 0

Reality V/s Fantasy
by Karanbir Singh 03 Dec '10

03 Dec '10

Hi Florian, On 11/26/2010 10:41 AM, Florian La Roche wrote: > you should make sure to grow the CentOS development to a > bigger group and make it more stable. AKAIK this is the > goal of this list and there should be plenty of work to > distribute and get done. I am not sure where that came from - there is some level of fantasy that some of you guys seem to live with. Lets take for example the request for help with branding and trademark searches in the el6 source base. Then look at the people who really did anything to help, take the usual suspects out of the loop, and then see what the number reduces to.. Consider this : the distro was ready to QA in 72 hrs from when upstream dropped all srpms into the right places. I actually requested the 'usual suspects'[1] to not get involved with the branding issues, we all have quite a bit going on and adding onto that at release time usually means slowing down or dropping other efforts; the intention was to not do that, and to bring in a larger user base who can help cover issues that don't need specific centos resources. Also, the QA effort tends to be exceptionally manic, with things changing on an hourly basis, and some of us pushing for testing, results quite aggressively. Besides that, new release, new buildsys, new repo structure and new process meant that this would be fantastic time for a larger number of people to get involved, and stay involved. Starting from the root of what we do, and having a good understanding of context around it, why its a big deal and appreciate it in specific terms by working on it. The original email asking for help on this was posted on the 12th Nov. Its the 26th now. Check https://bugs.centos.org/ to see what level of participation has been forthcoming. Lots of people will argue that open source works in a way where people do what they want to do, so you cant tell them what needs doing - and they will do what they want, when they want. Its what many imagine is the 'fun' in the open source way. Fortunately, or unfortunately we dont have that luxury. What comes down the pipe needs to be addressed, sometimes its what we want to do - and sometimes its what needs doing because that's the issue on hand. The process we have in place is mostly finite, with a specified origin and a specified delivery expectation. We need to join those dots. And if people don't want to help with that joining-the-dots effort, they are never going to be a part of the process. So when people imply that there are lots of potential-contributers who would want to get involved and help etc : What fantasy world are they looking at ? I, or one, would like to get in on that action please. > No fights please, CentOS has such a wonderful source > base to extend upon... If we cant get traction to get on with just doing what our primary aim is, extending the code base looks to be a bit of another fantasy world. Slightly frustrating ? Absolutely. - KB [1]: The usual suspects being the people already doing quite a bit, the core/dev team, the qa guys, artwork effort. And I am truly grateful for their support.

12 21

Fasttrack for C-5
by Alan Bartlett 03 Dec '10

03 Dec '10

Karanbir, Is there an ETA for this repository yet? A status update would be appreciated, please. Regards, Alan.

10 33

handling ABRT
by Karanbir Singh 03 Dec '10

03 Dec '10

hi, EL6 now includes abrt ( https://fedorahosted.org/abrt/ ), which is setup to talk with bugzilla.r.c and comes with a plugin that allows details passed to rhsupport. We dont really want either of those two things to happen. So we can either : - Remove abrt completely ( might not be the best overall solution, but it would surely be the fastest short term target ) - Leave abrt in the distro, but disable chatter abilities with anything *.r.c; and *.fedoraproject.org ( that leaves functionality partially intact, but local implementations would need to adopt and go with whatever they want / need; this solution might not be as nice as the last option) - Last option: get a plugin together that can do what's needed to file at bugs.c.o ( we might need a few more people to get involved with triage and handling of issues via that route! ) Who wants to take on the task of handling abrt, getting the work done and driving this issue into CentOS-6 ? Being able to code in python might not be optional.. - KB

14 39

build errors with RHEL6 packages
by Hubert Bahr 03 Dec '10

03 Dec '10

On 11/13/2010 02:17 PM, Karanbir Singh wrote: > On 11/13/2010 08:25 AM, Farkas Levente wrote: >>/ - what os, version do you use on build hosts? /> > CentOS-5.5 >>/ - which version of mock and ccache do you use? / > no ccache, mock-0.6.3 >/ - and what mock config do you use? / > nothing interesting in the mock configs. If there is nothing interesting in the mock configs why not share them. The config really defines the build environment not the host and not necessarily the version of mock. It is the default installs + the packages to meet dependancies and where they come from. >>/ since it's well known that there are some packages (like bash, nss) / ? because you have those problems, does not mean everyone else will. >>/ which can not be build in mock on rhel-6: />>/ https://bugzilla.redhat.com/show_bug.cgi?id=613392 />>/ https://bugzilla.redhat.com/show_bug.cgi?id=609201 />>/ so it's rather strange that build complete without issues. / > Speak to the people who have the problems ? These packages have all > clearly built not only for fedora, but also for red hat - and going by > the changelogs, quite a few times. > - KB Since I have built all but 36 packages on both 1686 and x86_64 with rpmbuild I am very interested in resolving the differences in build environments. Once I too have a stable build environment I would be interested in working on the rebranding etc. But I would like to be able to test and make sure my changes are not causing the problems not the Build environment. I am building on RHEL6 + updates. Hubert

3 5

Considering repo re-structuring
by Karanbir Singh 02 Dec '10

02 Dec '10

Hi Guys, Some micro-conversations have taken place around this issue on various venues and its worth bringing all that together into one place. With EL6, the rpmlist has grown quite a bit, also there are components that Red Hat ship out in their 'optional' repo. Which are not available on the main isos. Or so I've been told - if you can verify that, please do. The other thing to keep in mind is that we have always merged in all packages from various variants that upstream ship - making all packages available to everyone was always the aim. So traditionally, CentOS has maintained the distro repositories in 2 url's: [os] [updates] with [os] reflecting whats on the isos/; as close to exactly as possible. With CentOS-6, we might need to reconsider that - there is way too much content to fit onto a single DVD. And having the main distro on multiple DVD's might be an option, but is that the best option ? to expand on that option, we could merge in all packages, built a DVD iso set ( 2 or 3 disks, whatever is needed ), stick with the [os] and [updates] repo's on mirror.c.o - and then potentially consider doing some 'slimmer' options. eg: CentOS-6-Minimal, or CentOS-6-SMB-Server etc. The other option is to split the repos into [os] [updates] [optional] {1} [optional-updates] {2} {1} or use a better / different name {2} do we even need the second -updates, we could go with what the present policy w.r.t centosplus/extras is - and drop updates into the same repo Then stick with what we have done in the past, use the isos to reflect whats in [os], create the ability for people to use the [optional] repo at install time and go with that. The iso content would be dictated by the merged iso contents from upstream, so we retain the CentOS <= 5 process in that regard. Continuing on the same idea, one thing that came up was reporpose the Extras/ repo and use that to host these 'additional/optional' packages. Given that it changes a massive user expectation - unless there is very good reasoning to do this, lets try and avoid this. - KB

19 58

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel December 2010