Does anyone have concern about this? What if Redhat stops giving SRPMS for
new releases and updates in public? If you buy a subscription to RHEL AS and
they have to give you the SRPMS because of GPL agreement can that person
provide those SRPMS to public again because of GPL? They claim they are
premium OpenSource company but they are still a company and for them money
is bottom line. Hopefully this is all legal and we will have SRPMS one way
or the other.
_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen
Technology.
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…
Start enjoying all the benefits of MSN® Premium right now and get the
first two months FREE*.
I had sent my reply to centos-devel, but as there is discussion here -
here it is ...
Lance
---------- Forwarded message ----------
Date: Tue, 14 Dec 2004 12:47:18 +0000 (GMT)
From: Lance Davis <lance(a)uklinux.net>
Reply-To: centos-devel(a)caosity.org
To: John Newbigin <jn(a)it.swin.edu.au>
Cc: centos-devel(a)caosity.org
Subject: [CentOS-devel] Re: [Centos] Issues/thoughts re CentOS-4
(The beta isnt public yet - so I have moved this thread to centos-devel -
where it should probably be anyway ... )
On Tue, 14 Dec 2004, John Newbigin wrote:
> This is a list of issues for discussion for CentOS-4. Most of it is
> based on my experience from building/maintaining CentOS-2 and observing
> CentOS-3. I have not seen the CentOS-4 beta yet so I don't know if any
> of this is already done. If these have been discussed on IRC then
> perhaps someone could produce a shot summary of the outcomes....?
>
>
> * Just call it CentOS-4 not 4.1 etc. Too confusing and serves no real
> purpose
It will be called CentOS-4 but will have 4.0,4.1,4.2 as iso releases.
It means that the version of centos-release rpm will always be 4 , but the
contents will probably say 4 (4.0) or somesuch.
This is necessary to know what version people have installed (or at least
what version they have (attempted to) upgraded to.
> * All modified rpm should use mezzanine or equiv. This makes it easier
> to track changes, build updates and generate a report on what has changed.
That needs someone to sort it out ... and all developers to be up to speed
with the packages ...
> * Modified rpm should have .c4.n added to the release
> - c4 = centos 4. (works well once the 4.1 is dropped)
> - .n = a number starting at 1. The spec only 0 does not scale if you
> need to make another spec only change. The changelog will tell you what
> has changed.
yes it does scale - you make it c0.1 ( or c4.0.1 )
I think it is useful to indicate a spec only change, but am happy to go
with .c4.0 for this purpose if you wish, I still prefer .c0
Also there is no problem having .c0 rpms in different centos versions
because they are only non changed redhat rpms with trademark edits in the
specfile. If the specfile was edited so as to produce different output
then that would have to be a .1
> * Mission: To stay as close to RedHat as possible
> Issues: some things need to be modified to support this. For example
> the cpu/memory restrictions will be removed(like in CentOS-3). Given
> that we are doing this, should we also lift other artificial constraints
> like installing on i386?
The restraint for i586 will be removed, as I am working on doing for U4 ,
however I'm not sure i386 is a good idea ... It is easy enough - just
build the kernel and have it in the install tree.
> If we start making changes, where do we draw the line? In CentOS-2 I
> have fixed some small 1 line bugs (mostly packaging issues) but this
> might be a contentious issue. What about a CentOS+ repo. for enhanced
> versions?
Bug fixes are not contentious IMHO, but they should be pushed upstream.
a CentOS+ repo sounds like a good idea if someone is prepared to do the
work. I think it would have to work along the contrib lines and be
experimental / not supported
> * Issue: should the distro be self hosting? I think as long as the
> requirements are available from the addon/extras repos. then I don't
> think this is needed out of the box. Obviously the build environment
> needs to be well documented and reproducible.
indeed - as long as the components to make it self hosting are there then
they do not need to be installed/installable from anaconda.
> * Mission: Remove RedHat trademarks.
> Issues: should we replace all rh logos/icons or just the ones required
> by RedHat? I think if the file/words can be replaced then yes, but
> package names etc. should be left alone.
all of the rh/logos and icons are removed - to give a 'better user
experience'. There is no need to change the package names that redhat have
chosen to give to the linux community. (In rhel4 redhat-config ->
system-config - and also a lot of work has been done by Fedora removing
the word redhat where it is uneccesary - this has flowed through into
Rhel4 - indeed even in U4 for 3.3 there are occasions where I have had to
remove patches because they had been modified upstream by Fedora project
and incorporated by Redhat) .
> * Issue: yum > Don't ever auto-modify
yum.conf. Too confusing.
It is a shame that yum does not support multiple configuration directories
...
> Invent a system for selecting/allocating a mirror. Users should always
> use a 3rd party mirror and not the main caosity mirrors.
> Issue: every mirror has different paths. We need to clean up all the
> symlinks and multi versions on the mirrors. (We need someone in change
> of the mirrors)
There is no issue here - all of the mirrors use the same paths within the
cAos repo - the mirror is just defined as the url including the path to
the cAos repo - that does not cause any problems that I can see and can be
used in automated scripts.
Someone does need to volunteer to write the script to 'auto-modify
yum.conf' to use a local mirror (ok not 'auto' maybe) - it would be done
on install and manually thereafter - I am guessing a yum-config-centos rpm
or some such containing a bash script that actually produces the first
yum.conf on install (using the geolocate stuff) and thereafter would
only write a .rpmnew unless run manually. How about the yum.conf in the
actual yum rpm ?? what will happen to that ??
It is also a shame that yum cannot use iso image sets - although I wonder
if with a dvd and all packages on a single disc the [base] repo could be
local disc - probably not :(
We have Rick Graves managing the mirror database now - I had been doing it
up until recently.
> * Issue: gpg key.
> This should be installed by default so the user does not have to find &
> import it. At a minimum it should be in /usr/share/doc/centos-release
> and work like a RedHat box.
agreed - I have been discussing this at length with Skvidal and Orc etc,
the most recent proposal is to auto install the gpg key only if it is the
same key that the yum rpm has been signed with - by checking fingerprints,
otherwise to squawk.
In any event to tell the user that the key has bene installed and how to
check whether the key has been compromised/is the right key.
(Skvidal - sorry - not had chance to discuss with you since discussiuon
with Orc)
> > * Issue: release QA
> Before public release, a QA procedure should make sure that there are no
> obvious problems (like the comps issue of 3.3).
agreed
> * Idea: automatic patch building.
> It should be possible to build most patches without intervention. I
> don't know what the current systems in place are but if there were
> autobuilt unsigned patches available it would allow
> - testing of patches before they are 'officially' released
> - checking the progress if a patch
agreed - there is no automatic system at present.
Thanks for your input - great
Regards
Lance
--
uklinux.net -
The ISP of choice for the discerning Linux user.
_______________________________________________
CentOS-devel mailing list
CentOS-devel(a)caosity.org
http://lists.caosity.org/mailman/listinfo/centos-devel
>From: "Nigel Kendrick" <nigel.kendrick(a)petdoctors.co.uk>
>Reply-To: <nigel.kendrick(a)petdoctors.co.uk>
>To: <centos(a)caosity.org.>
>Subject: [Centos] CentOS newbie just saying hello
>Date: Tue, 14 Dec 2004 14:53:44 -0000
>
>Hi folks,
>
>Just a quick hello having installed CentOS on my first box - an Acer
>Altos G310 (P4 2.8GHz, 768MB RAM with 70GB + 300GB storage. The 300GB
>unit is a SATA disk which I hope to software (hardware!?) mirror - if
>I'm in for any major fun mirroring a SATA drive do let me know now - I
>think hardware mirroring is not an option (yet!?) but I haven't checked
>this out completely.
Maybe http://3ware.com/products/serial_ata.asp I don't have SATA hardwares.
How is everyone else using them hopefully without problems? I would like
hardware SATA RAID in future as well. Anyone like 3ware cards for this?
Stable?
>This isn't my first *nix/linux install - I go all the way back to Daisy
>Dnix, Xenix, SC..er..you know who..unix, via VAX VMS and CP/M on various
>systems. I have a couple of RH9 boxes that will need updating soon and
>I'm also running one other Acer G310 server on..er..White Box..(sorry!)
>so this is kind of a 'keeping my options open' thing!
I get impression that Centos development process is better compared to
Whitebox because community working on OS is better than one person.
_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen
Technology
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…
Start enjoying all the benefits of MSN® Premium right now and get the
first two months FREE*.
Updated ruby package is available for CentOS-3 x86_64:
https://rhn.redhat.com/errata/RHSA-2004-635.html
Updated files are:
RPMS/irb-1.6.8-9.EL3.3.x86_64.rpm
RPMS/ruby-1.6.8-9.EL3.3.x86_64.rpm
RPMS/ruby-devel-1.6.8-9.EL3.3.x86_64.rpm
RPMS/ruby-docs-1.6.8-9.EL3.3.x86_64.rpm
RPMS/ruby-libs-1.6.8-9.EL3.3.x86_64.rpm
RPMS/ruby-mode-1.6.8-9.EL3.3.x86_64.rpm
RPMS/ruby-tcltk-1.6.8-9.EL3.3.x86_64.rpm
SRPMS/ruby-1.6.8-9.EL3.3.src.rpm
Execute "yum update ruby" to apply.
Will Dinkel
Chief Systems Engineer
Team HPC, Inc.
785-542-2135 x304
wdinkel(a)teamhpc.com
http://www.teamhpc.com
Hi folks,
Just a quick hello having installed CentOS on my first box - an Acer
Altos G310 (P4 2.8GHz, 768MB RAM with 70GB + 300GB storage. The 300GB
unit is a SATA disk which I hope to software (hardware!?) mirror - if
I'm in for any major fun mirroring a SATA drive do let me know now - I
think hardware mirroring is not an option (yet!?) but I haven't checked
this out completely.
This isn't my first *nix/linux install - I go all the way back to Daisy
Dnix, Xenix, SC..er..you know who..unix, via VAX VMS and CP/M on various
systems. I have a couple of RH9 boxes that will need updating soon and
I'm also running one other Acer G310 server on..er..White Box..(sorry!)
so this is kind of a 'keeping my options open' thing!
This new G310 will be running Bacula to provide remote backup services
for 25 regional sites, and the other G310 is being used as a
mail/Web/Intranet (eGroupWare) server for our 250 staff.
Thanks to all those who made CentOS what it is - hope I can 'give back'
sometime by sharing my experience where relevant.
Nigel Kendrick
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com)
Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004
The following errata for CentOS-2 have been built and uploaded the the
centos mirror:
RHSA-2004:505-01 Updated kernel packages fix security vulnerability
Files available:
kernel-2.4.9-e.57.athlon.rpm
kernel-smp-2.4.9-e.57.athlon.rpm
kernel-BOOT-2.4.9-e.57.i386.rpm
kernel-doc-2.4.9-e.57.i386.rpm
kernel-headers-2.4.9-e.57.i386.rpm
kernel-source-2.4.9-e.57.i386.rpm
kernel-2.4.9-e.57.i686.rpm
kernel-debug-2.4.9-e.57.i686.rpm
kernel-enterprise-2.4.9-e.57.i686.rpm
kernel-smp-2.4.9-e.57.i686.rpm
kernel-summit-2.4.9-e.57.i686.rpm
More details are available from the RedHat web site at
https://rhn.redhat.com/errata/rh21as-errata.html
The easy way to make sure you are up to date with all the latest patches
is to run:
# yum update
--
John Newbigin - Computer Systems Officer
School of Information Technology
Swinburne University of Technology
Melbourne, Australia
http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the
centos mirror:
RHSA-2004:536-01 Updated ncompress package fixes security issue and bug
Files available:
ncompress-4.2.4-37.i386.rpm
More details are available from the RedHat web site at
https://rhn.redhat.com/errata/rh21as-errata.html
The easy way to make sure you are up to date with all the latest patches
is to run:
# yum update
--
John Newbigin - Computer Systems Officer
School of Information Technology
Swinburne University of Technology
Melbourne, Australia
http://www.it.swin.edu.au/staff/jnewbigin
The following errata for CentOS-2 have been built and uploaded the the
centos mirror:
RHSA-2004:635-01 Updated ruby package fixes denial of service issue
Files available:
irb-1.6.4-2.AS21.1.i386.rpm
ruby-1.6.4-2.AS21.1.i386.rpm
ruby-devel-1.6.4-2.AS21.1.i386.rpm
ruby-docs-1.6.4-2.AS21.1.i386.rpm
ruby-libs-1.6.4-2.AS21.1.i386.rpm
ruby-tcltk-1.6.4-2.AS21.1.i386.rpm
More details are available from the RedHat web site at
https://rhn.redhat.com/errata/rh21as-errata.html
The easy way to make sure you are up to date with all the latest patches
is to run:
# yum update
--
John Newbigin - Computer Systems Officer
School of Information Technology
Swinburne University of Technology
Melbourne, Australia
http://www.it.swin.edu.au/staff/jnewbigin
I have built a set of preview U4 beta rpms for CentOS i386 - these will
become the basis of CentOS 3.4 when Rhel 3 U4 is released.
I will not be pushing these out to the mirrors, but they are available at
http://beta.caosity.org/centos/3.3/U4beta
The beta packages are not signed.
To add then to yum.conf add :-
[u4beta]
name=CentOS-$releasever - U4beta
baseurl=http://beta.caosity.org/centos/$releasever/U4beta/$basearch/
gpgcheck=0
Please do not use these on production servers as consequences cannot be
predicted ..
I'll be rolling some beta isos in the next few days
Any problems - bugzilla ...
Regards
Lance
--
uklinux.net -
The ISP of choice for the discerning Linux user.