Hi...
as a project, i'm trying to find the Centos Source code/rpms, in droder to completely build the OS from scratch. I'm going to also want to build the OS in the debug mode.
can someone point me to the codebase, as well as any docs that cover the overall process.... it's been quite awhile since i've done this process...
thanks
as a project, i'm trying to find the Centos Source code/rpms, in droder to completely build the OS from scratch. I'm going to also want to build the OS in the debug mode.
can someone point me to the codebase, as well as any docs that cover the overall process.... it's been quite awhile since i've done this process...
It's been stated a couple times on the list that there's no interest in helping people rebuild the entire distribution from scratch. The build scripts are published on the centos mirrors in http://mirror.centos.org/centos/build/ beyond that, I'd say you're on your own. Too much rebuilding dilutes the gene pool.
On Sat, 19 Aug 2006, Jim Perrin wrote:
It's been stated a couple times on the list that there's no interest in helping people rebuild the entire distribution from scratch.
...
beyond that, I'd say you're on your own. Too much rebuilding dilutes the gene pool.
Jim states it humorously, but a whole swarm of issues with emerge during a rebuild effort: - Will package building be done in an 'as found' build environment, or in a chroot - As non-root, or as root - Will the build of the packages be done in a minimal build chroot, a defined chroot, a fully populated build chroot - Will the build chroot be pristine every time, or are shortcuts tolerated - How will non-explicit BuildReq's to be handled - What arches are targets - What installation methods will be supported - Is it a goal to maintain ABI interop with the upstream PNAEVL, or is drift tolerated - What workarounds will be used to solve reaching a ABI identicality when the upstream has build with a tool (such as a GCC variant) not released - What post-testing processes will be used to measure confirmance - Is it going to solve the trademark issues, or ignore them - Will all package versions match the upstream identically, or will 'creep' of later versions and fixes be accepted - How will updates be handled
We have not even touched on issues surrounding binary and source code distribution, support, documentation, mailing lists, bug trackers, community building, and the like.
Thinking of material alternative efforts similar to CentOS', David Parsley worked and published his solution first, has as to RHAS21; John Morris later with his writeup as to RHEL 3; and many others as well within the context of the 'rebuilds' of RH Enterprise sources derived distributions. Each has made differing choices, and to greater and lesser extents, documented their efforts. David has retired Tao into CentOS recently, as it was so demanding; others as well have flagged in their 'freshness' over time.
A strong aspect of CentOS is the ability to attract and retain committed volunteers, and really become the 'community' solution for the whole range of 'being an Enterprise-grade Distribution' -- it is far more than just compiling packages so that they can be wedged into an installable format.
Here, as with the IRC channel's guidelines, well asked questions may draw a meaningful response from a CentOS 'insider'; general ones will (and I argue, _should_) not.
Solve about the Cost/Benefit equation from the standpoint of a CentOS volunteer: Asking how to make CentOS weaker (as by a random call not showing the slightest bit of advance research and being a distractor from more pressing tasks) is a question thoughtlessly asked. Within the range of proper replies: devnull it and move on. Another couple approaches from the core group also have been offered.
Thanks, CentOS core group. You know who you are.
- Russ Herrold
hi...
thanks for the reply... your comments are reasonable. but you have to understand.. this is for a project... to simply gain additional/further information.. i'm not looking to replace Centos/RH... i was simply looking for docs/instructions on how to build Centos from source in both the regular/debug mode... no more.. no less...
in all honesty, it should be rather simple, as i should be able to essentually use the same cmnds that are used to build the source rpms..
the difficulty/lack of information is coming as i can't find anything that appears to relate to the 'debug-kernel' issue...
thanks
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org]On Behalf Of R P Herrold Sent: Saturday, August 19, 2006 2:08 PM To: CentOS mailing list Subject: [CentOS] build Centos source/rpms from scratch...
On Sat, 19 Aug 2006, Jim Perrin wrote:
It's been stated a couple times on the list that there's no interest in helping people rebuild the entire distribution from scratch.
...
beyond that, I'd say you're on your own. Too much rebuilding dilutes the gene pool.
Jim states it humorously, but a whole swarm of issues with emerge during a rebuild effort: - Will package building be done in an 'as found' build environment, or in a chroot - As non-root, or as root - Will the build of the packages be done in a minimal build chroot, a defined chroot, a fully populated build chroot - Will the build chroot be pristine every time, or are shortcuts tolerated - How will non-explicit BuildReq's to be handled - What arches are targets - What installation methods will be supported - Is it a goal to maintain ABI interop with the upstream PNAEVL, or is drift tolerated - What workarounds will be used to solve reaching a ABI identicality when the upstream has build with a tool (such as a GCC variant) not released - What post-testing processes will be used to measure confirmance - Is it going to solve the trademark issues, or ignore them - Will all package versions match the upstream identically, or will 'creep' of later versions and fixes be accepted - How will updates be handled
We have not even touched on issues surrounding binary and source code distribution, support, documentation, mailing lists, bug trackers, community building, and the like.
Thinking of material alternative efforts similar to CentOS', David Parsley worked and published his solution first, has as to RHAS21; John Morris later with his writeup as to RHEL 3; and many others as well within the context of the 'rebuilds' of RH Enterprise sources derived distributions. Each has made differing choices, and to greater and lesser extents, documented their efforts. David has retired Tao into CentOS recently, as it was so demanding; others as well have flagged in their 'freshness' over time.
A strong aspect of CentOS is the ability to attract and retain committed volunteers, and really become the 'community' solution for the whole range of 'being an Enterprise-grade Distribution' -- it is far more than just compiling packages so that they can be wedged into an installable format.
Here, as with the IRC channel's guidelines, well asked questions may draw a meaningful response from a CentOS 'insider'; general ones will (and I argue, _should_) not.
Solve about the Cost/Benefit equation from the standpoint of a CentOS volunteer: Asking how to make CentOS weaker (as by a random call not showing the slightest bit of advance research and being a distractor from more pressing tasks) is a question thoughtlessly asked. Within the range of proper replies: devnull it and move on. Another couple approaches from the core group also have been offered.
Thanks, CentOS core group. You know who you are.
- Russ Herrold _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 8/19/06, bruce bedouglas@earthlink.net wrote:
hi...
thanks for the reply... your comments are reasonable. but you have to understand.. this is for a project... to simply gain additional/further information.. i'm not looking to replace Centos/RH... i was simply looking for docs/instructions on how to build Centos from source in both the regular/debug mode... no more.. no less...
in all honesty, it should be rather simple, as i should be able to essentually use the same cmnds that are used to build the source rpms..
the difficulty/lack of information is coming as i can't find anything that appears to relate to the 'debug-kernel' issue...
I am guessing this is for some school project...
The debug kernel you mentioned was only upstream in 2.1. The 'code' to create the kernel-debug is in that spec file ONLY. Red Hat changed its way of doing things and put all the debugging information in -debuginfo packages sometime during the Fedora packages (FC3 was stabilized into RHEL-4.. so Centos-4 would be your best bet to creating all the debuginfo pacakges.)
In your 'build' system you will want to make sure that the rpmmacros files do not have %debug_package %{nil}
so that the automatic debug packages are created.
What google will tell you: http://vault.centos.org/debuginfo/ https://www.redhat.com/magazine/012oct05/features/oprofile/
stephen/smooge!
thanks for the reply...
not a school project, a machine is having intermittent crashes, and i want to know more detailed information.. so i need to have a debug kernel in order to keep testing.
the issue with the kernel-debuginfo, is that it appears to essentially be the OS with the debug/symbolic information. you apparently don't actually run the rpm/app after it's installed.. but it gives the 'crash' app the ability to match/resolve symbolic information in the event of a crash/hang within the OS....
you supplied me with info that i had eventually found after hours of searching... i had created debug kernel scenarios years ago, but needed to be sure things hadn't changed...
thanks
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org]On Behalf Of Stephen John Smoogen Sent: Sunday, August 20, 2006 9:47 AM To: CentOS mailing list Subject: Re: [CentOS] build Centos source/rpms from scratch...
On 8/19/06, bruce bedouglas@earthlink.net wrote:
hi...
thanks for the reply... your comments are reasonable. but you have to understand.. this is for a project... to simply gain additional/further information.. i'm not looking to replace Centos/RH... i was simply looking for docs/instructions on how to build Centos from source in both the regular/debug mode... no more.. no less...
in all honesty, it should be rather simple, as i should be able to essentually use the same cmnds that are used to build the source rpms..
the difficulty/lack of information is coming as i can't find anything that appears to relate to the 'debug-kernel' issue...
I am guessing this is for some school project...
The debug kernel you mentioned was only upstream in 2.1. The 'code' to create the kernel-debug is in that spec file ONLY. Red Hat changed its way of doing things and put all the debugging information in -debuginfo packages sometime during the Fedora packages (FC3 was stabilized into RHEL-4.. so Centos-4 would be your best bet to creating all the debuginfo pacakges.)
In your 'build' system you will want to make sure that the rpmmacros files do not have %debug_package %{nil}
so that the automatic debug packages are created.
What google will tell you: http://vault.centos.org/debuginfo/ https://www.redhat.com/magazine/012oct05/features/oprofile/
-- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Please don't top post in mailing list replies. It's not considered "proper" behavior.
not a school project, a machine is having intermittent crashes, and i want to know more detailed information.. so i need to have a debug kernel in order to keep testing.
What are you calling a debug kernel? There seems to be a miscommunication or trouble getting the idea of what you're trying to do across?
the issue with the kernel-debuginfo, is that it appears to essentially be the OS with the debug/symbolic information. you apparently don't actually run the rpm/app after it's installed.. but it gives the 'crash' app the ability to match/resolve symbolic information in the event of a crash/hang within the OS....
How does this differ from your 'debug kernel'?
you supplied me with info that i had eventually found after hours of searching... i had created debug kernel scenarios years ago, but needed to be sure things hadn't changed...
I'm still unclear how this relates to the original post of rebuilding the CentOS distribution, and to some extent I don't overly follow how changing to a kernel of your own creation will help you troubleshoot a crash you think is related to the provided kernel.
jim...
the linux kernel has the ability to be compiled in a 'debug' mode. the resulting 'app' is used by various external apps to be able to trap/resolve dependencies at the kernel level to determine why kernel level (kernel generated) crashes/hangups occur.
if you're building the kernel, i believe the flag '-g' is used in the CFLAGS attribute during the complile/build process for the kernel.
it also appears that the kernel-debuginfo app is essentially the same as i just described. (which would explain the large size of the rpm file. it's the OS with the debugging/symbolic information)
it also appears that you do not need to 'run' the kernel-debuginfo app, rather you can point to it with the 'crash' app and other apps to get the symbols resolved while you're debugging the kernel level errors/isssues...
this is also used with the netdump process.
so what you're doing is either rebuilding the kernel, using the '-g'/debug flag, or you're using the 'kernel-debuginfo' app to handle the symbolic resoultion for the debugging process.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org]On Behalf Of Jim Perrin Sent: Sunday, August 20, 2006 2:24 PM To: CentOS mailing list Subject: Re: [CentOS] build Centos source/rpms from scratch...
Please don't top post in mailing list replies. It's not considered "proper" behavior.
not a school project, a machine is having intermittent crashes, and i want to know more detailed information.. so i need to have a debug kernel in order to keep testing.
What are you calling a debug kernel? There seems to be a miscommunication or trouble getting the idea of what you're trying to do across?
the issue with the kernel-debuginfo, is that it appears to essentially be the OS with the debug/symbolic information. you apparently don't actually run the rpm/app after it's installed.. but it gives the 'crash' app the ability to match/resolve symbolic information in the event of a crash/hang within the OS....
How does this differ from your 'debug kernel'?
you supplied me with info that i had eventually found after hours of searching... i had created debug kernel scenarios years ago, but needed to be sure things hadn't changed...
I'm still unclear how this relates to the original post of rebuilding the CentOS distribution, and to some extent I don't overly follow how changing to a kernel of your own creation will help you troubleshoot a crash you think is related to the provided kernel.
-- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Please don't top post in mailing list replies. It's not considered "proper" behavior.
it also appears that the kernel-debuginfo app is essentially the same as i just described. (which would explain the large size of the rpm file. it's the OS with the debugging/symbolic information)
kernel-debuginfo is not an application that stands by itself. It is supplemental to the kernel rpm of the corresponding version, and as Stephen explained earlier, is the default way of doing things from RHEL/Centos 3 onward.
it also appears that you do not need to 'run' the kernel-debuginfo app, rather you can point to it with the 'crash' app and other apps to get the symbols resolved while you're debugging the kernel level errors/isssues...
Correct, which is why I'm unclear on your need/desire to rebuild things.
so what you're doing is either rebuilding the kernel, using the '-g'/debug flag, or you're using the 'kernel-debuginfo' app to handle the symbolic resoultion for the debugging process.
There is no kernel-debuginfo application. It's simply putting back the debugging information which. It's a supplement to the package, not a replacement, and not something that stands on its own.
I'm also still unclear on what your issue is (since you stated you're having crashes but never clarified) or why you want to rebuild everything as a means to troubleshoot that crash. Why not simply use the packages available from centos (and thus from the centos perspective reliable, and reproducible) to figure out what's going on. Or elaborate on the issue here, as if it's a problem it's quite likely someone has encountered it before and will be able to offer advice. I don't see how rebuilding anything helps you just yet.
Stephen John Smoogen wrote:
In your 'build' system you will want to make sure that the rpmmacros files do not have %debug_package %{nil}
using %debug_package %{nil} means that debug info is left in the binaries and not stripped out ( so you end up with large binary .rpm's ) perhaps that is exactly what the OP wanted ?
On 8/20/06, Karanbir Singh mail-lists@karan.org wrote:
Stephen John Smoogen wrote:
In your 'build' system you will want to make sure that the rpmmacros files do not have %debug_package %{nil}
using %debug_package %{nil} means that debug info is left in the binaries and not stripped out ( so you end up with large binary .rpm's ) perhaps that is exactly what the OP wanted ?
Possibly. I misread what debug_package does.. I thought it threw away the debug info.. sigh.
Stephen John Smoogen wrote:
On 8/20/06, Karanbir Singh mail-lists@karan.org wrote:
using %debug_package %{nil} means that debug info is left in the binaries and not stripped out ( so you end up with large binary .rpm's ) perhaps that is exactly what the OP wanted ?
Possibly. I misread what debug_package does.. I thought it threw away the debug info.. sigh.
Well, it does :)
It throws it away to another package ...
scnr, really.
Ralph
bruce wrote:
as a project, i'm trying to find the Centos Source code/rpms, in droder to completely build the OS from scratch. I'm going to also want to build the OS in the debug mode.
I am interested... what exactly is the debug mode ?
- K
-
bruce -
Jim Perrin -
Karanbir Singh -
R P Herrold -
Ralph Angenendt -
Stephen John Smoogen