hi guys,
EL5 got a bunch of updates that really need to make it out asap, and while 4.9 settles down - the thinking is to get them released into the 5.5/updates repo. I'll have an exact list of what all is going to make it in the day tomorrow, along with the packages.
- KB
On Wed, Mar 02, 2011 at 10:28:18PM +0000, Karanbir Singh wrote:
EL5 got a bunch of updates that really need to make it out asap, and while 4.9 settles down - the thinking is to get them released into the 5.5/updates repo. I'll have an exact list of what all is going to make it in the day tomorrow, along with the packages.
Thanks -- as always, I appreciate the status reports.
Am 02.03.2011 23:28, schrieb Karanbir Singh:
hi guys,
EL5 got a bunch of updates that really need to make it out asap, and while 4.9 settles down - the thinking is to get them released into the 5.5/updates repo. I'll have an exact list of what all is going to make it in the day tomorrow, along with the packages.
isn't putting 5.x packages into a 5.(x-1) repo what fasttrack was once intended for?
Just my 2 cent...
On 03/04/2011 04:10 PM, Andreas Rogge wrote:
isn't putting 5.x packages into a 5.(x-1) repo what fasttrack was once intended for?
I am not sure if it was ever quantified in that way, but fastrack isnt a repo enabled on most machines out there.
There are a couple of tricky builds, but if we can get them done today we should have the updates out right away. Nothing in there seems to be a major blocker.
- KB
On 04/03/11 16:10, Andreas Rogge wrote:
Am 02.03.2011 23:28, schrieb Karanbir Singh:
hi guys,
EL5 got a bunch of updates that really need to make it out asap, and while 4.9 settles down - the thinking is to get them released into the 5.5/updates repo. I'll have an exact list of what all is going to make it in the day tomorrow, along with the packages.
isn't putting 5.x packages into a 5.(x-1) repo what fasttrack was once intended for?
No, the fasttrack channel/repo was supposed to be a rebuild of the upstream FasTrack channel, but it never really materialised, at least not for 5.x.
The choices are to put these 5.6 updates into the 5.5/updates repo and risk potential breakage in exchange for wider adoption or to put them into a testing channel where the vast majority of users would likely never see/deploy them.
Dne 2.3.2011 23:28, Karanbir Singh napsal(a):
hi guys,
EL5 got a bunch of updates that really need to make it out asap, and while 4.9 settles down - the thinking is to get them released into the 5.5/updates repo. I'll have an exact list of what all is going to make it in the day tomorrow, along with the packages.
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Karanbir, What's the current state of this effort? DH
On 03/07/2011 05:37 PM, David Hrbáč wrote:
EL5 got a bunch of updates that really need to make it out asap, and while 4.9 settles down - the thinking is to get them released into the
What's the current state of this effort?
There are some deep linking issues with the updates. I thought we had the final tree for 5.6 in place last night, but there are 2 issues that Ned pointed out which I hope to get done shortly - in the next few hours and have the tree's over into QA. Once that is done, the updates can churn though.
- KB
Karanbir Singh wrote:
On 03/07/2011 10:48 PM, Karanbir Singh wrote:
and have the tree's over into QA. Once that is done, the updates can churn though.
Just a quick update to this, updates now churning. The last bits of 5.6 fell into place over the course of the last 24 hrs.
- KB
That is very nice to hear.
Can you comment on CentOS 6.0 status? Is it still 2-3 weeks from now or was there any progress that will shorten this period?
Ljubomir
On Wed, Mar 9, 2011 at 11:46 AM, Karanbir Singh mail-lists@karan.org wrote:
On 03/09/2011 05:47 PM, Ljubomir Ljubojevic wrote:
Can you comment on CentOS 6.0 status? Is it still 2-3 weeks from now or was there any progress that will shorten this period?
2 - 3 weeks from GA release of 5.6 is still a good time line to plan against.
If the response to a question regarding "CentOS 6.0 status" only relates to "GA release of 5.6", then, in spite of the constant responses to the contrary, there is a discrepancy between "what is expected from CentOS", and "what is delivered by CentOS". Period. End of story. Own up to it. Fix it.
jerry
If the response to a question regarding "CentOS 6.0 status" only relates to "GA release of 5.6", then, in spite of the constant responses to the contrary, there is a discrepancy between "what is expected from CentOS", and "what is delivered by CentOS". Period. End of story. Own up to it. Fix it.
jerry
Obviously you haven't been paying attention, they are getting 4.9/5.6 out the door first before pushing resources to 6. If you have an issue with the wait then you are free to install SL or RHEL.
On 03/10/2011 04:00 AM, Jerry Amundson wrote:
If the response to a question regarding "CentOS 6.0 status" only relates to "GA release of 5.6", then, in spite of the constant responses to the contrary, there is a discrepancy between "what is expected from CentOS", and "what is delivered by CentOS". Period. End of story. Own up to it. Fix it.
What a load of bollocks.
If this was your first post here, I'd assume differently - but, having been here long enough, I'd now say you just dont know whats going on. Give up. go home. The complexity of this stuff is beyond what you are able to parse.
bye,
- KB
On 03/10/2011 11:04 AM, Karanbir Singh wrote:
The complexity of this stuff is beyond what you are able to parse.
Could you please elaborate?
I don't mean here in reply to this posting. I mean it long-term, in the bug tracker and also in a publicly accessible git repo of patches and quirks. As things are now, the dev team has a huge amount of knowledge on how CentOS is made, but very little of it trickles outside the core team.
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it, learn from it, improve upon it, and also contribute back? Would you care to share your scripts and other wheels, so others won't have to re-invent them?
Mind you, I'm not asking you to start writing documentation or do anything that would take away resources from actually producing CentOS. What I'm asking is just that you open up the work you're doing anyway, no extra cost involved.
Doing so would also serve to protect your work in the long term. People tend to get hit by busses, by marriage, by small children, by new jobs, you name it. CentOS is so big by now that it deserves protection also from its own team. If you would disappear one day for whatever reason, good or bad, others should be able to take over and continue where you left. Sharing the knowledge creates that protection.
Z
On 03/10/2011 04:53 PM, Zenon Panoussis wrote:
On 03/10/2011 11:04 AM, Karanbir Singh wrote:
The complexity of this stuff is beyond what you are able to parse.
Could you please elaborate?
I don't mean here in reply to this posting. I mean it long-term, in the bug tracker and also in a publicly accessible git repo of patches and quirks. As things are now, the dev team has a huge amount of knowledge on how CentOS is made, but very little of it trickles outside the core team.
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it, learn from it, improve upon it, and also contribute back? Would you care to share your scripts and other wheels, so others won't have to re-invent them?
Mind you, I'm not asking you to start writing documentation or do anything that would take away resources from actually producing CentOS. What I'm asking is just that you open up the work you're doing anyway, no extra cost involved.
Johnny Hughes has already provided the info and the scripts . See http://lists.centos.org/pipermail/centos-devel/2011-February/006735.html and later messages
On 03/10/2011 04:12 PM, Manuel Wolfshant wrote:
The complexity of this stuff is beyond what you are able to parse.
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it,
Johnny Hughes has already provided the info and the scripts . See http://lists.centos.org/pipermail/centos-devel/2011-February/006735.html and later messages
Are you referring to http://people.centos.org/hughesjr/buildsystem/ and http://mirror.centos.org/centos-4/4/build/distro/tmverifyrpms ? Indeed, I had missed those.
But I was talking about "de-branding and building". For example, it has been repeated over and over again that most changes are made in the build root, not in the SRPMS themselves, but where can I find information about the de-branding which actually *is* done in the SRPMS themselves? I could find out by installing all the RH SRPMS in one directory and all the CentOS SRPMS in another and diff'ing the two, but I assume there is already a list of all the (known) modifications that are needed for de-branding. Has this list been published somewhere?
Likewise, many of the changes to the build root - hidden dependencies etc - are likely to have been documented somewhere. Sort of "note to self: need to install external xyz from Fedora NN before building abc". Couldn't that documentation be made public and easily accessible?
That last part, "easily accessible", is just as important as "public". There might be lots of tidbits of information on this list, but finding them is a drag.
Finally, I can't find any details on the process of comparing RPMs, apart from tmverifyrpms that you just pointed me to. What needs to be compared, apart from size? What is the definition of "good" or "good enough"?
If simple things like that, information that already exists, were to be gathered in one place, the sharing of knowledge that I was talking about would already be a fact.
Z
On 03/10/2011 10:12 AM, Zenon Panoussis wrote:
On 03/10/2011 04:12 PM, Manuel Wolfshant wrote:
The complexity of this stuff is beyond what you are able to parse.
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it,
Johnny Hughes has already provided the info and the scripts . See http://lists.centos.org/pipermail/centos-devel/2011-February/006735.html and later messages
Are you referring to http://people.centos.org/hughesjr/buildsystem/ and http://mirror.centos.org/centos-4/4/build/distro/tmverifyrpms ? Indeed, I had missed those.
But I was talking about "de-branding and building". For example, it has been repeated over and over again that most changes are made in the build root, not in the SRPMS themselves, but where can I find information about the de-branding which actually *is* done in the SRPMS themselves? I could find out by installing all the RH SRPMS in one directory and all the CentOS SRPMS in another and diff'ing the two, but I assume there is already a list of all the (known) modifications that are needed for de-branding. Has this list been published somewhere?
Any SRPM modified by CentOS will have a .centos in the name of the SRPM (that is noted in our FAQ). If it does not have a .centos, it is the same as upstream. The only exception is the kernel (we modify it not be signed by a key that says Red Hat, Inc) and we do not rename it as this will cause 3rd party drivers not to install. (Also noted in our FAQ). These packages that are CentOS modified are also listed in the release notes.
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.5#head-b412468e15231f72d...
As far as reapplying our patches again to a new SRPM when released from upstream, that is EXACTLY how I do it. I first install the old CentOS SRPM. I go to the rpmbuild directory and I move SPECS to SPECS.old and SOURCES to SOURCES.old. Then I install the new upstream SRPM. I copy any patches (or other sources) that have "centos" in the name from the SOURCES.old directory to the SOURCES directory. I then look at the old spec file and the new spec file in VI using vsplit and copy the portions that need to be changed into the new spec file (usually add a couple of centos patches). Then I rpmbuild -bp and see of the patches still apply. If they do apply, I use mock to build to new SRPM into RPMs ... if the patches do not apply cleanly I redesign the patches to apply on this version, then build.
If I need to figure out what changed in the old centos spec file, I will install the old upstream package and diff it against the original.
There is nothing magic ... if you have the .centos SRPM and the upstream SRPM, then you have everything I use. If you can set up mock and point it to the current centos tree, then you have the build system I use. The host OS I use for the mock builder is CentOS 5, latest updates.
Likewise, many of the changes to the build root - hidden dependencies etc - are likely to have been documented somewhere. Sort of "note to self: need to install external xyz from Fedora NN before building abc". Couldn't that documentation be made public and easily accessible?
It has been made public:
http://lists.centos.org/pipermail/centos/2011-February/106570.html
But, you need to understand that the list is fluid. If a package does not build because of a hidden build requirement, that is a bug. You have to figure it out to get it to build, but the next time you build that package you will likely NOT need to change the build root as they will likely have fixed the issue by then. We first try to build every package in a mock build root that it builds on it's own ... only if it fails do we look at why and make changes to the build root. Every time we do it, it is unique to that specific situation. It is likely never to be repeated again.
That last part, "easily accessible", is just as important as "public". There might be lots of tidbits of information on this list, but finding them is a drag.
Why is that important. Red Hat did not tell me how to build it. The purpose of the CentOS Project is to produce an operating system that you can choose to use or not to use. It is not to tell someone else how to produce an operating system. Why should I tell someone how to build a replacement OS to CentOS. That makes no sense at all.
Finally, I can't find any details on the process of comparing RPMs, apart from tmverifyrpms that you just pointed me to. What needs to be compared, apart from size? What is the definition of "good" or "good enough"?
The file tells you what we use. It tells you the conditions that produce a FAIL.
If simple things like that, information that already exists, were to be gathered in one place, the sharing of knowledge that I was talking about would already be a fact.
On 03/10/2011 05:50 PM, Johnny Hughes wrote:
[de-branding]
There is nothing magic ... if you have the .centos SRPM and the upstream SRPM, then you have everything I use.
Of course there is no magic, but there is a lot of work already invested. Ready patches for example. Anyone who has those patches could already be testing them on the next release, instead of starting off from scratch by making them.
[dependencies]
It has been made public: http://lists.centos.org/pipermail/centos/2011-February/106570.html
Thank you, that's yet another posting I had missed.
But, you need to understand that the list is fluid. If a package does not build because of a hidden build requirement, that is a bug. You have to figure it out to get it to build, but the next time you build that package you will likely NOT need to change the build root as they will likely have fixed the issue by then.
Over the years I have reported a number of these myself upstream and my experience is varied. Sometimes they fix things, sometimes not. Having a summary of all quirks that were needed to build a release makes building the next one so much easier.
That last part, "easily accessible", is just as important as "public". There might be lots of tidbits of information on this list, but finding them is a drag.
Why is that important. Red Hat did not tell me how to build it. The purpose of the CentOS Project is to produce an operating system that you can choose to use or not to use. It is not to tell someone else how to produce an operating system. Why should I tell someone how to build a replacement OS to CentOS. That makes no sense at all.
I'm not telling you to tell someone how to build a replacement of CentOS. I'm saying that you should tell everyone how to build CentOS itself. That would guarantee an influx of developers and CentOS' long-term survival, also past the point when you decide to swap your keyboard for a hammock in some tropical island.
Z
I'm saying that you should tell everyone how to build CentOS itself. That would guarantee an influx of developers and CentOS' long-term survival, also past the point when you decide to swap your keyboard for a hammock in some tropical island.
You do realise that developers is not what is needed right?
No development itself is done in CentOS. If you want to do development work that will end up in this distro contribute to fedora and if redhat picks it one day that bit of development work could appear here...
James
On 03/10/2011 11:20 AM, Zenon Panoussis wrote:
On 03/10/2011 05:50 PM, Johnny Hughes wrote:
[de-branding]
There is nothing magic ... if you have the .centos SRPM and the upstream SRPM, then you have everything I use.
Of course there is no magic, but there is a lot of work already invested. Ready patches for example. Anyone who has those patches could already be testing them on the next release, instead of starting off from scratch by making them.
Patches are in the SRPM ... in the SOURCES directory. I told exactly how I build packages. Everything is in the SRPM.
[dependencies]
It has been made public: http://lists.centos.org/pipermail/centos/2011-February/106570.html
Thank you, that's yet another posting I had missed.
But, you need to understand that the list is fluid. If a package does not build because of a hidden build requirement, that is a bug. You have to figure it out to get it to build, but the next time you build that package you will likely NOT need to change the build root as they will likely have fixed the issue by then.
Over the years I have reported a number of these myself upstream and my experience is varied. Sometimes they fix things, sometimes not. Having a summary of all quirks that were needed to build a release makes building the next one so much easier.
That last part, "easily accessible", is just as important as "public". There might be lots of tidbits of information on this list, but finding them is a drag.
Why is that important. Red Hat did not tell me how to build it. The purpose of the CentOS Project is to produce an operating system that you can choose to use or not to use. It is not to tell someone else how to produce an operating system. Why should I tell someone how to build a replacement OS to CentOS. That makes no sense at all.
I'm not telling you to tell someone how to build a replacement of CentOS. I'm saying that you should tell everyone how to build CentOS itself. That would guarantee an influx of developers and CentOS' long-term survival, also past the point when you decide to swap your keyboard for a hammock in some tropical island.
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch. The problem is that this stuff takes time. We build it, we test it, we fix it, we build it again. If I make a change and respin the OS, it takes a day for that to get onto the QA and another day (or two) for them to test it.
On 3/10/2011 12:05 PM, Johnny Hughes wrote:
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch. The problem is that this stuff takes time. We build it, we test it, we fix it, we build it again. If I make a change and respin the OS, it takes a day for that to get onto the QA and another day (or two) for them to test it.
But if you aren't short of resources, why can't the 4.x, 5.x, 6.x flavors proceed in parallel?
On 03/10/2011 12:16 PM, Les Mikesell wrote:
On 3/10/2011 12:05 PM, Johnny Hughes wrote:
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch. The problem is that this stuff takes time. We build it, we test it, we fix it, we build it again. If I make a change and respin the OS, it takes a day for that to get onto the QA and another day (or two) for them to test it.
But if you aren't short of resources, why can't the 4.x, 5.x, 6.x flavors proceed in parallel?
They can and are.
4.9 is released
5.6 is in QA testing for the last week
6.0 has all but 30 or so packages built.
We are concentrating on some (4.9 and 5.6) more than others, but they are all on going.
On Thu, 10 Mar 2011, Johnny Hughes wrote:
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch.
Johnny,
Who are those 6 people and are they all involved in the various CentOS releases ?
On 03/10/2011 03:12 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch.
Johnny,
Who are those 6 people and are they all involved in the various CentOS releases ?
Everyone is involved in the release and getting ready for the release, but not everyone is involved in building the packages. For example, we have two QA servers that host the QA tree that need to be managed. We have a QA mailing list and DNS names that need created and maintained. We have access control lists for the QA servers that need to be maintained. We have a mirror system (both internal and external) that needs to be prepared for release. We have a mirrorlist program that assigns mirrors which has to be modified on releases.
We have had the majority of the 5.6 build done for 2 weeks ... then we had several technical issues with building the distro with anaconda and we have found some other problems during the testing.
There is no need to name names, but every member of the team is very busy making releases happen.
So is the QA group/team. We have found and fixed several issues during this testing cycle for 5.6.
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 03:12 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch.
Who are those 6 people and are they all involved in the various CentOS releases ?
There is no need to name names, but every member of the team is very busy making releases happen.
I know of Karanbir, Tru and you, but haven't seen anyone else announcing signed packages. From the Team page at http://wiki.centos.org/Team I can only identify Russ as being active on the mailinglist.
Who has access to the buildsystem and who has access to the keys for signing wrt. CentOS 4.9, 5.6 and 6.0 ?
On Thu, 10 Mar 2011, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 03:12 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch.
Who are those 6 people and are they all involved in the various CentOS releases ?
There is no need to name names, but every member of the team is very busy making releases happen.
I know of Karanbir, Tru and you, but haven't seen anyone else announcing signed packages. From the Team page at http://wiki.centos.org/Team I can only identify Russ as being active on the mailinglist.
Sorry Ralph ! You too ;-)
Who has access to the buildsystem and who has access to the keys for signing wrt. CentOS 4.9, 5.6 and 6.0 ?
On 03/10/2011 03:45 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 03:12 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
CentOS does not rely on one person. We have a QA team of 30 or so people and at least 6 developers who could build OS from scratch.
Who are those 6 people and are they all involved in the various CentOS releases ?
There is no need to name names, but every member of the team is very busy making releases happen.
I know of Karanbir, Tru and you, but haven't seen anyone else announcing signed packages. From the Team page at http://wiki.centos.org/Team I can only identify Russ as being active on the mailinglist.
Sorry Ralph ! You too ;-)
Who has access to the buildsystem and who has access to the keys for signing wrt. CentOS 4.9, 5.6 and 6.0 ?
We don't just use one buildsystem ... like I said, it is not just about building. I don't think I need to discuss our internal infrastructure on an open list either.
Jim Perrin and Fabian Arrotin also have access to some infrastructure too. Tim Verhoeven has some access as well. Not to the signing keys ... not many people have that, but to be able to build some packages.
Akemi Yagi does some packages for us too, notably the CentOS Plus kernel.
Not sure where this is going.
2011/3/10 Johnny Hughes johnny@centos.org:
We don't just use one buildsystem ... like I said, it is not just about building. I don't think I need to discuss our internal infrastructure on an open list either.
Hi Johnny,
Why? (C = Community [?] Enterprise Operating System)
Do you build C6 packages on C5 build servers? Which mock version? Where can I get the buildlogs?
Best regards,
Morten
On 03/10/2011 04:14 PM, Morten P.D. Stevens wrote:
2011/3/10 Johnny Hughes johnny@centos.org:
We don't just use one buildsystem ... like I said, it is not just about building. I don't think I need to discuss our internal infrastructure on an open list either.
Hi Johnny,
Why? (C = Community [?] Enterprise Operating System)
Do you build C6 packages on C5 build servers? Which mock version? Where can I get the buildlogs?
You can't get the build logs, no.
Community because all the QA team, the forum moderators, the graphics team, the mailing lists and the wiki are all members of the community providing help.
We do not build CentOS 6 on CentOS 5 servers because of the new version of RPM and the issues getting those to install properly via the CentOS-5 yum/rpm is not worth the effort. We therefore are using a mixture of RHEL6Beta2 and Fedora-12 with mock 1.1.3 or 1.1.4 for CentOS6.
For CentOS4 and CentOS5, we use exactly what we have in centos extras (mock 0.6.8) to build.
CentOS is for the community ... it is not BUILT buy the community.
2011/3/10 Johnny Hughes johnny@centos.org
[...] CentOS is for the community ... it is not BUILT buy the community. [...]
If this statement was already on the list back in December, tons of emails where completely unnecessary. This is the big misunderstanding, a lot of people interpret the C as something that the community is doing, not that the community is using. This is normally declared as free, so FentOS might be a better name or even better FOS because enterprise stand for fixed release cycles and other professional stuff that is not match with statements like it's done when it's done. But nevertheless what the name is, if you put this information on the top of the CentOS page or at least somewhere on the top of the FAQ section or so, everyone will know what the purpose of CentOS is and I guess they will only ask when things are released and not anymore how they can help. So this should significant reduce the amount of mails on this list.
Kind regards, Thomas
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 03:45 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Dag Wieers wrote:
I know of Karanbir, Tru and you, but haven't seen anyone else announcing signed packages. From the Team page at http://wiki.centos.org/Team I can only identify Russ as being active on the mailinglist.
Sorry Ralph ! You too ;-)
Who has access to the buildsystem and who has access to the keys for signing wrt. CentOS 4.9, 5.6 and 6.0 ?
We don't just use one buildsystem ... like I said, it is not just about building. I don't think I need to discuss our internal infrastructure on an open list either.
Jim Perrin and Fabian Arrotin also have access to some infrastructure too. Tim Verhoeven has some access as well. Not to the signing keys ... not many people have that, but to be able to build some packages.
Akemi Yagi does some packages for us too, notably the CentOS Plus kernel.
Not sure where this is going.
This is going towards more understanding from the community to how CentOS is being built, who is involved and where the problems are situated.
This information is not available from anywhere else. So only Karanbir, Tru and you have access to the signing keys.
Jim, Fabian, Tim and Akemi have access to certain buildsystems or infrastructure but have not built any packages for CentOS 4.9, 5.6 and 6.0 ?
I guess this also means that just the three of you can produce updates ?
On 03/10/2011 04:18 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 03:45 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Dag Wieers wrote:
I know of Karanbir, Tru and you, but haven't seen anyone else announcing signed packages. From the Team page at http://wiki.centos.org/Team I can only identify Russ as being active on the mailinglist.
Sorry Ralph ! You too ;-)
Who has access to the buildsystem and who has access to the keys for signing wrt. CentOS 4.9, 5.6 and 6.0 ?
We don't just use one buildsystem ... like I said, it is not just about building. I don't think I need to discuss our internal infrastructure on an open list either.
Jim Perrin and Fabian Arrotin also have access to some infrastructure too. Tim Verhoeven has some access as well. Not to the signing keys ... not many people have that, but to be able to build some packages.
Akemi Yagi does some packages for us too, notably the CentOS Plus kernel.
Not sure where this is going.
This is going towards more understanding from the community to how CentOS is being built, who is involved and where the problems are situated.
This information is not available from anywhere else. So only Karanbir, Tru and you have access to the signing keys.
Jim, Fabian, Tim and Akemi have access to certain buildsystems or infrastructure but have not built any packages for CentOS 4.9, 5.6 and 6.0 ?
I guess this also means that just the three of you can produce updates ?
No, it means that only the 3 of us can SIGN updates ... there is a difference.
On Thu, 10 Mar 2011, Dag Wieers wrote:Hughes:
Hughes:
too. Tim Verhoeven has some access as well. Not to the signing keys ... not many people have that, but to be able to build some packages.
This information is not available from anywhere else. So only Karanbir, Tru and you have access to the signing keys.
This information as to who particularly has access to the signing keys has intentionally never been discussed publicly. I would prefer the cyber-ninja's did not break into my safe-deposit box at the bank to steal the media bearing the 'end of the world' backup copies and pass-phrases
Is there a purpose to mis-reading and mis-stating what was said, Dag?
You made the choice to leave and close a door, Dag, subsequent to having been recruited in part by me and others to be on a track that would have ended up in you being a signer and builder for record for CentOS
That is over, and that door will not re-open
-- Russ herrold
On Thu, 10 Mar 2011, R P Herrold wrote:
On Thu, 10 Mar 2011, Dag Wieers wrote:Hughes:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
Not sure where this is going.
This information is not available from anywhere else. So only Karanbir, Tru and you have access to the signing keys.
This information as to who particularly has access to the signing keys has intentionally never been discussed publicly. I would prefer the cyber-ninja's did not break into my safe-deposit box at the bank to steal the media bearing the 'end of the world' backup copies and pass-phrases
Is there a purpose to mis-reading and mis-stating what was said, Dag?
I leave the mis-reading and mis-stating up to you. Since a few months I am genuinly interested in the CentOS process. Mind you, despite my background, I never was involved in those details.
You made the choice to leave and close a door, Dag, subsequent to having been recruited in part by me and others to be on a track that would have ended up in you being a signer and builder for record for CentOS
That is over, and that door will not re-open
Russ, thank you for bringing this up, as irrelevant as it is today. I'll ignore this vile attempt to shut me up by trying to discredit me. It can only remind me that leaving was the right thing to do.
Besides, you mis-characterize my involvement. I never even asked for or attempted to have any powers other than helping with promotion, wiki and community-matters. I have too many other responsibilities already.
But, all this is irrelevant today, although what I wrote in my resignation-letter still holds today:
----- -snip-
However a recent incident showed yet again a lack of trust and appreciation and made me question my involvement. There are also a few reasons that I consider internal kitchen and therefore will not be disclosed, but the project lacks leadership, shows poor communication, little transparency and fails to engage more people from the community (eg. great need for improvements, plenty offerings, but slow or little acceptance).
I never had any responsibility in producing the base CentOS distribution and therefore my decision will not have any effect on the final product that people are using. That what makes CentOS a good Linux distribution with, quite possibly, the largest installed Linux base.
And while I may no longer be part of the CentOS team, I still am an avid CentOS user and advocate. And hope that the team (of which I consider many good friends) can turn this around for the benefit of its community, including myself :-)
-snip- -----
On 03/10/2011 04:18 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 03:45 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Dag Wieers wrote:
I know of Karanbir, Tru and you, but haven't seen anyone else announcing signed packages. From the Team page at http://wiki.centos.org/Team I can only identify Russ as being active on the mailinglist.
Sorry Ralph ! You too ;-)
Who has access to the buildsystem and who has access to the keys for signing wrt. CentOS 4.9, 5.6 and 6.0 ?
We don't just use one buildsystem ... like I said, it is not just about building. I don't think I need to discuss our internal infrastructure on an open list either.
Jim Perrin and Fabian Arrotin also have access to some infrastructure too. Tim Verhoeven has some access as well. Not to the signing keys ... not many people have that, but to be able to build some packages.
Akemi Yagi does some packages for us too, notably the CentOS Plus kernel.
Not sure where this is going.
This is going towards more understanding from the community to how CentOS is being built, who is involved and where the problems are situated.
This information is not available from anywhere else. So only Karanbir, Tru and you have access to the signing keys.
Jim, Fabian, Tim and Akemi have access to certain buildsystems or infrastructure but have not built any packages for CentOS 4.9, 5.6 and 6.0 ?
I guess this also means that just the three of you can produce updates ?
BTW, how many people have access to YOUR private signing key for your repo?
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 04:18 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Johnny Hughes wrote:
On 03/10/2011 03:45 PM, Dag Wieers wrote:
On Thu, 10 Mar 2011, Dag Wieers wrote:
I know of Karanbir, Tru and you, but haven't seen anyone else announcing signed packages. From the Team page at http://wiki.centos.org/Team I can only identify Russ as being active on the mailinglist.
Sorry Ralph ! You too ;-)
Who has access to the buildsystem and who has access to the keys for signing wrt. CentOS 4.9, 5.6 and 6.0 ?
We don't just use one buildsystem ... like I said, it is not just about building. I don't think I need to discuss our internal infrastructure on an open list either.
Jim Perrin and Fabian Arrotin also have access to some infrastructure too. Tim Verhoeven has some access as well. Not to the signing keys ... not many people have that, but to be able to build some packages.
Akemi Yagi does some packages for us too, notably the CentOS Plus kernel.
Not sure where this is going.
This is going towards more understanding from the community to how CentOS is being built, who is involved and where the problems are situated.
This information is not available from anywhere else. So only Karanbir, Tru and you have access to the signing keys.
Jim, Fabian, Tim and Akemi have access to certain buildsystems or infrastructure but have not built any packages for CentOS 4.9, 5.6 and 6.0 ?
I guess this also means that just the three of you can produce updates ?
BTW, how many people have access to YOUR private signing key for your repo?
That is very known, I am the only one who can sign for my repository.
On Thu, Mar 10, 2011 at 2:18 PM, Dag Wieers dag@wieers.com wrote:
Jim, Fabian, Tim and Akemi have access to certain buildsystems or infrastructure ...
Because my name appeared "inadvertently" in that sentence, I may have to say something :-)
Unlike Jim, Fabian and Tim, I am just a user [TM]. I have no access to any CentOS buildsystems. All my works related to CentOS are done on my personal machines. When I offer packages (centosplus kernel testing, for example), I do so from my web site ( toracat.org ). I am just a user [TM]. :)
Akemi
On Thu, 10 Mar 2011, Johnny Hughes wrote:
There is no need to name names, but every member of the team is very busy making releases happen.
I would note that with my broken ankle, mentioned on this list a couple months ago, this go-round, that I have been less active than usual in the release process for 4.9, 5.6, and 6 initial, as it is just so darned hard to work on must a laptop and remotely to do development
I see the count was at 5 publicly mentioned scanning ahead in the thread. John Newbegin and Donavan Nelson also run builds, and so we are at seven -- more than the six Johnny mentioned off the top of his head
The suggestion by a relative newcomer that the project would fall apart from a lack of depth or interest of developers, seems to me to be just another troll
-- Russ herrold
On 03/10/2011 11:13 PM, R P Herrold wrote:
The suggestion by a relative newcomer that the project would fall apart from a lack of depth or interest of developers, seems to me to be just another troll
Are you referring to me? If so, that's not what I said; not that the project will fall apart and certainly not from a lack of depth or interest of developers. What I said was that the project would benefit from more openness and from the involvement of more people, and that a broader involvement would also give better guarantees for the project's long-term future.
As for trolling, let me remind you of this in case you forgot: http://lists.centos.org/pipermail/centos/2009-July/079767.html Inflammatory language and name-calling does not make your argument; it breaks it.
In any case, this whole discussion is moving in rather inconsistent ways. I mean, you can't at the same time (a) boast serving 8 million unique machines worldwide, (b) be 4 months and counting behind upstream, (c) be so protective of your project that you just dodge offers for help and (d) two months later also claim that the project has all the manpower that it needs (see links at the bottom). Any one or two of these statements would be valid, but not all four at the same time.
Apart from that, it is completely up to the owners of the project how they want to organise it and manage it, but it is also common knowledge that openly managed projects thrive more than closed ones. I'm not talking about democracy here, let alone consensus; I'm just talking about creating coherence and involvement by letting people know what is happenning, how, when and why and by letting them contribute instead of brushing them off. To quote from the link above: "Please do not kill CentOS through your fear of shared management of the project". Please take a good look at the signatures below that statement.
With that said, I don't see much of a point in carrying this discussion further. If a discussion is not constructive, then it better not be at all.
Z
(a) http://lists.centos.org/pipermail/centos-devel/2011-February/006935.html (b) http://www.redhat.com/about/news/prarchive/2010/new-standard.html (c) http://lists.centos.org/pipermail/centos-devel/2011-January/006558.html (d) http://lists.centos.org/pipermail/centos-devel/2011-March/007087.html
Am 10.03.2011 um 18:20 schrieb Zenon Panoussis:
But, you need to understand that the list is fluid. If a package does not build because of a hidden build requirement, that is a bug. You have to figure it out to get it to build, but the next time you build that package you will likely NOT need to change the build root as they will likely have fixed the issue by then.
Over the years I have reported a number of these myself upstream and my experience is varied. Sometimes they fix things, sometimes not. Having a summary of all quirks that were needed to build a release makes building the next one so much easier.
Clearly a misunderstanding. You can't define a fixed process. The process will be renewed everytime. This has different reasons. The util-linux/gettext example is one of them and this one will disappear in future releases.
I understand that you try to get the facts compiled. But this would not really help for future releases, compared to an understanding of the underlying concept that allows you to handle new facts.
PM
On Thu, Mar 10, 2011 at 11:50 AM, Johnny Hughes johnny@centos.org wrote:
Any SRPM modified by CentOS will have a .centos in the name of the SRPM (that is noted in our FAQ). If it does not have a .centos, it is the same as upstream. The only exception is the kernel (we modify it not be
This is quite sensible. Is this documented anywhere? I'm not finding it in tne Wiki, but admittedly my Wiki expertise is not absolute.
signed by a key that says Red Hat, Inc) and we do not rename it as this will cause 3rd party drivers not to install. (Also noted in our FAQ). These packages that are CentOS modified are also listed in the release notes.
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.5#head-b412468e15231f72d...
As far as reapplying our patches again to a new SRPM when released from upstream, that is EXACTLY how I do it. I first install the old CentOS SRPM. I go to the rpmbuild directory and I move SPECS to SPECS.old and SOURCES to SOURCES.old. Then I install the new upstream SRPM. I copy any patches (or other sources) that have "centos" in the name from the SOURCES.old directory to the SOURCES directory. I then look at the old spec file and the new spec file in VI using vsplit and copy the portions that need to be changed into the new spec file (usually add a couple of centos patches). Then I rpmbuild -bp and see of the patches still apply. If they do apply, I use mock to build to new SRPM into RPMs ... if the patches do not apply cleanly I redesign the patches to apply on this version, then build.
If I need to figure out what changed in the old centos spec file, I will install the old upstream package and diff it against the original.
There is nothing magic ... if you have the .centos SRPM and the upstream SRPM, then you have everything I use. If you can set up mock and point it to the current centos tree, then you have the build system I use. The host OS I use for the mock builder is CentOS 5, latest updates.
Likewise, many of the changes to the build root - hidden dependencies etc - are likely to have been documented somewhere. Sort of "note to self: need to install external xyz from Fedora NN before building abc". Couldn't that documentation be made public and easily accessible?
It has been made public:
http://lists.centos.org/pipermail/centos/2011-February/106570.html
But, you need to understand that the list is fluid. If a package does not build because of a hidden build requirement, that is a bug. You have to figure it out to get it to build, but the next time you build that package you will likely NOT need to change the build root as they will likely have fixed the issue by then. We first try to build every package in a mock build root that it builds on it's own ... only if it fails do we look at why and make changes to the build root. Every time we do it, it is unique to that specific situation. It is likely never to be repeated again.
That last part, "easily accessible", is just as important as "public". There might be lots of tidbits of information on this list, but finding them is a drag.
Why is that important. Red Hat did not tell me how to build it. The purpose of the CentOS Project is to produce an operating system that you can choose to use or not to use. It is not to tell someone else how to produce an operating system. Why should I tell someone how to build a replacement OS to CentOS. That makes no sense at all.
Finally, I can't find any details on the process of comparing RPMs, apart from tmverifyrpms that you just pointed me to. What needs to be compared, apart from size? What is the definition of "good" or "good enough"?
The file tells you what we use. It tells you the conditions that produce a FAIL.
If simple things like that, information that already exists, were to be gathered in one place, the sharing of knowledge that I was talking about would already be a fact.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Mar 10, 2011, at 5:36 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 11:50 AM, Johnny Hughes johnny@centos.org wrote:
Any SRPM modified by CentOS will have a .centos in the name of the SRPM (that is noted in our FAQ). If it does not have a .centos, it is the same as upstream. The only exception is the kernel (we modify it not be
This is quite sensible. Is this documented anywhere? I'm not finding it in tne Wiki, but admittedly my Wiki expertise is not absolute.
He said it was in the FAQ, and in my two minute perusal I found it, and Johnny's note, dating from 2005. See http://www.centos.org/modules/smartfaq/faq.php?faqid=9 -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu
On 03/10/2011 04:36 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 11:50 AM, Johnny Hughes johnny@centos.org wrote:
Any SRPM modified by CentOS will have a .centos in the name of the SRPM (that is noted in our FAQ). If it does not have a .centos, it is the same as upstream. The only exception is the kernel (we modify it not be
This is quite sensible. Is this documented anywhere? I'm not finding it in tne Wiki, but admittedly my Wiki expertise is not absolute.
It has been posted on the FAQ in the first comment here:
http://linuxreference.com/modules/smartfaq/faq.php?faqid=9
(since 2005/5/14)
It is also in the Wiki in question #4 text here:
On Thu, Mar 10, 2011 at 5:52 PM, Johnny Hughes johnny@centos.org wrote:
On 03/10/2011 04:36 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 11:50 AM, Johnny Hughes johnny@centos.org wrote:
Any SRPM modified by CentOS will have a .centos in the name of the SRPM (that is noted in our FAQ). If it does not have a .centos, it is the same as upstream. The only exception is the kernel (we modify it not be
This is quite sensible. Is this documented anywhere? I'm not finding it in tne Wiki, but admittedly my Wiki expertise is not absolute.
It has been posted on the FAQ in the first comment here:
http://linuxreference.com/modules/smartfaq/faq.php?faqid=9
(since 2005/5/14)
It is also in the Wiki in question #4 text here:
Thanks. It's an answer to somewhat *different* question, so I missed it, but OK.
On Thu, Mar 10, 2011 at 6:31 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Mar 10, 2011 at 5:52 PM, Johnny Hughes johnny@centos.org wrote:
On 03/10/2011 04:36 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 11:50 AM, Johnny Hughes johnny@centos.org wrote:
Any SRPM modified by CentOS will have a .centos in the name of the SRPM (that is noted in our FAQ). If it does not have a .centos, it is the same as upstream. The only exception is the kernel (we modify it not be
This is quite sensible. Is this documented anywhere? I'm not finding it in tne Wiki, but admittedly my Wiki expertise is not absolute.
It has been posted on the FAQ in the first comment here:
http://linuxreference.com/modules/smartfaq/faq.php?faqid=9
(since 2005/5/14)
It is also in the Wiki in question #4 text here:
Thanks. It's an answer to somewhat *different* question, so I missed it, but OK.
On review, it's also lacking detail. The use of the "%{dist}" option in .spec is a wonderful standardization, and of '%{?dist}" even more effective by the upstream vendor. It really helps allow developers to set it in their .rpmmacros and use the defaults when they run it through mock to build production versions, so I *assume* that your mock environments are not resetting this. Perhaps a mention that "we prefer to tweak it by editing the .spec files as necessary, and those modified .spec files are available at publicly accessible source Subversion mirror 'http://svnmirror.centos.org"..
I've really been hoping for public access to the build structure. "You can do it yourself" is not as helpful as the kind of public access to build structures that Dag publishes, and has been suggesting.
On 03/10/2011 05:41 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 6:31 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Mar 10, 2011 at 5:52 PM, Johnny Hughes johnny@centos.org wrote:
On 03/10/2011 04:36 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 11:50 AM, Johnny Hughes johnny@centos.org wrote:
Any SRPM modified by CentOS will have a .centos in the name of the SRPM (that is noted in our FAQ). If it does not have a .centos, it is the same as upstream. The only exception is the kernel (we modify it not be
This is quite sensible. Is this documented anywhere? I'm not finding it in tne Wiki, but admittedly my Wiki expertise is not absolute.
It has been posted on the FAQ in the first comment here:
http://linuxreference.com/modules/smartfaq/faq.php?faqid=9
(since 2005/5/14)
It is also in the Wiki in question #4 text here:
Thanks. It's an answer to somewhat *different* question, so I missed it, but OK.
On review, it's also lacking detail. The use of the "%{dist}" option in .spec is a wonderful standardization, and of '%{?dist}" even more effective by the upstream vendor. It really helps allow developers to set it in their .rpmmacros and use the defaults when they run it through mock to build production versions, so I *assume* that your mock environments are not resetting this. Perhaps a mention that "we prefer to tweak it by editing the .spec files as necessary, and those modified .spec files are available at publicly accessible source Subversion mirror 'http://svnmirror.centos.org"..
Why do you keep talking about a SCM system. Everything you want to know is in the SRPMS. If you want to create a git repo of them, have at it. You like SVN better, use it. CVS your thing, use that. Look for .centos files and pull them in (that and the kernel is all we change).
I work with SRPMS, not with an SCM system. I like SRPMS, they are a SCM system of their own.
We do not change what upstream has in their SRPMS (except when we have to) ... we don't even unpack them unless we need to change them. We submit them to mock to build. Every patch we create, every change we make, it is in the SRPM.
Why is this so hard to understand?
If we were maintaining changes in 2500 SRPMS per distribution (times 3 or 4 distributions), we would do it in an SCM program, but since we just BUILD the vast majority of these packages without changes, maintaining an SCM of 10,000 packages when we change less than 1% of them does not make much sense.
You have the SRPMS, you have example config files, you have the mock that we use, you have the script that we build the software tree with, you have the file that we use to compare RPMs with upstream. Those are what we use.
I've really been hoping for public access to the build structure. "You can do it yourself" is not as helpful as the kind of public access to build structures that Dag publishes, and has been suggesting.
The build structure is NOT necessarily a public machine. The machines that get built on do not necessarily belong to CentOS. My company, for example, provides some resources that I build on. You can not have access to my company's internal network or their machines.
Dag changes SRPMS and source code ... we rebuild someone else's source code. That is why we don't maintain an SCM.
On Thu, Mar 10, 2011 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
Why do you keep talking about a SCM system. Everything you want to know is in the SRPMS. If you want to create a git repo of them, have at it. You like SVN better, use it. CVS your thing, use that. Look for .centos files and pull them in (that and the kernel is all we change).
I work with SRPMS, not with an SCM system. I like SRPMS, they are a SCM system of their own.
Because they're really not. Patches can be altered, and .spec files altered, without any logging or notification of the change. Release numbers and revision numbers are hard-coded, not trackable.
We do not change what upstream has in their SRPMS (except when we have to) ... we don't even unpack them unless we need to change them. We submit them to mock to build. Every patch we create, every change we make, it is in the SRPM.
That's..... a pretty odd approach. Not inconceivable, but *exactly* the sort of informaiton not in the "do it yourself, it's easy" approach.
Why is this so hard to understand?
Because it's amazingly poor software management. SRPM's are binaries and make change tracking quite awkward, and rely entirely on the developer to consistently report changes in the %changelog. That's..... really awkward.
If we were maintaining changes in 2500 SRPMS per distribution (times 3 or 4 distributions), we would do it in an SCM program, but since we just BUILD the vast majority of these packages without changes, maintaining an SCM of 10,000 packages when we change less than 1% of them does not make much sense.
No, no, you'd just SCM the ones you alter, and the build system (which needed design to provide a bootstrappable environment.)
You have the SRPMS, you have example config files, you have the mock that we use, you have the script that we build the software tree with, you have the file that we use to compare RPMs with upstream. Those are what we use.
I've really been hoping for public access to the build structure. "You can do it yourself" is not as helpful as the kind of public access to build structures that Dag publishes, and has been suggesting.
The build structure is NOT necessarily a public machine. The machines that get built on do not necessarily belong to CentOS. My company, for example, provides some resources that I build on. You can not have access to my company's internal network or their machines.
Excuse me, I didn't say it should be. But access to the /etc/mock files, *in the SCM I just described*, would be helpful.
Dag changes SRPMS and source code ... we rebuild someone else's source code. That is why we don't maintain an SCM.
But you do change them! By your own admission above, you've altered 100 packages. That's plenty to justify an SCM.
On 03/10/2011 07:55 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
Why do you keep talking about a SCM system. Everything you want to know is in the SRPMS. If you want to create a git repo of them, have at it. You like SVN better, use it. CVS your thing, use that. Look for .centos files and pull them in (that and the kernel is all we change).
I work with SRPMS, not with an SCM system. I like SRPMS, they are a SCM system of their own.
Because they're really not. Patches can be altered, and .spec files altered, without any logging or notification of the change. Release numbers and revision numbers are hard-coded, not trackable.
We do not change what upstream has in their SRPMS (except when we have to) ... we don't even unpack them unless we need to change them. We submit them to mock to build. Every patch we create, every change we make, it is in the SRPM.
That's..... a pretty odd approach. Not inconceivable, but *exactly* the sort of informaiton not in the "do it yourself, it's easy" approach.
Why is this so hard to understand?
Because it's amazingly poor software management. SRPM's are binaries and make change tracking quite awkward, and rely entirely on the developer to consistently report changes in the %changelog. That's..... really awkward.
It is not awkward at all and it does not require anything.
diff -uNrp <original>.spec <modified>.spec > spec.diff
diff -uNrp SOURCES.old SOURCES > sources.diff
Now you have everything.
People making the SRPM don't have to REPORT anything, you see it right there. The vast majority of our changes get rolled in over and over exactly as they are after the first time we create them. We are not making technical changes. PatchA just gets moved from the old one to the new one and reapplied, etc. The whole goal is NOT to change anything.
Red Hat does not give us an SCM to look at, yet we seem to be able to build the software.
If we were maintaining changes in 2500 SRPMS per distribution (times 3 or 4 distributions), we would do it in an SCM program, but since we just BUILD the vast majority of these packages without changes, maintaining an SCM of 10,000 packages when we change less than 1% of them does not make much sense.
No, no, you'd just SCM the ones you alter, and the build system (which needed design to provide a bootstrappable environment.)
We build software, we are not it the business of teaching you how to build software or producing a something that makes it so everyone can rebuild their own distribution. Our goal is not a reproducable system so YOU can build software, it is for US to produce software. If you are looking for a distribution that teaches YOU to build things, get Gentoo or Linux From Scratch.
You have the SRPMS, you have example config files, you have the mock that we use, you have the script that we build the software tree with, you have the file that we use to compare RPMs with upstream. Those are what we use.
I've really been hoping for public access to the build structure. "You can do it yourself" is not as helpful as the kind of public access to build structures that Dag publishes, and has been suggesting.
The build structure is NOT necessarily a public machine. The machines that get built on do not necessarily belong to CentOS. My company, for example, provides some resources that I build on. You can not have access to my company's internal network or their machines.
Excuse me, I didn't say it should be. But access to the /etc/mock files, *in the SCM I just described*, would be helpful.
The mock files are default and point to the default CentOS trees. I gave you an example mock file.
Dag changes SRPMS and source code ... we rebuild someone else's source code. That is why we don't maintain an SCM.
But you do change them! By your own admission above, you've altered 100 packages. That's plenty to justify an SCM.
People are already bitching that it TAKES TOO LONG to get the software and what you want to do is add more things to the process to make it easy for you to reproduce what we do. This conversation is about what makes it easier for you to rebuild the upstream sources and has nothing to do with what the purpose of the CentOS Project is. What you need to do is start your own project called "Enterprise Linux from Sources" and your goals need to be to design, maintain, and teach someone exactly how to rebuild the upstream sources ... those are not the goals of CentOS. It would be a good project, it is just not THIS project.
On Friday, March 11, 2011 03:47:55 am Johnny Hughes wrote:
What you need to do is start your own project called "Enterprise Linux from Sources" and your goals need to be to design, maintain, and teach someone exactly how to rebuild the upstream sources ... those are not the goals of CentOS. It would be a good project, it is just not THIS project.
While I'm quoting Johnny, this reply is for Nico, and the others who want an SCM in place.
There is just exactly this sort of system you seem to want, Nico; it's called koji, and it is the Fedora buildsystem. SL is also using koji. See if they will let you see their koji, and the SCM repository behind it, and a listing of the contents of the binary repository pulled in for the buildroots. If they will (or if they've already documented it), then you've got your information.
On Fri, Mar 11, 2011 at 3:47 AM, Johnny Hughes johnny@centos.org wrote:
On 03/10/2011 07:55 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
Why do you keep talking about a SCM system. Everything you want to know is in the SRPMS. If you want to create a git repo of them, have at it. You like SVN better, use it. CVS your thing, use that. Look for .centos files and pull them in (that and the kernel is all we change).
I work with SRPMS, not with an SCM system. I like SRPMS, they are a SCM system of their own.
Because they're really not. Patches can be altered, and .spec files altered, without any logging or notification of the change. Release numbers and revision numbers are hard-coded, not trackable.
We do not change what upstream has in their SRPMS (except when we have to) ... we don't even unpack them unless we need to change them. We submit them to mock to build. Every patch we create, every change we make, it is in the SRPM.
That's..... a pretty odd approach. Not inconceivable, but *exactly* the sort of informaiton not in the "do it yourself, it's easy" approach.
Why is this so hard to understand?
Because it's amazingly poor software management. SRPM's are binaries and make change tracking quite awkward, and rely entirely on the developer to consistently report changes in the %changelog. That's..... really awkward.
It is not awkward at all and it does not require anything.
diff -uNrp <original>.spec <modified>.spec > spec.diff
diff -uNrp SOURCES.old SOURCES > sources.diff
No, the extraction of the contents of the SRPM's into distinguishable directories is quite inefficient and has a great deal of unnecessary overlap. Normally, I would use "rpm -U foo.src.rpm" to extract the contents, but doing that with SRPM's can store files that have changed and overlap each other, such as README and init scripts.
I'm going to explain this one for the folks new to comparing SRPM's. For this case, you can use something like:
mkdir foo1 foo2 (cd foo1 && rpm2cpio ../foo1.src.rpm | cpio -id) (cd foo2 && rpm2cpio ../foo2.src.rpm | cpio -id) diff -u foo1/*.spec foo2/*.spec diff -ur foo1 foo2 --exclude=*.spec
This is workable, but when you start looking at the minor changes between releases, it gets awkward, and to check the history of the changes, you have to check the "* Changelog" in the .spec files. I don't know *anyone* else who does those manually on a big project, rather than pulling them from the source control logs.
Now you have everything.
*NOW* you have everything cleanly accessed and separated, but you don't have the logs of the requisite change, nor if changes go together as sets.
People making the SRPM don't have to REPORT anything, you see it right there. The vast majority of our changes get rolled in over and over exactly as they are after the first time we create them. We are not making technical changes. PatchA just gets moved from the old one to the new one and reapplied, etc. The whole goal is NOT to change anything.
But since you don't have source control, you don't actually know that except by manually going back and disassembling the SRPM's.
Red Hat does not give us an SCM to look at, yet we seem to be able to build the software.
Well, yes. But they're not inviting people into the OS building process, nor saying "where is all our help!!!????"
If we were maintaining changes in 2500 SRPMS per distribution (times 3 or 4 distributions), we would do it in an SCM program, but since we just BUILD the vast majority of these packages without changes, maintaining an SCM of 10,000 packages when we change less than 1% of them does not make much sense.
No, no, you'd just SCM the ones you alter, and the build system (which needed design to provide a bootstrappable environment.)
We build software, we are not it the business of teaching you how to build software or producing a something that makes it so everyone can rebuild their own distribution. Our goal is not a reproducable system so YOU can build software, it is for US to produce software. If you are looking for a distribution that teaches YOU to build things, get Gentoo or Linux From Scratch.
Johnny, I *teach* people how to build software in RPM structures, in source control, and to stabilize their build environments. CentOS has been a great teaching environment, it's partly why I work with it. But now you've got me nervous about what's going on upstream.
You have the SRPMS, you have example config files, you have the mock that we use, you have the script that we build the software tree with, you have the file that we use to compare RPMs with upstream. Those are what we use.
I've really been hoping for public access to the build structure. "You can do it yourself" is not as helpful as the kind of public access to build structures that Dag publishes, and has been suggesting.
The build structure is NOT necessarily a public machine. The machines that get built on do not necessarily belong to CentOS. My company, for example, provides some resources that I build on. You can not have access to my company's internal network or their machines.
Excuse me, I didn't say it should be. But access to the /etc/mock files, *in the SCM I just described*, would be helpful.
The mock files are default and point to the default CentOS trees. I gave you an example mock file.
Oh, dear. Now I see a problem.
Take a good look at the "extras" repository in the default "mock" setups. those point to the EPEL repository, and are enabled for the entire EPEL repository. This means that you may be introducing dependencies that have *nothing* to do with your primary or local codebase of CentOS. EPEL avoids overwriting RHEL dependencies, but that's not the same thing as introducing parallel components that would provide the same functionality and create separate dependency trees.
That's been a problem with centosplus, epel, and rpmforge when they have overlapping contents but differening dependencies. This way lies madness.
Dag changes SRPMS and source code ... we rebuild someone else's source code. That is why we don't maintain an SCM.
But you do change them! By your own admission above, you've altered 100 packages. That's plenty to justify an SCM.
People are already bitching that it TAKES TOO LONG to get the software and what you want to do is add more things to the process to make it easy for you to reproduce what we do. This conversation is about what
I want it easier to for us to help, to knock in 3 or four SRPM's when we can pry time free. As it is, we've got to devote days to build up our own bootstrapped binary repository, and trip over the same failures you guys are encountering, instead of being to use your fixes from in-house SRPM's that *you haven't published*, so I can't compare notes and avoid stepping on them.
makes it easier for you to rebuild the upstream sources and has nothing to do with what the purpose of the CentOS Project is. What you need to do is start your own project called "Enterprise Linux from Sources" and your goals need to be to design, maintain, and teach someone exactly how to rebuild the upstream sources ... those are not the goals of CentOS. It would be a good project, it is just not THIS project.
I don't have the physical resources in my home, and the start up costs would be ridiculous.
On Mar 11, 2011, at 2:19 PM, Nico Kadel-Garcia wrote:
No, the extraction of the contents of the SRPM's into distinguishable directories is quite inefficient and has a great deal of unnecessary overlap. Normally, I would use "rpm -U foo.src.rpm" to extract the contents, but doing that with SRPM's can store files that have changed and overlap each other, such as README and init scripts.
Um, not true. All depends on how you choose to configure RPM before unpacking, and how you go about building from SRPMS and otherwise setup a build system
You could ask how to do that someplace where you might get an informed answer, RPM and SRPM and VCS issues are entirely not gonna be solved on centos-devel.
I also have a 100 line #!/usr/bin/make -f script around that explodes SRPM's into a repository in ~1-2 hours.
About 1/3rd of the 100 lines is --help spewage.
73 de Jeff
On 03/10/2011 07:55 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 10, 2011 at 7:18 PM, Johnny Hughes johnny@centos.org wrote:
Why do you keep talking about a SCM system. Everything you want to know is in the SRPMS. If you want to create a git repo of them, have at it. You like SVN better, use it. CVS your thing, use that. Look for .centos files and pull them in (that and the kernel is all we change).
I work with SRPMS, not with an SCM system. I like SRPMS, they are a SCM system of their own.
Because they're really not. Patches can be altered, and .spec files altered, without any logging or notification of the change. Release numbers and revision numbers are hard-coded, not trackable.
We do not change what upstream has in their SRPMS (except when we have to) ... we don't even unpack them unless we need to change them. We submit them to mock to build. Every patch we create, every change we make, it is in the SRPM.
That's..... a pretty odd approach. Not inconceivable, but *exactly* the sort of informaiton not in the "do it yourself, it's easy" approach.
Why is this so hard to understand?
Because it's amazingly poor software management. SRPM's are binaries and make change tracking quite awkward, and rely entirely on the developer to consistently report changes in the %changelog. That's..... really awkward.
If we were maintaining changes in 2500 SRPMS per distribution (times 3 or 4 distributions), we would do it in an SCM program, but since we just BUILD the vast majority of these packages without changes, maintaining an SCM of 10,000 packages when we change less than 1% of them does not make much sense.
No, no, you'd just SCM the ones you alter, and the build system (which needed design to provide a bootstrappable environment.)
You have the SRPMS, you have example config files, you have the mock that we use, you have the script that we build the software tree with, you have the file that we use to compare RPMs with upstream. Those are what we use.
I've really been hoping for public access to the build structure. "You can do it yourself" is not as helpful as the kind of public access to build structures that Dag publishes, and has been suggesting.
The build structure is NOT necessarily a public machine. The machines that get built on do not necessarily belong to CentOS. My company, for example, provides some resources that I build on. You can not have access to my company's internal network or their machines.
Excuse me, I didn't say it should be. But access to the /etc/mock files, *in the SCM I just described*, would be helpful.
Dag changes SRPMS and source code ... we rebuild someone else's source code. That is why we don't maintain an SCM.
But you do change them! By your own admission above, you've altered 100 packages. That's plenty to justify an SCM.
Let me ask you another question about this magical SCM system that will make the world a better place.
Lets say I import the first upstream package into the SCM as package 1. Lets do httpd as it needs changes. I install it onto our system and it gets split into a SPEC and SOURCES directory.
Now, what items would you want to pull into this magical SCM ... just the text files or also their tarballs. Or would you untar/unzip the tarballs too. (Remember we NEVER change their tarballs). Lets leave the tarballs out for now. Lets just bring in their spec file and all the text. Lets change the spec the way we want it and commit that to the SCM. Now lets add in our patches and commit that to the SCM. So far this SCM is looking great. We can use it to see the 2 patches we added and it will do the diffs for us on spec file. So far so good. (You can get exactly the same info if you run the diff -uNrp on the SPEC directory and the SOURCES directory, but still it makes sense to do this at this point).
Now, upstream releases a new package ... what do you do? Lets import it into our SCM. Hmmm ... it overwrites the spec file and removes my changes ... that's OK, I can still see them from commit 1, so I will go back and grab them from there and reapply them into the new spec file. But now, that makes the versions complicated and bringing in the new spec shows me what upstream changed, but it does not show me anything more about my changes than the first one did. During the build process, I need to add another patch and specfile change and make a commit. Now, I have 4 changes to the spec file ... which ones are mine and which ones are upstream? After about 3 or 4 cycles it is all muddled. However, if I grab any version of the upstream package and the corresponding centos version of the package and diff the SPEC and SOURCES directory of those it tells me in an instant exactly what is different from upstream. So, for the SPECs it is MUCH easier to get the info you want to know (what did CentOS roll in on package x-y-z.1) by using SRPMS than by using SCM.
OK, lets look at the SOURCES directory. We brought it in and we committed, then we made our changes and committed ... everything is great. First update, we pull in their changes and now we can see everything they changed ... but our patches go in as expected, so no changes from us. The SCM works great to tell us what they changed, but we did not change anything. Lets say I do need to refactor one of our patches. I can see the difference it has but after several cycles is it very difficult to see what I really want to see, and that is how is my package different from the upstream one. I could care less that they modified the where a trademark is now as compared to where it was 3 versions ago ... all I need to know is where it is now so I can get rid of it. Remember, we are not making technical changes, JUST removing trademarks and branding. What we changed last time does not matter, all that matters is what we need to change this time.
The bottom line is, I can take any SRPM from upstream, take the same corresponding SRPM from CentOS, diff them and know what I need to change to build the next one. I can then figure out if I need to do anything to it when I apply the patches, etc. If I had an SCM, I would need to take a bunch of time just to figure out which changes I want to look at. (I need to look at diff between change 27 and change 38 to see what I changed in the spec file, and between change 18 and change 35 for the sources, etc.) Even worse, I might have made a change to the spec, committed it, then later on needed to make a second change to the spec. So, it becomes much harder to figure out which two changes to look at to see the things I want to see ... using the SRPMS, it is easy peasy to see exactly what i want to see.
I have tried to use an SCM for these changes ... for me, it does not work, it slows me down, and I do not think it adds value in the rebuild situation. SCMs are great if you are developing something from point A to Point B to Point C ... we are NOT doing that. We makes changes at Point A ... they roll in perfect at Point B, and Point C ... then at Point D, they need to be re-factored. The changes required to refactor are irrelevant to what was in Point A though Point C and only depend on Point D. The SRPMS themselves are BETTER tracking devices than an SCM.
On Fri, 2011-03-11 at 03:55 -0600, an unknown sender wrote:
Now, upstream releases a new package ... what do you do? Lets import it into our SCM. Hmmm ... it overwrites the spec file and removes my changes ... that's OK, I can still see them from commit 1, so I will go back and grab them from there and reapply them into the new spec file. But now, that makes the versions complicated and bringing in the new spec shows me what upstream changed, but it does not show me anything more about my changes than the first one did. During the build process, I need to add another patch and specfile change and make a commit. Now, I have 4 changes to the spec file ... which ones are mine and which ones are upstream? After about 3 or 4 cycles it is all muddled. However, if I grab any version of the upstream package and the corresponding centos version of the package and diff the SPEC and SOURCES directory of those it tells me in an instant exactly what is different from upstream. So, for the SPECs it is MUCH easier to get the info you want to know (what did CentOS roll in on package x-y-z.1) by using SRPMS than by using SCM.
Hi Johnny!
I don't want to get actively involved in this debate, particularly because my competences are somehow limited, however I thought it could be valuable for you to know that Debian and its derivatives have exactly the same problem.
To solve it, they authored a toolset that wraps around the package building facilities (pbuilder is the mock of Debian, debuild is equivalent to rpmbuild etc.) and different kinds of SCM.
There are several concurrently used sets of tools, for each SCM of choice, most notably git-buildpackage, hg-buildpackage, svn-buildpackage etc. The point here is to solve exactly the problem that you are discussing.
They automatically create tracking branches on top of upstream imports (upstream could be the original author of the program, or a packaged version of the program e.g. from Debian that is considered to be "upstream" by a derivative, i.e. Ubuntu) that let you re-base your older changes on top of newer upstream changes, tag the uploads you do to the archive, combine all patches in one pack of patches, concurrently work with several branches for different distributions (backports), auto-generate changelogs and much more. At the same time, the immutability of the original upstream tarballs is guaranteed by a tool called "pristine-tar" and validated by computing a hash.
That is to say, that this problem has been solved rather efficiently for Debian and allows for a very enjoyable packaging workflow using your favorite tools to manage the history.
It could be that there are similar efforts for RPM-based distributions, but I am not up to date with that. It's rather a proof of concept.
The SRPMS themselves are BETTER tracking devices than an SCM.
Provided a right set of tools, they are definitively not, as are not "source debs". It could be that these tools do not exist for RPM based distributions and if indeed they don't, CentOS might not be the right project to develop them, but just thought I would mention that.
To me this point is of an academic interest.
Yury, you have missed the point, as many before you.
CentOS has no interest in tracking SRPMS since the are **not** changing them. All they want to do is to repack them and comply with rules of repackaging them, which include de-branding them, etc... What you do not have to change, you do not need to track...
If upstream would be nice/stupid enough to solve all issues with properly solving dependencies, everybody could just run them through recompiling and there would be no need for all of this hassle.
Since upstream needs (more) time between their release and downstream rebuilds, in order to make better profit in the mean time, they have made problems harder for rebuilding crews.
For me, it's that simple. And I do not hold grudge on upstream, their choice makes them profitable enough to be able to invest in development of the product we use and pay not with our money but with our nerves. Those who cherish their nerves more then money will buy upstreams product, and the rest of our self will loose nerves and keep our money.
Ljubomir.
Yury V. Zaytsev wrote:
On Fri, 2011-03-11 at 03:55 -0600, an unknown sender wrote:
Now, upstream releases a new package ... what do you do? Lets import it into our SCM. Hmmm ... it overwrites the spec file and removes my changes ... that's OK, I can still see them from commit 1, so I will go back and grab them from there and reapply them into the new spec file. But now, that makes the versions complicated and bringing in the new spec shows me what upstream changed, but it does not show me anything more about my changes than the first one did. During the build process, I need to add another patch and specfile change and make a commit. Now, I have 4 changes to the spec file ... which ones are mine and which ones are upstream? After about 3 or 4 cycles it is all muddled. However, if I grab any version of the upstream package and the corresponding centos version of the package and diff the SPEC and SOURCES directory of those it tells me in an instant exactly what is different from upstream. So, for the SPECs it is MUCH easier to get the info you want to know (what did CentOS roll in on package x-y-z.1) by using SRPMS than by using SCM.
Hi Johnny!
I don't want to get actively involved in this debate, particularly because my competences are somehow limited, however I thought it could be valuable for you to know that Debian and its derivatives have exactly the same problem.
To solve it, they authored a toolset that wraps around the package building facilities (pbuilder is the mock of Debian, debuild is equivalent to rpmbuild etc.) and different kinds of SCM.
There are several concurrently used sets of tools, for each SCM of choice, most notably git-buildpackage, hg-buildpackage, svn-buildpackage etc. The point here is to solve exactly the problem that you are discussing.
They automatically create tracking branches on top of upstream imports (upstream could be the original author of the program, or a packaged version of the program e.g. from Debian that is considered to be "upstream" by a derivative, i.e. Ubuntu) that let you re-base your older changes on top of newer upstream changes, tag the uploads you do to the archive, combine all patches in one pack of patches, concurrently work with several branches for different distributions (backports), auto-generate changelogs and much more. At the same time, the immutability of the original upstream tarballs is guaranteed by a tool called "pristine-tar" and validated by computing a hash.
That is to say, that this problem has been solved rather efficiently for Debian and allows for a very enjoyable packaging workflow using your favorite tools to manage the history.
It could be that there are similar efforts for RPM-based distributions, but I am not up to date with that. It's rather a proof of concept.
The SRPMS themselves are BETTER tracking devices than an SCM.
Provided a right set of tools, they are definitively not, as are not "source debs". It could be that these tools do not exist for RPM based distributions and if indeed they don't, CentOS might not be the right project to develop them, but just thought I would mention that.
To me this point is of an academic interest.
Ljubomir,
On Wed, 2011-03-23 at 10:45 +0100, Ljubomir Ljubojevic wrote:
Yury, you have missed the point, as many before you.
I appreciate your answer, but unfortunately you were too quick to assume that I am the one that is missing the point here. I need no explanations of what and how CentOS does, as I am to a certain extent familiar with the goals and the process.
The tools I am relating to pertain especially to the production and maintenance of rebuilds and derivatives (where only a fraction of upstream packages is changed), and as Johnny was generally questioning the usefulness of SCM in these particular scenarios I though I would mention how other projects deal with similar problems.
This was an informational email primarily for Johnny, which I also decided to share with the list, since I've seen it before that developers involved in one particular flavor of distributions are often not up to date with alternative approaches from other distributions.
I tried to make the informational nature of my post clear. Please be more of an attentive reader in the future to keep this thread clean.
On Wed, Mar 23, 2011 at 5:45 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
Yury, you have missed the point, as many before you.
CentOS has no interest in tracking SRPMS since the are **not** changing them. All they want to do is to repack them and comply with rules of repackaging them, which include de-branding them, etc... What you do not have to change, you do not need to track...
Yes, they are! They're changing the artwork and the trademarks and some of the documentation. They have to for redistribution. They're not modifying the *binary* portions, but it absolutely requires changes, or we wouldn't have ".centos" named RPM's and SRPM's, and the "centos-release" package would not exist.
Keeping those changes well managed makes the work more replicable, and helps avoid precisely the "spurious dependency" issues that our helpful repackagers have reported elsewhere, and creeping library changes in the build environments.
If upstream would be nice/stupid enough to solve all issues with properly solving dependencies, everybody could just run them through recompiling and there would be no need for all of this hassle.
And if our helpful packagers would publish their build environment layouts in an SCM, we could replicate them and help. I'd love to help, and have asked before for such access.
The point earlier that diffs cannot be tracked if you do this is, I think, an understandable but misplaced concern. Here's how you do it.
* Set up a canonical repository with the mirrored SRPM's from upstream. * Set permissions to "add" only. * Extract the contents of those into a repository with subdirectories for each package. * Set permissions to "add" only. * Set up a third repository. * Copy, or import, the contents of the second repository to the third. * Edit, or modify only in this third repository. * Branch as necessary. * Replicate as necessary for binary RPM's.
This provides direct access to replicate materials for development, to compare differences, and to provide access for others through an SCM, to the changes and change history of the packages and source that *must* be modified for a rebuild.
There are details that are sensitive to the particular source control system used. Subversion, for exemple, cannot gracefully handle comparisons between two distinct repositories, and would work better with subdirectories in one repository. Git would be better at allowing our contributors to make and record local changes without direct write access to the central repo, and is better in security terms. But those are details. The structure works, and I've used it to help companies commit changes against externally provided vendor source trees with source control.
Since upstream needs (more) time between their release and downstream rebuilds, in order to make better profit in the mean time, they have made problems harder for rebuilding crews.
This is a conflated view of several recent issues. I think. Red Hat has a long and *VERY* good history of publishing such requirements. There have been what look like some accidental spurious dependencies, which they're resolving. (SuSE used to do that deliberately, don't know if they still do with their kernels.)
There is the kernel tarball issue. That's understandable, but real. Red Hat is publishing their kernels as tarballs, rather than as the vanilla tarball with a list of ordered patches against it. This makes layering in, or out, specific patches much more awkward. Was Oracle being any better about this? Does anyone have actual pointers to their SRPM's?
For me, it's that simple. And I do not hold grudge on upstream, their choice makes them profitable enough to be able to invest in development of the product we use and pay not with our money but with our nerves. Those who cherish their nerves more then money will buy upstreams product, and the rest of our self will loose nerves and keep our money.
Ljubomir.
On Thu, Mar 10, 2011 at 6:18 PM, Johnny Hughes johnny@centos.org wrote
We do not change what upstream has in their SRPMS (except when we have to) ... we don't even unpack them unless we need to change them. We submit them to mock to build. Every patch we create, every change we make, it is in the SRPM.
Why is this so hard to understand?
What are the differences (if any) between the build procedures documented by Scientific Linux at the url below? https://www.scientificlinux.org/distributions/6x/build/problembyrpm
Would Scientific Linux also be 100% binary compatible with upstream, or are there other procedures followed by Centos to achieve the binary compatibility goal?
On 03/10/2011 08:30 PM, Trent Johnson wrote:
On Thu, Mar 10, 2011 at 6:18 PM, Johnny Hughes johnny@centos.org wrote
We do not change what upstream has in their SRPMS (except when we have to) ... we don't even unpack them unless we need to change them. We submit them to mock to build. Every patch we create, every change we make, it is in the SRPM.
Why is this so hard to understand?
What are the differences (if any) between the build procedures documented by Scientific Linux at the url below? https://www.scientificlinux.org/distributions/6x/build/problembyrpm
The do not document a build process at that page, so I don't know. That page is the packages that they currently have problems with on their rebuild of EL6.
They do document some of the actions that they used to get some of the things to build. Some of those actions may or may not produce differences between the upstream binaries and those files produced. In order to know that, I would need to grab all their RPMs and run compares against the upstream RPMs, then analyze it. That takes long enough to do when I do it to CentOS, so I have not done it for theirs. If I have something I can't get to build, I will grab their SRPM and RPM and diff their SRPM with the one from upstream to see what they did to it. I will also compare their RPMs to ours and/or upstream's to see if they are linked correctly.
Would Scientific Linux also be 100% binary compatible with upstream, or are there other procedures followed by Centos to achieve the binary compatibility goal?
I don't know their procedures, but I can show you 2 packages in 5.6 on the CERN build where there is a problem right now ... because I looked at their RPMS yesterday to solve our problem. (Their RPMs and SRPMS did not help me, they had the same issue as ours).
Here is the output of an issue in both libtevent and certmonger that is in the current CERN build:
Differing package requirements: --- work/SL-req 2011-03-09 07:35:12.000000000 -0500 +++ work/RHEL-req 2011-03-09 07:35:12.000000000 -0500 @@ -41,7 +41,7 @@ libpthread.so.0(GLIBC_2.0) libsmime3.so libssl3.so -libtalloc.so.1 +libtalloc.so.2 libtevent.so.0 libxmlrpc.so.3 libxmlrpc_client.so.3
What does this mean, it means that the libtevent package and the certmonger package are linked against and use libtalloc-1.2.x and not libtalloc-2.0.x. Does this mean their packages for libtevent and certmonger will not work? Not really, they might work fine. They are not, however, binary compatible with upstream.
How many other packages are like that ... I have no idea as I have not tested all their packages. I only test our packages. Do they test their packages for this? I don't know. Getting a package to build and getting to be binary compatible are not the same thing.
On 3/11/2011 3:14 AM, Johnny Hughes wrote:
-libtalloc.so.1 +libtalloc.so.2
What does this mean, it means that the libtevent package and the certmonger package are linked against and use libtalloc-1.2.x and not libtalloc-2.0.x.
So what's the next step here? Is this just a build order issue or do you have to find a libtalloc-2.0.x binary that isn't created by any RHEL SRPM? And if you have the binary to test against, couldn't some automated procedure have predicted this before you took the time to build the version that fails your test?
[While this message is fairly long, I did take the time to cut it down some from its original form, which was over 200 lines longer than the current form. I'm sure glad I took touch-typing in school where they still used manual Remington-Rand typewriters....]
[Also, I had this in the last paragraph, but decided to top-post this piece: While those building C6 haven't given 'scheduled' updates, I want to thank them for the updates they have provided in reply to questions in these threads on these subjects, and for there continued work on the builds. ]
On Thursday, March 10, 2011 09:30:27 pm Trent Johnson wrote:
What are the differences (if any) between the build procedures documented by Scientific Linux at the url below? https://www.scientificlinux.org/distributions/6x/build/problembyrpm
SL uses koji, except in those cases where the koji environment's mock produces the wrong result (as documented in that page above for the perl-Sys-Virt package, just picking the first one that wouldn't build at all in koji). The SL started the koji 'adventure' way back in June, according to the SL archives, so it hasn't been a quick process for them, either. CentOS does not use koji as documented on this list a while back.
In my investigation of doing my own rebuild, I looked at koji. Koji does a fantastic job of managing a full distribution build where there are lots of contributors who are actually developing source RPM packaging; that was, after all, its design goal for the Fedora project. Koji is overkill for doing a rebuild from someone else's source RPM repo where you are only maintaining a relative handful of the full package set, and where you are building from SRPM rather than out of an SCM (koji uses an SCM on the backend, and rebuilding out of SRPM isn't by default allowed except for koji admins).
Even then it's not a magic bullet for rebuilding from a set of distributed source RPMs, as the contents of the binary RPM repository koji uses to populate the mock buildroots is still not known (I'm talking about upstream's binaries and buildroots); that information is not public (again, from the upstream vendor, not CentOS). What is known is that the buildroot-populating repository is a mix of packages from various sources; some might channel Frank Herbert and say a melange of sources. And the building dependencies documented in the source RPMs do not tell the full story in terms of the whole distribution.
Since the full CentOS package set has not yet successfully met the stringent binary compatibility tests that CentOS uses, I would say the full solution to the buildroot-populating binary repo is not yet known by CentOS, and thus can't yet be documented (it's just a smack difficult to document something you don't know yet).
And since SL is built using koji, their results don't necessarily translate directly to a non-koji-fied mock builder, and while the page you linked is useful information as a starting point, there are multitudes of details, especially once you get down to just a small number of packages left to successfully build and pass binary verification.
And, to throw another wrinkle, upstream may not have gone GA with a completely consistent package set; that is, where all packages in the package set shared exactly the same buildroot repository, and the distribution includes all packages in the correct versions to rebuild itself; this is known as 'self-hosting.'
We do know that 'self hosting' is not one of upstream's public goals, and, for that matter, never has been to the best of my knowledge (which is rather incomplete). It is a Fedora goal (and is periodically tested), but upstream EL is really just loosely pulled from a running snapshot of some Fedora packages across a relatively wide timeline.... and thus there isn't really a rawhide snapshot at any single point in time that completely corresponds to the buildroot-populating binary package repository used by mock, whether in koji or outside of koji, to do the builds.
Many links to many pieces of information have been posted; grep the archives. Enough information has been posted that anyone here with the requisite experience in package building could bootstrap, using the last known upstream beta binaries, and do their own rebuild of EL6, given the time required to do the work across the full package set. You might get it done very quickly; but part of the draw of CentOS is the strict binary-linkage-and-requires-and-provides bug-for-bug compatibility, and that is what takes a lot of time to do.
I find it rather interesting that the buildsystem under mock does have an effect when (re)building EL6; the newer version of rpm has to be present on the buildhost for xz compression, for one. So mock isn't total build isolation, unfortunately. Its isolation is very good, though, for the actual compilation of package sources; but mock has to use the buildhost's toolchain to actually put together the resulting binary packages, thus a newer RPM than C5's is required, as stated by Johnny upthread. This is a change from previous information.
On 03/11/2011 05:28 AM, Lamar Owen wrote:
[While this message is fairly long, I did take the time to cut it down some from its original form, which was over 200 lines longer than the current form. I'm sure glad I took touch-typing in school where they still used manual Remington-Rand typewriters....]
[Also, I had this in the last paragraph, but decided to top-post this piece: While those building C6 haven't given 'scheduled' updates, I want to thank them for the updates they have provided in reply to questions in these threads on these subjects, and for there continued work on the builds. ]
On Thursday, March 10, 2011 09:30:27 pm Trent Johnson wrote:
What are the differences (if any) between the build procedures documented by Scientific Linux at the url below? https://www.scientificlinux.org/distributions/6x/build/problembyrpm
SL uses koji, except in those cases where the koji environment's mock produces the wrong result (as documented in that page above for the perl-Sys-Virt package, just picking the first one that wouldn't build at all in koji). The SL started the koji 'adventure' way back in June, according to the SL archives, so it hasn't been a quick process for them, either. CentOS does not use koji as documented on this list a while back.
In my investigation of doing my own rebuild, I looked at koji. Koji does a fantastic job of managing a full distribution build where there are lots of contributors who are actually developing source RPM packaging; that was, after all, its design goal for the Fedora project. Koji is overkill for doing a rebuild from someone else's source RPM repo where you are only maintaining a relative handful of the full package set, and where you are building from SRPM rather than out of an SCM (koji uses an SCM on the backend, and rebuilding out of SRPM isn't by default allowed except for koji admins).
Exactly ... koji is a wonderful thing for "maintaining 100,000 packages from source" ... it is NOT so great for building someone else's SRPMS where you are not maintaining the sources (though as you say, koji admins can push SRPMS in). We are not using koji because of this reason. I have set up a koji system, built some packages in it and we have decided that it is not what we want to use.
But regardless of whether you are using koji, plague, or just manually building via mock, it is mock that does the heavy lifting.
Even then it's not a magic bullet for rebuilding from a set of distributed source RPMs, as the contents of the binary RPM repository koji uses to populate the mock buildroots is still not known (I'm talking about upstream's binaries and buildroots); that information is not public (again, from the upstream vendor, not CentOS). What is known is that the buildroot-populating repository is a mix of packages from various sources; some might channel Frank Herbert and say a melange of sources. And the building dependencies documented in the source RPMs do not tell the full story in terms of the whole distribution.
And since we have not completed the "check binaries" phase yet, we do not know the exact iteration of what packages we need as our "binary repos" yet. We have available to use the RHEL6B2 and Fedora 12 binaries, and the CentOS 6 binaries that we have already built as a staged repo to choose from.
Since the full CentOS package set has not yet successfully met the stringent binary compatibility tests that CentOS uses, I would say the full solution to the buildroot-populating binary repo is not yet known by CentOS, and thus can't yet be documented (it's just a smack difficult to document something you don't know yet).
This is also exactly correct ... we do not yet have the full build, so we are not sure exactly what it takes and we have certainly not tried to rebuild it on itself.
And since SL is built using koji, their results don't necessarily translate directly to a non-koji-fied mock builder, and while the page you linked is useful information as a starting point, there are multitudes of details, especially once you get down to just a small number of packages left to successfully build and pass binary verification.
And, to throw another wrinkle, upstream may not have gone GA with a completely consistent package set; that is, where all packages in the package set shared exactly the same buildroot repository, and the distribution includes all packages in the correct versions to rebuild itself; this is known as 'self-hosting.'
We do know that 'self hosting' is not one of upstream's public goals, and, for that matter, never has been to the best of my knowledge (which is rather incomplete). It is a Fedora goal (and is periodically tested), but upstream EL is really just loosely pulled from a running snapshot of some Fedora packages across a relatively wide timeline.... and thus there isn't really a rawhide snapshot at any single point in time that completely corresponds to the buildroot-populating binary package repository used by mock, whether in koji or outside of koji, to do the builds.
And this version (EL6) is less "complete" than most because it is much harder to get all the upstream RPMS for testing, etc. There is an "optional tree" that does not seem to be available on any ISOs, but that is part of the upstream distribution. This total change in the way upstream distributes their packages (many items in the distro, but not on the ISO media) is something else we are going to need to wrap our hands around ... especially for doing comparisons.
Many links to many pieces of information have been posted; grep the archives. Enough information has been posted that anyone here with the requisite experience in package building could bootstrap, using the last known upstream beta binaries, and do their own rebuild of EL6, given the time required to do the work across the full package set. You might get it done very quickly; but part of the draw of CentOS is the strict binary-linkage-and-requires-and-provides bug-for-bug compatibility, and that is what takes a lot of time to do.
I find it rather interesting that the buildsystem under mock does have an effect when (re)building EL6; the newer version of rpm has to be present on the buildhost for xz compression, for one. So mock isn't total build isolation, unfortunately. Its isolation is very good, though, for the actual compilation of package sources; but mock has to use the buildhost's toolchain to actually put together the resulting binary packages, thus a newer RPM than C5's is required, as stated by Johnny upthread. This is a change from previous information.
Right, one would have to either roll in a newer version of RPM into the build host (that can handle the xz compression of the SRPMS) ... or you can write a script to rebuild the SRPMS without xz compression (an equally valid approach that has also been used by us). You would just need to do this to set them up to build on c5:
rpm -Uvh --nomd5 $SRPMS; rpm -bs <path_to_specfile>/<name>.spec
Another approach is to build on RHEL6B2 or Fedora 12, or RHEL6 proper if you want to do that.
Regardless of the approach, the SRPMS and RPMS from within the build root (not the buildhost OS) will have xz compression.
We will also rebuild the packages again on CentOS6 when it is available and those will be the packages we release.
We will continue to build CentOS-4 and CentOS-5 packages on a CentOS-5 buildhost machine and CentOS-6 will be built on a CentOS-6 buildhost machine (once CentOS-6 is done).
Zenon Panoussis wrote:
On 03/10/2011 11:04 AM, Karanbir Singh wrote:
The complexity of this stuff is beyond what you are able to parse.
Could you please elaborate?
I don't mean here in reply to this posting. I mean it long-term, in the bug tracker and also in a publicly accessible git repo of patches and quirks. As things are now, the dev team has a huge amount of knowledge on how CentOS is made, but very little of it trickles outside the core team.
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it, learn from it, improve upon it, and also contribute back? Would you care to share your scripts and other wheels, so others won't have to re-invent them?
He already said he will document the process once 6.0 is released. read his mail on this list from 02/23/2011 11:59 AM.
On 03/10/2011 02:53 PM, Zenon Panoussis wrote:
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it, learn from it, improve upon it, and also contribute back? Would you care to share your scripts and other wheels, so others won't have to re-invent them?
This is the bit that is most frustrating. You clearly didnt bother really checking your facts or what you are talking about before going off and sending an email.
When c6 started off, there was a call for people to get involved - there were no scripts, there was nothing to share - the idea was that people would help build the bits. So your assumption that there are things were not sharing are bogus.
- KB
On 03/10/2011 05:14 PM, Karanbir Singh wrote:
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it, learn from it, improve upon it, and also contribute back? Would you care to share your scripts and other wheels, so others won't have to re-invent them?
When c6 started off, there was a call for people to get involved - there were no scripts, there was nothing to share - the idea was that people would help build the bits. So your assumption that there are things were not sharing are bogus.
I'm not talking about 6.0 or any release in particular; I am talking about CentOS.
So what about 5.x? Is there any list of packages needed de-branding? Any notes about hidden dependencies? Is there anything at all on 5.x that you could share with us? Or on 4.x for that matter?
Z
On 03/10/2011 04:49 PM, Zenon Panoussis wrote:
I'm not talking about 6.0 or any release in particular; I am talking about CentOS.
I dont understand what that means, we have an opportunity to do things in a different way, but you think its not relevant ?
So what about 5.x? Is there any list of packages needed de-branding? Any notes about hidden dependencies? Is there anything at all on 5.x that you could share with us? Or on 4.x for that matter?
not really, mirror.c.o has everything you need for 4.x and 5.x
- KB
On 03/10/2011 10:49 AM, Zenon Panoussis wrote:
On 03/10/2011 05:14 PM, Karanbir Singh wrote:
So, what I'm saying essentially is this: would you care to make the de-branding and building process fully open, so that others can copy it, learn from it, improve upon it, and also contribute back? Would you care to share your scripts and other wheels, so others won't have to re-invent them?
When c6 started off, there was a call for people to get involved - there were no scripts, there was nothing to share - the idea was that people would help build the bits. So your assumption that there are things were not sharing are bogus.
I'm not talking about 6.0 or any release in particular; I am talking about CentOS.
So what about 5.x? Is there any list of packages needed de-branding? Any notes about hidden dependencies? Is there anything at all on 5.x that you could share with us? Or on 4.x for that matter?
Every file changed in debranding is in the release notes and has a .centos in the name.
Do an 'ls *centos*' and you will know.
I already published a list of all the build root changes, in a reply to you 5 minutes ago.
But, that list is outdated as soon as we release new packages because they fix things.
An example is the issue we were having today with util-linux on the 5.6 build. Here is the scenario. The QA team did a compare on util-linux with the upstream RPM and it failed, so we need to rebuild it. I submitted it for rebuild and it failed to build. Another member of the QA team finds this:
https://bugzilla.redhat.com/show_bug.cgi?id=677452
So, I have 2 choices, I build it with the old gettext or I modify the SRPM and add the new patch from the bugzilla. Since we have a no change policy, I built util-linux against a 5.5 tree with all the updates.
We will likely not need to build util-linux again until they make the change that fixes this issue.
If I listed this on the wiki, I would also have to remember to change it when it is no longer applicable. It is already listed on the RHEL bugzilla site, so if I search for it there the next time I have the problem (if there ever is a next time) it will still be there.
On 03/10/2011 06:07 PM, Johnny Hughes wrote:
An example is the issue we were having today with util-linux on the 5.6 build.
That's *precisely* the kind of thing that I'm talking about. Narrow stuff which, exactly as you point out, will probably never be relevant again in the future, but would still be very useful to anyone working on the current release.
I'll give you one back:
https://bugzilla.redhat.com/show_bug.cgi?id=683102
Too impatient to wait for CentOS 6, I installed a trial version of RHEL 6 on my workstation thinking that CentOS would be out anyway by the time I need updates. But it wasn't. And there are some critical ones out. And my trial subscription has long expired. So there's only one way to deal with this: respinning from source. I've been doing that in the past couple of days, either repeating work that you have already done or preceding it without any benefit to you. That's where this discussion comes from.
If I listed this on the wiki, I would also have to remember to change it when it is no longer applicable. It is already listed on the RHEL bugzilla site, so if I search for it there the next time I have the problem (if there ever is a next time) it will still be there.
Having it all in one place makes collaboration much easier. It allows me to profit from your work and you to profit from mine and that of others. For example, the bug above is totally trivial, but in my build it was triggered just after I went to bed, wasting a night and a day of the machine idling instead of compiling. If you know about it, it might save you and everybody else an extra day of waiting. That's what the benefit of an open build process would be.
Z
On Thursday, March 10, 2011 01:00:14 pm Zenon Panoussis wrote:
Having it all in one place makes collaboration much easier. It allows me to profit from your work and you to profit from mine and that of others.
Someone has to take time to do that; are you volunteering to gather all that information up and post it on the wiki?
On 03/10/2011 08:25 PM, Lamar Owen wrote:
Having it all in one place makes collaboration much easier. It allows me to profit from your work and you to profit from mine and that of others.
Someone has to take time to do that; are you volunteering to gather all that information up and post it on the wiki?
I was talking about collaboration, as you correctly quoted above.
So I volunteer to put what I know on the wiki. That's the whole idea of a wiki, that everyone contributes to it; not that one person writes it.
Z
On 03/09/2011 10:00 PM, Jerry Amundson wrote:
On Wed, Mar 9, 2011 at 11:46 AM, Karanbir Singh mail-lists@karan.org wrote:
On 03/09/2011 05:47 PM, Ljubomir Ljubojevic wrote:
Can you comment on CentOS 6.0 status? Is it still 2-3 weeks from now or was there any progress that will shorten this period?
2 - 3 weeks from GA release of 5.6 is still a good time line to plan against.
If the response to a question regarding "CentOS 6.0 status" only relates to "GA release of 5.6", then, in spite of the constant responses to the contrary, there is a discrepancy between "what is expected from CentOS", and "what is delivered by CentOS". Period. End of story. Own up to it. Fix it.
Take you expectations and your condescending attitude someplace else.
You get a free operating system that is enterprise grade when we provide it for you.
If you don't like it, don't use it.
If you want a service level agreement with guaranteed deliverables, buy one.
-----Original message----- To: centos-devel@centos.org; From: Johnny Hughes johnny@centos.org Sent: Thu 10-03-2011 21:29 Subject: Re: [CentOS-devel] Updates from today Attachment: signature.asc
On 03/09/2011 10:00 PM, Jerry Amundson wrote:
On Wed, Mar 9, 2011 at 11:46 AM, Karanbir Singh mail-lists@karan.org wrote:
On 03/09/2011 05:47 PM, Ljubomir Ljubojevic wrote:
Can you comment on CentOS 6.0 status? Is it still 2-3 weeks from now or was there any progress that will shorten this period?
2 - 3 weeks from GA release of 5.6 is still a good time line to plan against.
If the response to a question regarding "CentOS 6.0 status" only relates to "GA release of 5.6", then, in spite of the constant responses to the contrary, there is a discrepancy between "what is expected from CentOS", and "what is delivered by CentOS". Period. End of story. Own up to it. Fix it.
Take you expectations and your condescending attitude someplace else.
You get a free operating system that is enterprise grade when we provide it for you.
If you don't like it, don't use it.
If you want a service level agreement with guaranteed deliverables, buy one.
Enough of this slanging match! The professionalism of this list has gone right down the tubes!
Please take the 'Ce' out and make it ntOS. It has nothing to do with Community or Enterprise.
I have decided to take all my servers to Scientific Linux forthwith. I will not touch CentOS with a bargepole from now on.
Goodbye Bill
On Thu, Mar 10, 2011 at 10:54:21PM +1100, Bill Maidment wrote:
Enough of this slanging match! The professionalism of this list has gone right down the tubes!
Actually I thought Johnny's response was the epitome of professionalism considering the invective of the response he was replying to.
And he's right. If you don't like it you are not forced to continue using the product. The original poster seems to feel that he is owed something which he is not. People are free to believe what they wish, of course, but the reality of the situation might very well be something completely at odds with their mistaken beliefs.
Please take the 'Ce' out and make it ntOS. It has nothing to do with Community or Enterprise.
Get real. It's a full baked, 100% binary, API and ABI compliant rebuild of the upstream vendor's enterprise linux product. Said product, I might add, being the most popular and well entrenched commercial enterprise linux product in the world. If you, somehow, take that to mean that CentOS isn't an enterprise grade distribution then you are, I must say, quite deluded.
I have decided to take all my servers to Scientific Linux forthwith.
Excellent. May you find happiness and peace there.
I will not touch CentOS with a bargepole from now on.
Wow. You've access to a bargepole? Neat beans.
Goodbye
*wave*
John
On 3/10/2011 5:54 AM, Bill Maidment wrote:
If the response to a question regarding "CentOS 6.0 status" only relates to "GA release of 5.6", then, in spite of the constant responses to the contrary, there is a discrepancy between "what is expected from CentOS", and "what is delivered by CentOS". Period. End of story. Own up to it. Fix it.
Take you expectations and your condescending attitude someplace else.
You get a free operating system that is enterprise grade when we provide it for you.
If you don't like it, don't use it.
If you want a service level agreement with guaranteed deliverables, buy one.
Enough of this slanging match! The professionalism of this list has gone right down the tubes!
Please take the 'Ce' out and make it ntOS. It has nothing to do with Community or Enterprise.
I have decided to take all my servers to Scientific Linux forthwith. I will not touch CentOS with a bargepole from now on.
Goodbye Bill
</lurk> <rant> Get over yourself. Your migration to another OS just because you don't like to see childish non-contributors bash the hard working volunteers isn't something that needs to be posted to the development list.
This rant really doesn't belong here either but I hope that people will still take a deep breath, calm down for a second, and consider the amount of hard work that all the real devs put in. Having to listen to all of the whiners criticizing their work over and over again *when they have already released all of that information*, I can understand why Johnny would respond that way - and I don't blame him! I respond exactly the same way then 20th time I've been asked the same question when I've answered it every time.
Have you ever had a small child pester you while you're trying to cook dinner? Answer "are we there yet" every 5 minutes on a six hour drive? That's what you people are doing to the devs!
There is no secret sauce. The scripts have been publicly released. The build process has been described in enough detail that anybody capable of doing it should be able to do it with the information that has been posted to this list and the CentOS Wiki. Karanbir has already committed to more documentation once v6 is out the door.
Knock it off, get over yourselves, have some patience, and stop posting to this list if you don't have anything positive to contribute. </rant> <lurk>
On Wed, Mar 9, 2011 at 11:44 AM, Karanbir Singh mail-lists@karan.org wrote:
On 03/07/2011 10:48 PM, Karanbir Singh wrote:
and have the tree's over into QA. Once that is done, the updates can churn though.
Just a quick update to this, updates now churning. The last bits of 5.6 fell into place over the course of the last 24 hrs.
- KB
Woo-hoo!!!!!!
On 3/9/2011 11:44 AM, Karanbir Singh wrote:
On 03/07/2011 10:48 PM, Karanbir Singh wrote:
and have the tree's over into QA. Once that is done, the updates can churn though.
Just a quick update to this, updates now churning. The last bits of 5.6 fell into place over the course of the last 24 hrs.
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
How about the updates that came out after 5.6 was released. Are you going to roll those into the 5.6 tree directly or put out those updates immediately after you roll out 5.6?
On 03/09/2011 10:15 PM, William Warren wrote:
On 3/9/2011 11:44 AM, Karanbir Singh wrote:
On 03/07/2011 10:48 PM, Karanbir Singh wrote:
and have the tree's over into QA. Once that is done, the updates can churn though.
Just a quick update to this, updates now churning. The last bits of 5.6 fell into place over the course of the last 24 hrs.
How about the updates that came out after 5.6 was released. Are you going to roll those into the 5.6 tree directly or put out those updates immediately after you roll out 5.6?
We will always produce the OS tree to be an exact copy of our released media, with everything else in updates.
Our media needs to be the exact same versions of programs as the upstream media to allow for 3rd party drivers to work properly at installation time.
So, the answer is that versions newer than those on the upstream installation media for a given point release will always be placed in updates.
Hi,
On 03/10/2011 04:15 AM, William Warren wrote:
How about the updates that came out after 5.6 was released. Are you going to roll those into the 5.6 tree directly or put out those updates immediately after you roll out 5.6?
The base [os] will remain intact, so the updates post 5.6 will go into the 5.6/updates/ repo's. If you want to install with the updates, you can always setup-networking, add the updates repo to the installer.
- KB
On 3/10/2011 5:05 AM, Karanbir Singh wrote:
Hi,
On 03/10/2011 04:15 AM, William Warren wrote:
How about the updates that came out after 5.6 was released. Are you going to roll those into the 5.6 tree directly or put out those updates immediately after you roll out 5.6?
The base [os] will remain intact, so the updates post 5.6 will go into the 5.6/updates/ repo's. If you want to install with the updates, you can always setup-networking, add the updates repo to the installer.
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Kewlies..that works fine. so i'll update to 5.6 then run another update to get current..:) Nice deal..:)
On 03/10/2011 08:00 PM, William Warren wrote:
Kewlies..that works fine. so i'll update to 5.6 then run another update to get current..:) Nice deal..:)
If you are already running CentOS 5.x, you should just be able to yum update and you'll be fully current. No need to even run it twice. That's assuming that post-5.6 updates are also dropped around the same time as the 5.6 main release.
On 3/11/2011 11:37 AM, David Hollis wrote:
On 03/10/2011 08:00 PM, William Warren wrote:
Kewlies..that works fine. so i'll update to 5.6 then run another update to get current..:) Nice deal..:)
If you are already running CentOS 5.x, you should just be able to yum update and you'll be fully current. No need to even run it twice. That's assuming that post-5.6 updates are also dropped around the same time as the 5.6 main release. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Unless i misread 5.6 is first then 5.6 updates are coming second hence the two yum runs.
On Mar 11, 2011, at 11:37 AM, David Hollis wrote:
If you are already running CentOS 5.x, you should just be able to yum update and you'll be fully current. No need to even run it twice. That's assuming that post-5.6 updates are also dropped around the same time as the 5.6 main release.
If the rpm version has been bumped, and/or if yum has been updated, it's sometimes a really good idea to 'yum upgrade rpm' and/or 'yum upgrade yum' first, then do the others. I typically do that, but I seem to remember getting burned by some upgrade of rpm years ago that got that put on my 'do this when a significant update comes along' list. It's right under the 'perform a clone/snapshot' line item (since virtually all of my servers are, uh, virtualized (sorry, couldn't resist), VMware snapshots are easy, pretty fast, and wonderful when things break bad).
On Friday 11 March 2011 12:52, Lamar Owen wrote:
On Mar 11, 2011, at 11:37 AM, David Hollis wrote:
If you are already running CentOS 5.x, you should just be able to yum update and you'll be fully current. No need to even run it twice. That's assuming that post-5.6 updates are also dropped around the same time as the 5.6 main release.
If the rpm version has been bumped, and/or if yum has been updated, it's sometimes a really good idea to 'yum upgrade rpm' and/or 'yum upgrade yum' first, then do the others. I typically do that, but I seem to remember getting burned by some upgrade of rpm years ago that got that put on my 'do this when a significant update comes along' list. It's right under the 'perform a clone/snapshot' line item (since virtually all of my servers are, uh, virtualized (sorry, couldn't resist), VMware snapshots are easy, pretty fast, and wonderful when things break bad).
The procedure I usually follow:
yum upgrade glibc* yum upgrade yum* rpm* python* yum clean metadata yum upgrade
On Friday, March 11, 2011 01:18:07 pm Dee Holtsclaw wrote:
yum upgrade glibc* yum upgrade yum* rpm* python* yum clean metadata yum upgrade
Reasonable sequence to follow, that's for sure. I don't recall getting burned by a glibc update recently (and I don't run VMware Server.... so that one didn't bug me), but there's always a first time.
-
Akemi Yagi -
Andreas Rogge -
Bill Maidment -
Dag Wieers -
David Brian Chait -
David Hollis -
David Hrbáč -
Dee Holtsclaw -
James Hogarth -
Jeff Johnson -
Jerry Amundson -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Matthew Miller -
Morten P.D. Stevens -
Ned Slider -
Nick Bright -
Nico Kadel-Garcia -
Paulo Martinez -
R P Herrold -
Thomas Bendler -
Trent Johnson -
William Warren -
Yury V. Zaytsev -
Zenon Panoussis