Any updates on progress, either on 5.6 or 6.0?
Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu URL: http://furo.astro.umd.edu/
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
In short: - There is about 2-3 weeks more before 6 is released. - CentOS 5.6 should be available for download any day now.
William L. Sebok wrote:
Any updates on progress, either on 5.6 or 6.0?
Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy Internet: wls@astro.umd.edu URL: http://furo.astro.umd.edu/ _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
On Wed, 16 Feb 2011, Matthew Miller wrote:
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
One is not expected to criticize on this list. All is well. Don't ask any uncomfortable questions please ! It's normal for a RHEL rebuild to be months behind the original. It has never been different for years. Either shut up or pay for the real thing. The developers are doing the best they can. Again all is well. Don't believe the non-believers.
On 02/17/2011 06:03 AM, Dag Wieers wrote:
On Wed, 16 Feb 2011, Matthew Miller wrote:
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
One is not expected to criticize on this list. All is well. Don't ask any uncomfortable questions please ! It's normal for a RHEL rebuild to be months behind the original. It has never been different for years. Either shut up or pay for the real thing. The developers are doing the best they can. Again all is well. Don't believe the non-believers.
Are you sure, this answer was ok?
I can't see any criticism, not in Mathews comment and not in the original question. And even if, a fair comment should be ok, or?
And if you really think, the question is uncomfortable, don't answer. But don't tell people, it's not allowed to ask questions ...
On 02/16/2011 04:03 PM, Dag Wieers wrote:
On Wed, 16 Feb 2011, Matthew Miller wrote:
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
One is not expected to criticize on this list. All is well. Don't ask any uncomfortable questions please ! It's normal for a RHEL rebuild to be months behind the original. It has never been different for years. Either shut up or pay for the real thing. The developers are doing the best they can. Again all is well. Don't believe the non-believers.
You are such a baby Dag.
On Fri, 18 Feb 2011, Johnny Hughes wrote:
On 02/16/2011 04:03 PM, Dag Wieers wrote:
One is not expected to criticize on this list. All is well. Don't ask any uncomfortable questions please ! It's normal for a RHEL rebuild to be months behind the original. It has never been different for years. Either shut up or pay for the real thing. The developers are doing the best they can. Again all is well. Don't believe the non-believers.
You are such a baby Dag.
If after so many years we still have the same issues, and the same threads and arguments come up, including the promise to fix it after the release gets out, but it never does, then yes, I become cynical.
It's been almost 2 years I left the CentOS team because I couldn't defend the CentOS project anymore. The only thing solved was the ownership of the CentOS name and domains, but all the other problems regarding code transparency, trust-issues, missing or delayed updates, governance, adding more people for redundancy, where the considerable ad income is going, etc...
But I am preaching to the wrong choir, because you obviously know all this.
http://dag.wieers.com/blog/leaving-centos-team-not-centos-community
At least with your involvement I am confident CentOS 4.9 will not be as late as CentOS 4.8 was. (And this time I am not being cynical)
On 2/18/2011 10:47 AM, Dag Wieers wrote:
It's been almost 2 years I left the CentOS team because I couldn't defend the CentOS project anymore. The only thing solved was the ownership of the CentOS name and domains, but all the other problems regarding code transparency, trust-issues, missing or delayed updates, governance, adding more people for redundancy, where the considerable ad income is going, etc...
But I am preaching to the wrong choir, because you obviously know all this.
http://dag.wieers.com/blog/leaving-centos-team-not-centos-communityAt least with your involvement I am confident CentOS 4.9 will not be as late as CentOS 4.8 was. (And this time I am not being cynical)
Have you attempted the same involvement with SL? Or considered building a non-scientific respin of their version? (Basically backing out their changes...). Given the economic environment, maybe it would be good if they had some volunteer backup.
On Fri, 18 Feb 2011, Les Mikesell wrote:
On 2/18/2011 10:47 AM, Dag Wieers wrote:
It's been almost 2 years I left the CentOS team because I couldn't defend the CentOS project anymore. The only thing solved was the ownership of the CentOS name and domains, but all the other problems regarding code transparency, trust-issues, missing or delayed updates, governance, adding more people for redundancy, where the considerable ad income is going, etc...
But I am preaching to the wrong choir, because you obviously know all this.
http://dag.wieers.com/blog/leaving-centos-team-not-centos-communityAt least with your involvement I am confident CentOS 4.9 will not be as late as CentOS 4.8 was. (And this time I am not being cynical)
Have you attempted the same involvement with SL? Or considered building a non-scientific respin of their version? (Basically backing out their changes...). Given the economic environment, maybe it would be good if they had some volunteer backup.
Hi Les,
I recently became a dad, am renovating a house, am involved in a few Open Source projects already, so the little time I have left I would like to spend wisely ;-) Although I would support any initiative to bring more competition into the RHEL rebuild market.
My opinion has always been that more competition is good for CentOS and for its users, compare the current situation with when Whitebox and Tao Linux were still around and you could feel the positive influence of the competition (the race to be the first to release was one of them).
That's why more transparency from CentOS regarding to buildtools, changes and processes (including an open QA process) would be a much better approach in the long run for everyone involved than a closed and protected process with less than a handful of people at the center and the large community in the dark.
Although I do understand that some people prefer to keep the control and power over things, I just do not agree with it.
On Fri, Feb 18, 2011 at 11:19 AM, Les Mikesell lesmikesell@gmail.com wrote:
Have you attempted the same involvement with SL? Or considered building a non-scientific respin of their version? (Basically backing out their changes...). Given the economic environment, maybe it would be good if they had some volunteer backup.
IMHO Dag should _consider_ what centos.alt.ru has done and either vet them or do the same thing if they can't be vetted. There's a need for current BIND, et al and RH's policy of backporting takes time and puts perhaps millions of systems at risk.
SL could have been named "US Government Linux"; there's nothing "scientific" about sl-base and sl-security. It plays well in the same environments RH and CentOS play well in, of course, because of the charter.
kind regards/ldv/vaden@texoma.net
<quote from top management of Internet2 security> It's fundamentally wrong for RedHat to attempt to backport security patches for such a fundamental service. I'd cuss a blue streak about this point, in fact, except that I don't want to trigger the anti-cuss features at Dr. Vaughn's place of employment. </quote from manager of Internet2 security>
On 2/18/2011 11:35 AM, Larry Vaden wrote:
There's a need for current BIND, et al and RH's policy of backporting takes time and puts perhaps millions of systems at risk.
That's very much a separate issue, and a question of whether you prefer old bugs to new ones. Unless you think there are no new bugs.
On Fri, Feb 18, 2011 at 11:50 AM, Les Mikesell lesmikesell@gmail.com wrote:
On 2/18/2011 11:35 AM, Larry Vaden wrote:
There's a need for current BIND, et al and RH's policy of backporting takes time and puts perhaps millions of systems at risk.
That's very much a separate issue, and a question of whether you prefer old bugs to new ones. Unless you think there are no new bugs.
New bugs are arguably more difficult to exploit than well known old bugs and IMHO the OSS community, in general, moves closer to a complete and correct solution with each release.
On Friday, February 18, 2011 12:35:16 pm Larry Vaden wrote:
There's a need for current BIND, et al and RH's policy of backporting takes time and puts perhaps millions of systems at risk.
What exactly is so necessary about having 'current' BIND, and what will break or change in an unexpected way when BIND is brought current?
<quote from top management of Internet2 security> It's fundamentally wrong for RedHat to attempt to backport security patches for such a fundamental service. I'd cuss a blue streak about this point, in fact, except that I don't want to trigger the anti-cuss features at Dr. Vaughn's place of employment. </quote from manager of Internet2 security>
You keep quoting this, but, it seems to me Red Hat has done very well in the market at a time in which the market was difficult. They can't be doing to many things that are 'fundamentally wrong' or they'd go out of business (since they aren't a monopoly). Details, man, details.
However, the CentOS list is the wrong place to address this; the stated goal of the core CentOS repositories (this excludes CentOSPlus) is to be as close to upstream as is possible in building from the source; bugs and all. Address the bug upstream; it will then come downstream. That is and has been the CentOS credo pretty much as long as there has been a CentOS, as far as I can recall.
As a further comment, it is not easy to get this close to the upstream at the binary level. Things are better than they used to be back in the days of beehive and highly customized specialized buildhosts (I could find my archived message from Jeff Johnson about it, and I probably could share it here since it's been over ten years, but I have more important things to do after I'm finished with lunch).
But things are not perfect, and Red Hat does not make public the complete specs on its buildsystems. Like I say, it is better now than in the good old days, thanks in no small part to the Fedora project's open infrastructure, but there are still niggles to do to get things to build.
Troy has documented on the SL list about some of those niggles; I've been reading the release notes, and they are revealing about the process, and about some fundamental differences between SL and CentOS, both the distributions and the projects. Anyone curious about those differences, read through the archives of all the lists and see them for yourself; I'm not going to summarize here. Suffice to say that I don't think either approach is the One True Way to an EL rebuild; they are just different.
At one time I thought they should join forces, but even as talented as all the folks involved are, it wouldn't be the greatest of ideas; in a way, thanks to how open the processes of both distributions are (yes, the CentOS process is more open than it could be!), they already have joined forces, just as sovereign allies, instead of parts of one big project.
Johnny has posted a link to the buildsystem 'things' for C3,4,and 5; 6 isn't up there, probably because it's not finalized.
I was there in the old days of waiting on a new RHL release; this process is scads more open than the process then was, that is for sure.
On 2/18/2011 12:14 PM, Lamar Owen wrote:
At one time I thought they should join forces, but even as talented as all the folks involved are, it wouldn't be the greatest of ideas; in a way, thanks to how open the processes of both distributions are (yes, the CentOS process is more open than it could be!), they already have joined forces, just as sovereign allies, instead of parts of one big project.
In a truly open system, you don't need to 'join forces' to take advantage of each others' work. The version control system will tell you everything you might need to know, and the fact that it is open means that permission to use it is implicit.
On Friday, February 18, 2011 01:30:14 pm Les Mikesell wrote:
In a truly open system, you don't need to 'join forces' to take advantage of each others' work. The version control system will tell you everything you might need to know, and the fact that it is open means that permission to use it is implicit.
Perhaps the expression 'join forces' isn't quite right.
The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.
Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
On 2/18/2011 12:48 PM, Lamar Owen wrote:
In a truly open system, you don't need to 'join forces' to take advantage of each others' work. The version control system will tell you everything you might need to know, and the fact that it is open means that permission to use it is implicit.
Perhaps the expression 'join forces' isn't quite right.
The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.
Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
Nobody said it was trivial or easy. No major software project is. But the open ones put all their tools in a version control system that anyone can access and duplicate. And the successful open ones find that some of the people who do access and duplicate their work improve on it and make their improvements available. Is anything like that happening here?
On 02/18/2011 01:00 PM, Les Mikesell wrote:
On 2/18/2011 12:48 PM, Lamar Owen wrote:
In a truly open system, you don't need to 'join forces' to take advantage of each others' work. The version control system will tell you everything you might need to know, and the fact that it is open means that permission to use it is implicit.
Perhaps the expression 'join forces' isn't quite right.
The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.
Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
Nobody said it was trivial or easy. No major software project is. But the open ones put all their tools in a version control system that anyone can access and duplicate. And the successful open ones find that some of the people who do access and duplicate their work improve on it and make their improvements available. Is anything like that happening here?
But the VERSION CONTROL SYSTEM would need to be implemented BY upstream not us.
Our stated goal is to NOT change anything that we don't have to change. We ONLY make changes to the packages as required to remove trademarks ... we add NO CHANGES to fix the packages.
It is our goal to NOT HAVE ANY CHANGES.
Therefore a VCS at the package level for our projects is worthless (except for the packages that we have to change to remove trademarks).
That is what no one is understanding here.
We do NOT change the packages (the SRPMS), therefore there is nothing inside the packages to track. If you have the SRPM, you have the source code that would get imported into the VCS ... it would then also be rebuilt exactly like it was to submit it to the build system.
For packages that are not changed at all (the VAST MAJORITY in the case of CentOS), this splitting of SRPMS into a VCS and then reassembly from the VCS into an SRPM adds nothing to the overall process. In fact, it only adds a potential spot to do unneeded actions that might introduce errors into the packages on reassembly.
So, this VCS at the CentOS level is extra work for us with no added benefit to producing packages.
The vast majority of the time, we are working directly with SRPMS, and not a VCS.
On 02/19/2011 04:29 AM, Johnny Hughes wrote:
On 02/18/2011 01:00 PM, Les Mikesell wrote:
On 2/18/2011 12:48 PM, Lamar Owen wrote:
In a truly open system, you don't need to 'join forces' to take advantage of each others' work. The version control system will tell you everything you might need to know, and the fact that it is open means that permission to use it is implicit.
Perhaps the expression 'join forces' isn't quite right.
The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.
Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
Nobody said it was trivial or easy. No major software project is. But the open ones put all their tools in a version control system that anyone can access and duplicate. And the successful open ones find that some of the people who do access and duplicate their work improve on it and make their improvements available. Is anything like that happening here?
But the VERSION CONTROL SYSTEM would need to be implemented BY upstream not us.
Our stated goal is to NOT change anything that we don't have to change. We ONLY make changes to the packages as required to remove trademarks ... we add NO CHANGES to fix the packages.
It is our goal to NOT HAVE ANY CHANGES.
Therefore a VCS at the package level for our projects is worthless (except for the packages that we have to change to remove trademarks).
That is what no one is understanding here.
We do NOT change the packages (the SRPMS), therefore there is nothing inside the packages to track. If you have the SRPM, you have the source code that would get imported into the VCS ... it would then also be rebuilt exactly like it was to submit it to the build system.
For packages that are not changed at all (the VAST MAJORITY in the case of CentOS), this splitting of SRPMS into a VCS and then reassembly from the VCS into an SRPM adds nothing to the overall process. In fact, it only adds a potential spot to do unneeded actions that might introduce errors into the packages on reassembly.
So, this VCS at the CentOS level is extra work for us with no added benefit to producing packages.
The vast majority of the time, we are working directly with SRPMS, and not a VCS.
Something else i want to point out here is that IF you need to adjust a build root for a package for version x.y.z-1 ... when x.y.z-2 comes out, it may or may not need that same change. And in fact, we try building it first with NO changes in the build root to see if it will build, if it does not then we would look at what is in (or what is extra in) the compare process and add or remove things to get the correct linking.
There is no magic secret sauce or magic VCS here to be kept over time. It is brute force build, compare, adjust, build. It is good only for the one iteration for which it is performed. The next time a new package is built, we do it in a virgin way to try and reproduce it exactly as the SRPM requires.
It is no harder than build it in mock ... check it ... manually modify the build root with some commands ... if required (if the package fails the compare).
You guys act like we are doing magic here, we are not.
On 2/19/11 4:42 AM, Johnny Hughes wrote:
Therefore a VCS at the package level for our projects is worthless (except for the packages that we have to change to remove trademarks).
That is what no one is understanding here.
How do you track the work you do, reproduce it across architectures, and duplicate it to spread the load over multiple machines?
There is no magic secret sauce or magic VCS here to be kept over time. It is brute force build, compare, adjust, build. It is good only for the one iteration for which it is performed. The next time a new package is built, we do it in a virgin way to try and reproduce it exactly as the SRPM requires.
That sounds exactly like a situation where having more people involved could help, given the ability to share the state of current work.
It is no harder than build it in mock ... check it ... manually modify the build root with some commands ... if required (if the package fails the compare).
You guys act like we are doing magic here, we are not.
You really aren't doing those changes by retyping the command lines on every machine involved with no automated way to reproduce it or history of what you've done, are you?
On Saturday, February 19, 2011 11:15:39 am Les Mikesell wrote:
How do you track the work you do, reproduce it across architectures, and duplicate it to spread the load over multiple machines?
I don't know how CentOS the project does this; and that's ok.
I do know how Fedora does it, and it's called koji. And apparently RHEL6 was created with koji. Koji was built from the ground up to do this, and do it on a large scale.
For all I know Johnny and Karanbir and whoever else is doing buildsystem work for CentOS may be using koji; but my gut feel is that if they're not using it now it's too late in this cycle to start with it.
Perhaps in the future; and perhaps not, that's up to the folk doing the actual work of producing the distribution to decide. Not my decision, that much is for sure. Now if I wanted to produce my own dist (LOOSE; Lamar Owen's Operating System - Enterprise) it would be up to me. But this is CentOS, and it isn't up to me. I shouldn't try to be a backseat driver, IOW.
Hi,
On 02/19/2011 04:53 PM, Lamar Owen wrote:
For all I know Johnny and Karanbir and whoever else is doing buildsystem work for CentOS may be using koji; but my gut feel is that if they're not using it now it's too late in this cycle to start with it.
We dont use Koji, there are no plans to use koji or anything like that. We have very basic requirements from the buildsystem and we have a lot of requirements on the testing side of things. Going with a basic process that can work with srpms and work with automated testing at the other end is what was decided. Were sticking with that for the near future.
Perhaps in the future; and perhaps not, that's up to the folk doing the actual work of producing the distribution to decide. Not my decision, that much is for sure. Now if I wanted to produce my own dist (LOOSE; Lamar Owen's Operating System - Enterprise) it would be up to me. But this is CentOS, and it isn't up to me. I shouldn't try to be a backseat driver, IOW.
the idea of 'version control' is interesting, we publish ( just as we work with ) complete, tested srpms as the code-component because it helps retain some level of sanity ( even if the idea of sanity is insane in cases with builddep's are no longer relevant etc ). However if people want to work with a git like repo, I created and pulled in the el6 codebase into git repo's, hosted at https://nazar.karan.org/cgit/ - thats available as a purely side effect resource that people want to look at, its not what we work with within centos.
- KB
On Saturday, February 19, 2011 05:29:53 am Johnny Hughes wrote:
It is our goal to NOT HAVE ANY CHANGES.
Therefore a VCS at the package level for our projects is worthless
[snip]
We do NOT change the packages (the SRPMS), therefore there is nothing inside the packages to track.
Whew. I understand this, for sure; but I think there is some cross-communication misunderstandings here.
What I think most people are asking about is not the packages that are being built, and a VCS for the packages (if that's what they are wanting), well, I agree 100% that that is useless, since, as stated, to goal is the rebuild the completely unchanged source RPM and get the binary equivalent RPM out the backend. The SRPMS for the upstream components are already publicly visible at ftp.redhat.com.
What I think folks are most interested in, and I know this is my case, is the versioning of the packages and changes (custom scripts, etc) to any packages on the buildhost that is doing the mock build itself.
It's kindof like making sourdough bread (which I've done, using native yeast starter); the same set of ingredients, and the sourdough recipe is a well-known recipe, and pretty consistent from location to location, but yet the same ingredients using the same exact recipe can produce different results; it's all in the particular native yeast used for the starter, and the techniques used to get the starter started. That's why San Francisco sourdough bread tastes different from Western North Carolina sourdough bread; different yeasts.
The upstream SRPMS are the ingredients, mock is the recipe; but what went into the starter?
And, yes, sourdough starters are closely guarded secrets at bakeries that have unique products; similar is true for other yeast-driven ferments, including various alcoholic beverages made from fermented starches of various kinds. Which is why you can't make true scotch whisky anywhere but Scotland; it's all in the yeast, which is native.
That's the part of the process that isn't externally open as far as I can tell. We have quite a bit of scattered documentation on the buildsystem, including mock configs, your scripts you posted a while back, etc. But the versioning of the buildhost (which, in theory shouldn't matter but in practice it does, especially for certain architectures like UltraSPARC) isn't well documented. At least I've not run across it; which is not the same thing as saying that it doesn't exist: it's just saying that I've not yet found it.
To me, a simple 'rpm -qa|sort' output from the buildhost itself would answer a lot of my questions. I certainly would like to see that output for the IA64 buildhost, and for the last buildhost used for that one alpha SPARC build, as I would like to do those myself (getting C6 on UltraSPARC would be one of my end goals; there is a semi-usable F12-beta for SPARC, even though it's pretty broken for development purposes, meaning that the koji instance on the builder couldn't have been self-hosting and must be running something 'special').
But without knowing the packages and scripts on the buildhost and external to the SRPM repository to build I don't even know where to start, since I know a buildhost on SPARC requires some deep magic to set up (64-bit kernel but 32-bit userland; the buildhost has to be able to build a 64-bit kernel, and that isn't the easiest of tasks when the whole of userland is 32-bits, which makes sense pretty much only on SPARC, since 64-bit has no performance advantages on SPARC, just memory size advantages). I had a mutt setup on our E6500 at one time that began with Aurora 1.0 and went from there, using yum upgrades..... and replicating it would be a major undertaking. But that was the only SPARC build that I had here that would successfully build a kernel package set.
So I'm off to investigate the Fedora buildhost documentation that I can find and go from there. (pointer for those who want to see 'square 1' for such: http://fedoraproject.org/wiki/Koji/ServerHowTo ) And this is really overkill infrastructure for a buildhost used for special purposes, I know, but at least it's a documented large-scale distributed buildsystem, and perhaps the key to understanding the whole thing resides somewhere in the reams of information out there)....and in no way am I implying that CentOS uses koji, just that a closely related project does (since Fedora is somewhat the upstream for RHEL).
And, of course, getting an IA64 C6 (which might or might not be possible) would be something I'd love to try out, and is something I would want to do myself and not bother anyone else with; and if the results were something other people would want, then we could look at that when/if that arose.
And while I may very well have missed what others are interested in, I'm interested mostly in the buildhost magic, and there is magic at the buildhost level in any rebuild. Even if the magic is not automated...... And I'm not at all interested in 'competing' with the CentOS project; I don't have the bandwidth, for one, even if I do have the storage.
But I certainly reserve the right to be wrong, on all counts.
On 2/19/11 8:44 AM, Lamar Owen wrote:
And while I may very well have missed what others are interested in, I'm interested mostly in the buildhost magic, and there is magic at the buildhost level in any rebuild. Even if the magic is not automated...... And I'm not at all interested in 'competing' with the CentOS project; I don't have the bandwidth, for one, even if I do have the storage.
I completely agree. I am interested in duplicating it so I can learn more about the process, and through that perhaps be able to contribute to the project. I think what would be ideal would be something like a kickstart plus a puppet configuration for the buildhost, or at least a wiki page documenting the exact steps for setting up a buildhost.
Steve
Hi,
On 02/19/2011 04:33 PM, Steve Meyers wrote:
And while I may very well have missed what others are interested in, I'm interested mostly in the buildhost magic, and there is magic at the buildhost level in any rebuild. Even if the magic is not
I completely agree. I am interested in duplicating it so I can learn more about the process, and through that perhaps be able to contribute to the project. I think what would be ideal would be something like a
These sort of questions come from the FUD created by the silly people. In order to convert a source package to a binary package, you need to hit rpmbuild at some stage or the other, the environment it churns in can impact the result and these days convention in the rhel/fedora/centos areas is to use mock and a defined common buildroot.
The idea of magic juice used by CentOS is not only stupid its also what leads you into believing a lot of the other crap that these people shovel out.
- KB
On 2/21/11 7:59 AM, Karanbir Singh wrote:
On 02/19/2011 04:33 PM, Steve Meyers wrote:
And while I may very well have missed what others are interested in, I'm interested mostly in the buildhost magic, and there is magic at the buildhost level in any rebuild. Even if the magic is not
I completely agree. I am interested in duplicating it so I can learn more about the process, and through that perhaps be able to contribute to the project. I think what would be ideal would be something like a
These sort of questions come from the FUD created by the silly people. In order to convert a source package to a binary package, you need to hit rpmbuild at some stage or the other, the environment it churns in can impact the result and these days convention in the rhel/fedora/centos areas is to use mock and a defined common buildroot.
The idea of magic juice used by CentOS is not only stupid its also what leads you into believing a lot of the other crap that these people shovel out.
I was basing my statement on what Johnny had said. He stated that the reason it takes so long to do rebuilds is because the build environment for some packages is unknown, and it takes some guesswork to figure out whether it was built on RHEL 5, Fedora, or whatever.
Steve Meyers
On 02/21/2011 05:41 PM, Steve Meyers wrote:
I was basing my statement on what Johnny had said. He stated that the reason it takes so long to do rebuilds is because the build environment for some packages is unknown, and it takes some guesswork to figure out whether it was built on RHEL 5, Fedora, or whatever.
and so ?
whats stopping you from trying to get through that stuff like others have done ? Timo / Farkas etc have been vocal and been busy in the bugzilla.r.c for and with just this sort of an effort.
Maybe I just fail to see what your point is.
- KB
On Fri, Feb 18, 2011 at 12:14 PM, Lamar Owen lowen@pari.edu wrote:
But things are not perfect, and Red Hat does not make public the complete specs on its buildsystems. Like I say, it is better now than in the good old days, thanks in no small part to the Fedora project's open infrastructure, but there are still niggles to do to get things to build.
Troy has documented on the SL list about some of those niggles;
A member of the "information wants to be free club" offers this quote from Troy:
<quote> p.s. Really, we have no "top secret" stuff. High Energy Physics labs are very open and willing to share. </quote>
Hi
On 02/18/2011 04:47 PM, Dag Wieers wrote:
If after so many years we still have the same issues, and the same threads and arguments come up, including the promise to fix it after the release gets out, but it never does, then yes, I become cynical.
You will find that its only you who really comes up with these things - and since the 6.0 was announced upstream this is the third time you have decided to start throwing marbles around a process you neither understand nor want to.
I've read through most of this thread and its all just random stuff recycled over and over with zero real value add. You seem to have something in your mind as to how a process might work, and are completely unable to comprehend any deviations from there. I am no sure if there is any other way to put this across.
- KB
2011/2/21 Karanbir Singh mail-lists@karan.org:
[...] I've read through most of this thread and its all just random stuff recycled over and over with zero real value add. You seem to have something in your mind as to how a process might work, and are completely unable to comprehend any deviations from there. I am no sure if there is any other way to put this across.
With other words, what I think that is perfect is really perfect, other people are just time consuming idiots without technical knowledge. And they don't contribute to the project so they have to shut up. Did you ever asked yourself why so less people contribute to the CentOS project? Maybe it has something to do with the CentOS project and not with the fact that are only idiots out there who can't contribute to the project.
Kind regards, Thomas
P.S.: I set up a mock/script based infrastructure as a proof of concept for a fork in less than four weeks from scratch, so it can't be so much rocket science to get C6 up and running if enough people sort out the remaining build problems.
On Tue, Feb 22, 2011 at 10:56 AM, Thomas Bendler ml@bendler-net.de wrote:
Maybe it has something to do with the CentOS project and not with the fact that are only idiots out there who can't contribute to the project.
1) RHEL is the intellectual property of RedHat, subject to the licenses of the work of OSS giants 2) RH will seek to maximize RH shareholder equity ... 3) RH has hand-selected certain RH employees to perform the CentOS project, not more, not fewer 4) to make it more difficult for competitors, there are in Lamar's words, sniggles 5) RH pays partial lip service to "we stand on the shoulders of OSS giants" 6) RH looks at CentOS as a farm club of future rate-payers
IOW, much of this is about #3.
- RH has hand-selected certain RH employees to perform the CentOS
project, not more, not fewer
IOW, much of this is about #3.
I think you need to lay off the consperacy theories Larry, really. Just because the devs have better things to do right now (like completing 4.9/5.6/6) rather than training a bunch of newbies, that does not automatically mean that they are trying to protect exclusivity...only productivity. IMPO we would all be a lot better off if everyone here would lay off the core team and let them do their work.
-David
Am 22.02.11 18:22, schrieb Larry Vaden:
Can you please stop your senseless drivel on all kinds of mailing lists around the CentOS project? This is the first time that I've been asked by *many* members of the community to remove someone from the mailing lists, namely you.
And I must say that I do understand them while trying to catch up on mailing list things at the moment.
Ralph
On Tue, Feb 22, 2011 at 5:48 PM, Ralph Angenendt ralph.angenendt@gmail.com wrote:
Can you please stop your senseless drivel on all kinds of mailing lists around the CentOS project? This is the first time that I've been asked by *many* members of the community to remove someone from the mailing lists, namely you.
Ralph, thanks for your input --- it is fully appreciated.
I was about to ask Johnny a question, but now I see I probably shouldn't unless privacy is irrelevant. If privacy is irrelevant, then you can hit DELETE now.
Did the count of 8 million
. come from a SWAG . came from monitoring installs . came from monitoring unique (e.g., mac-based) installs . additional choices based on what you know about the count
===genesis:
On Tue, Feb 22, 2011 at 12:36 PM, Johnny Hughes johnny@centos.org wrote:
Well Thomas ... when you have a thousand server infrastructure to serve 6-8 million unique computers with every update then you would rival the CentOS project.
On 02/22/2011 10:56 AM, Thomas Bendler wrote:
2011/2/21 Karanbir Singh mail-lists@karan.org:
[...] I've read through most of this thread and its all just random stuff recycled over and over with zero real value add. You seem to have something in your mind as to how a process might work, and are completely unable to comprehend any deviations from there. I am no sure if there is any other way to put this across.
With other words, what I think that is perfect is really perfect, other people are just time consuming idiots without technical knowledge. And they don't contribute to the project so they have to shut up. Did you ever asked yourself why so less people contribute to the CentOS project? Maybe it has something to do with the CentOS project and not with the fact that are only idiots out there who can't contribute to the project.
Kind regards, Thomas
P.S.: I set up a mock/script based infrastructure as a proof of concept for a fork in less than four weeks from scratch, so it can't be so much rocket science to get C6 up and running if enough people sort out the remaining build problems.
Well Thomas ... when you have a thousand server infrastructure to serve 6-8 million unique computers with every update then you would rival the CentOS project.
10-15 people on a mailing list continually whining is one thing ... 8 million machines served is the real thing.
Le 22/02/2011 22:36, Johnny Hughes a écrit :
On 02/22/2011 10:56 AM, Thomas Bendler wrote:
2011/2/21 Karanbir Singh mail-lists@karan.org:
[...] I've read through most of this thread and its all just random stuff recycled over and over with zero real value add. You seem to have something in your mind as to how a process might work, and are completely unable to comprehend any deviations from there. I am no sure if there is any other way to put this across.
With other words, what I think that is perfect is really perfect, other people are just time consuming idiots without technical knowledge. And they don't contribute to the project so they have to shut up. Did you ever asked yourself why so less people contribute to the CentOS project? Maybe it has something to do with the CentOS project and not with the fact that are only idiots out there who can't contribute to the project.
Kind regards, Thomas
P.S.: I set up a mock/script based infrastructure as a proof of concept for a fork in less than four weeks from scratch, so it can't be so much rocket science to get C6 up and running if enough people sort out the remaining build problems.
Well Thomas ... when you have a thousand server infrastructure to serve 6-8 million unique computers with every update then you would rival the CentOS project.
10-15 people on a mailing list continually whining is one thing ... 8 million machines served is the real thing.
Hello,
But Thomas is not doing things different from Centos; rpmbuild --rebuild (using mock and koji of course) ... There is "no magic sauce" as you said, Centos is only rebuilding srpms from RHEL. So install rpms on One or Millions of computers is the same, after all RH does the hard work (RH and the "million" of programmers that contribute to software under GPL/LGPL/... license).
ps: long live to puppet / fabric (http://docs.fabfile.org/0.9.4/) ; One, One thousand, millions ..;)
Regards
js.
2011/2/22 Johnny Hughes johnny@centos.org:
[...] Well Thomas ... when you have a thousand server infrastructure to serve 6-8 million unique computers with every update then you would rival the CentOS project. 10-15 people on a mailing list continually whining is one thing ... 8 million machines served is the real thing.
Scaling is something that is part of the architecture of a project, technical and functional. Having a major slow down in getting things up an running (4.9, 5.6 and 6) means there is a fundamental lack of a scalable architecture (and yes, I know about what I'm talking about, companies I'm working for are providing services for million of peoples without the help of mirrors). It is completely unbelievable that the CentOS team still think that is no real problem that releases take so much time simply because three releases start at the same time. This is something that could happen every time in the future again. So it's time to think about the architecture of the project and how to spread the load to more people to have three completely independent release teams and release cycles in the range of four weeks after RHEL GA versions.
And to make my point clear, I don't believe it is rocket science to get such a release cycle established if _more_ skilled people are involved in the release creation (beyond translation work).
Kind regards, Thomas
On 02/22/2011 08:26 PM, Thomas Bendler wrote:
And to make my point clear, I don't believe it is rocket science to get such a release cycle established if _more_ skilled people are involved in the release creation (beyond translation work).
I do believe you dont know what you are talking about, have done no research or aware of the CentOS process. You seem to be going on and on about getting more eyes on the ball, which is exactly what we attempted to do last year, and the option is still open.
- KB
2011/2/23 Karanbir Singh mail-lists@karan.org
On 02/22/2011 08:26 PM, Thomas Bendler wrote:
And to make my point clear, I don't believe it is rocket science to get such a release cycle established if _more_ skilled people are involved in the release creation (beyond translation work).
I do believe you dont know what you are talking about, have done no research or aware of the CentOS process. You seem to be going on and on about getting more eyes on the ball, which is exactly what we attempted to do last year, and the option is still open.
Funny to know that I don't know what I'm talking about but maybe you can be more specific. As I already pointed out in another mail, for me it look like that having more than one release at the same time (4.9, 5.6 and 6) result in a major slow down of release cycle time. This means for me, the project isn't able to scale (correct me if I'm wrong). When the project can't scale it is under normal circumstances a matter of human resources or technical boundaries. As you told me already in December, it is not a technical problem. So from my point of view it could _only_ be a matter of human resources in terms that not enough people working on the release (again, correct me if I'm wrong). To offer my help I asked already in December, please provide a list of packages that don't compile so that people that are willing to help can help getting this packages compiled (i.e. with differnet mock settings or whatever needed to get this compiled). If the recompile isn't possible because the SRPM is broken they can submit Bugreports to RH. But I only saw such a list on the SL website ( https://www.scientificlinux.org/distributions/6x/build/problembyrpm), not on the CentOS website.
What I heard in the meantime is that CentOS has a policy that the next release must be compiled with CentOS what I think is a bit funny simply because RedHat don't use a build environment based in RedHat (I read an article in the press indicating that they use FC12 koji with some FC13, FC14 backports, but I can't proof this). But the point is still, if you and your team allow skilled people to support you in the release creation (not by signing packages or so, but to work out open items, problems, whatsoever) it is something that the CentOS project will benefit, specially if you look at the mails currently on the list, most mails are from the same type, when is CentOS X.X released and why isn't it already released.
Kind regards, Thomas
On 02/24/2011 10:59 AM, Thomas Bendler wrote:
2011/2/23 Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org>
On 02/22/2011 08:26 PM, Thomas Bendler wrote: > And to make my point clear, I don't believe it is rocket science to > get such a release cycle established if _more_ skilled people are > involved in the release creation (beyond translation work). I do believe you dont know what you are talking about, have done no research or aware of the CentOS process. You seem to be going on and on about getting more eyes on the ball, which is exactly what we attempted to do last year, and the option is still open.Funny to know that I don't know what I'm talking about but maybe you can be more specific. As I already pointed out in another mail, for me it look like that having more than one release at the same time (4.9, 5.6 and 6) result in a major slow down of release cycle time. This means for me, the project isn't able to scale (correct me if I'm wrong). When the project can't scale it is under normal circumstances a matter of human resources or technical boundaries. As you told me already in December, it is not a technical problem. So from my point of view it could _only_ be a matter of human resources in terms that not enough people working on the release (again, correct me if I'm wrong). To offer my help I asked already in December, please provide a list of packages that don't compile so that people that are willing to help can help getting this packages compiled (i.e. with differnet mock settings or whatever needed to get this compiled). If the recompile isn't possible because the SRPM is broken they can submit Bugreports to RH. But I only saw such a list on the SL website (https://www.scientificlinux.org/distributions/6x/build/problembyrpm), not on the CentOS website.
What I heard in the meantime is that CentOS has a policy that the next release must be compiled with CentOS what I think is a bit funny simply because RedHat don't use a build environment based in RedHat (I read an article in the press indicating that they use FC12 koji with some FC13, FC14 backports, but I can't proof this). But the point is still, if you and your team allow skilled people to support you in the release creation (not by signing packages or so, but to work out open items, problems, whatsoever) it is something that the CentOS project will benefit, specially if you look at the mails currently on the list, most mails are from the same type, when is CentOS X.X released and why isn't it already released.
Why isn't SL released yet ... why did Oracle only release it last week ... because it takes time and it is hard.
If you want to use CentOS, feel free to use it. If you don't, feel free to leave.
I do appreciate everyone's efforts!
I have a few idle servers locally that can be used for compiling, but unfortunately cannot make the servers accessible to the outside. If that helps, I am willing to toss in CPU cycles.
On Thu, Feb 24, 2011 at 12:11 PM, Johnny Hughes johnny@centos.org wrote:
On 02/24/2011 10:59 AM, Thomas Bendler wrote:
2011/2/23 Karanbir Singh <mail-lists@karan.org mailto:mail-lists@karan.org>
On 02/22/2011 08:26 PM, Thomas Bendler wrote: > And to make my point clear, I don't believe it is rocket science to > get such a release cycle established if _more_ skilled people are > involved in the release creation (beyond translation work). I do believe you dont know what you are talking about, have done no research or aware of the CentOS process. You seem to be going on andon
about getting more eyes on the ball, which is exactly what weattempted
to do last year, and the option is still open.Funny to know that I don't know what I'm talking about but maybe you can be more specific. As I already pointed out in another mail, for me it look like that having more than one release at the same time (4.9, 5.6 and 6) result in a major slow down of release cycle time. This means for me, the project isn't able to scale (correct me if I'm wrong). When the project can't scale it is under normal circumstances a matter of human resources or technical boundaries. As you told me already in December, it is not a technical problem. So from my point of view it could _only_ be a matter of human resources in terms that not enough people working on the release (again, correct me if I'm wrong). To offer my help I asked already in December, please provide a list of packages that don't compile so that people that are willing to help can help getting this packages compiled (i.e. with differnet mock settings or whatever needed to get this compiled). If the recompile isn't possible because the SRPM is broken they can submit Bugreports to RH. But I only saw such a list on the SL website (https://www.scientificlinux.org/distributions/6x/build/problembyrpm), not on the CentOS website.
What I heard in the meantime is that CentOS has a policy that the next release must be compiled with CentOS what I think is a bit funny simply because RedHat don't use a build environment based in RedHat (I read an article in the press indicating that they use FC12 koji with some FC13, FC14 backports, but I can't proof this). But the point is still, if you and your team allow skilled people to support you in the release creation (not by signing packages or so, but to work out open items, problems, whatsoever) it is something that the CentOS project will benefit, specially if you look at the mails currently on the list, most mails are from the same type, when is CentOS X.X released and why isn't it already released.
Why isn't SL released yet ... why did Oracle only release it last week ... because it takes time and it is hard.
If you want to use CentOS, feel free to use it. If you don't, feel free to leave.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
2011/2/24 Johnny Hughes johnny@centos.org
[...]
Why isn't SL released yet ... why did Oracle only release it last week
... because it takes time and it is hard.
A lot of the things take time and a lot of things are hard. And in most cases the process could be simplified and the speed could be increased, but only if the process, man power, whatsoever is optimized.
If you want to use CentOS, feel free to use it. If you don't, feel free to leave.
Very constructive! I'm not on this list because I use Oracle, SL or any other rebuild of RHEL, I'm using CentOS and I would like to stay with CentOS. But if no comment is taken serious I'm not convinced if this is a smart decision.
Kind regards, Thomas
On Thu, 24 Feb 2011, Johnny Hughes wrote:
Why isn't SL released yet ... why did Oracle only release it last week ... because it takes time and it is hard.
Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling release since early february.
On 02/24/2011 09:34 PM, Dag Wieers wrote:
On Thu, 24 Feb 2011, Johnny Hughes wrote:
Why isn't SL released yet ... why did Oracle only release it last week ... because it takes time and it is hard.
Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling release since early february.
Given that Red Hat released 5.6 on Jan 13th, its interesting that you say Oracle had their build out on the 12th. Also interesting and worth noting is that 5.6 sources stock was still making its way to ftp.r.c a few days back ( well into second half of Feb ). Its blatantly clear that neither Oracle nor SciLinux are operating with the same model as are. And I think its also quite clear that we don't really give a rat's ass about what Oracle or SciLinux are doing.
So, can we just give up all this random noise now
- KB
On Thu, 24 Feb 2011, Karanbir Singh wrote:
On 02/24/2011 09:34 PM, Dag Wieers wrote:
On Thu, 24 Feb 2011, Johnny Hughes wrote:
Why isn't SL released yet ... why did Oracle only release it last week ... because it takes time and it is hard.
Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling release since early february.
Given that Red Hat released 5.6 on Jan 13th, its interesting that you say Oracle had their build out on the 12th.
I meant to say january 20th, another lapsus on my part:
http://blogs.oracle.com/linux/2011/01/oracle_linux_56_now_available.html
And I think its also quite clear that we don't really give a rat's ass about what Oracle or SciLinux are doing.
Then Johnny shouldn't have brought it up, should he ? I was simply filling in the facts.
For those without a LWN subscription, the discussion was mentioned on LWN:
http://lwn.net/SubscriberLink/429364/d1bdc6e1e6e58d0b/
which, incidentally, is where I got that Oracle release date from.
On 02/24/2011 10:52 PM, Dag Wieers wrote:
For those without a LWN subscription, the discussion was mentioned on LWN:
http://lwn.net/SubscriberLink/429364/d1bdc6e1e6e58d0b/which, incidentally, is where I got that Oracle release date from.
Quality of lwn.net isnt quite what it used to be :/ there are so many factual mistakes in that piece.
- KB
On 02/24/2011 03:34 PM, Dag Wieers wrote:
On Thu, 24 Feb 2011, Johnny Hughes wrote:
Why isn't SL released yet ... why did Oracle only release it last week ... because it takes time and it is hard.
Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling release since early february.
They (SL) do not recommend rolling in production ... we don't release things we don't want used in production. There is nothing wrong with either approach, but it is not fair to compare a final release to a beta/alpha release.
On Wed, Feb 16, 2011 at 4:03 PM, Dag Wieers dag@wieers.com wrote:
One is not expected to criticize on this list. All is well. Don't ask any uncomfortable questions please ! It's normal for a RHEL rebuild to be months behind the original. It has never been different for years. Either shut up or pay for the real thing. The developers are doing the best they can. Again all is well. Don't believe the non-believers.
Dag,
One can read that you are very prolific and that there is a community of developers who help you with your transparent process.
What is the URL that describes your process?
kind regards/ldv/vaden@texoma.net --- Transaction ID: 2V060708WB590000G (2/8/06)
On Fri, 18 Feb 2011, Larry Vaden wrote:
On Wed, Feb 16, 2011 at 4:03 PM, Dag Wieers dag@wieers.com wrote:
One is not expected to criticize on this list. All is well. Don't ask any uncomfortable questions please ! It's normal for a RHEL rebuild to be months behind the original. It has never been different for years. Either shut up or pay for the real thing. The developers are doing the best they can. Again all is well. Don't believe the non-believers.
One can read that you are very prolific and that there is a community of developers who help you with your transparent process.
What is the URL that describes your process?
Hi Larry,
Everything is available from:
we have a viewvc front-end and a mailinglist to keep track of changes here:
http://svn.rpmforge.net/viewvc/ http://lists.rpmforge.net/mailman/listinfo/svn-commits
And there are mailinglists to suggest changes or discuss packages. But at least everything is shared.
We don't have the community size, nor the infrastructure, nor the financial baggage that CentOS has, so it may not be a good comparison.
On 2/18/2011 8:28 AM, Dag Wieers wrote:
Everything is available from:
http://svn.rpmforge.net/svn/we have a viewvc front-end and a mailinglist to keep track of changes here:
http://svn.rpmforge.net/viewvc/ http://lists.rpmforge.net/mailman/listinfo/svn-commitsAnd there are mailinglists to suggest changes or discuss packages. But at least everything is shared.
I would like to say that in my opinion the system mentioned above sounds better than what there is now, for outsiders.
Now, I don't want outsiders to have access to the GPG keys, nor the ability to push out new versions, but being able to see the source tree as it is, and being able to download a mock config + setup instructions would go a long way (again in my opinion).
Forgive my naivete, but what is preventing us from doing such a thing? Is this a lack of manpower/resources to set it up, or is this more political as in; we don't want other rhel based distros to steal our juju?
For those about to say, help out or don't; I have helped out. I did a handful of patches last month after reverse engineering the process (http://thread.gmane.org/gmane.linux.centos.devel/6903/). Fast forward a month, and none of the bug ids where I posted patches on have had so much as their status changed. Before you jump down my throat on that, I realize the priority was/is Centos 5.6 etc...
I do believe that if we had a system similar to what Dag is using; someone in the Centos community would have tried the patches I made, maybe they didn't work and I needed to fix something or maybe they fix it and upload a better version. I think progress would have been made that wouldn't have detracted from the centos-devel's focus.
On 02/19/2011 01:31 AM, . wrote:
On 2/18/2011 8:28 AM, Dag Wieers wrote:
Everything is available from:
http://svn.rpmforge.net/svn/we have a viewvc front-end and a mailinglist to keep track of changes here:
http://svn.rpmforge.net/viewvc/ http://lists.rpmforge.net/mailman/listinfo/svn-commitsAnd there are mailinglists to suggest changes or discuss packages. But at least everything is shared.
I would like to say that in my opinion the system mentioned abovesounds better than what there is now, for outsiders.
Now, I don't want outsiders to have access to the GPG keys, nor theability to push out new versions, but being able to see the source tree as it is, and being able to download a mock config + setup instructions would go a long way (again in my opinion).
Forgive my naivete, but what is preventing us from doing such athing? Is this a lack of manpower/resources to set it up, or is this more political as in; we don't want other rhel based distros to steal our juju?
We release our SRPMS, that is our juju. Every patch is there for the looking.
I have tried to explain, over and over again. You guys are trying to make the process different than it is.
For most projects where RPMS are produced, you are getting an upstream tar ball that may or may not have a spec file ... you are creating spec file, you are creating lots of patches to change where WWW pages go or what directory things get installed in, etc.
That is not the case with CentOS ... all of those changes are already in the "SRPM Source Tree". Our #1 goal (by far) is to be able to use that SRPM package exactly as it is ... to clone it and make our rendering of it as identical as possible to the original.
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
For example, here is a problem that I had to solve for 4.9 yesterday. There is a hidden build requirement that the package gnome-volume-manager requires perl-XML-Parser to be in the mock build root for the package to build properly. This is NOT called out in the SRPM. We need to add it to the tree to build this package ... BUT, we do not modify the SRPM to make this happen, we instead modify the build root, and submit a BUG upstream for them to potentially fix this package.
Since our goal is NOT to change upstream packages at all, this would not show up in this "SVN" or "GIT" tree of all the packages ... since we do not change (or want to change) the package that upstream has produced. In any other project besides CentOS, the fix would take 1 minute, it would be to add a "Build Requires: perl-XML-Parser" to the spec file in the SVN repo and regenerate the SRPM package.
So, this time consuming tree that you want guys want us to create is not worth a hill of beans and adds nothing for the vast majority of packages, since the SRPM is unmodified from upstream.
You have everything you need already in the SRPM.
For those about to say, help out or don't; I have helped out. I dida handful of patches last month after reverse engineering the process (http://thread.gmane.org/gmane.linux.centos.devel/6903/). Fast forward a month, and none of the bug ids where I posted patches on have had so much as their status changed. Before you jump down my throat on that, I realize the priority was/is Centos 5.6 etc...
I do believe that if we had a system similar to what Dag is using;someone in the Centos community would have tried the patches I made, maybe they didn't work and I needed to fix something or maybe they fix it and upload a better version. I think progress would have been made that wouldn't have detracted from the centos-devel's focus.
What makes you think that we HAVE a "split" source tree?
CentOS builds someone else's SRPMS ... that IS our source tree, the SRPMS that are produced upstream.
We only change a handful of SRPMS (the ones that are labeled .centos). We are not creating these packages, and in fact it is desirable that they do not change at all.
We would be creating extra work to break down the SRPMS into their component parts and create this so called source tree.
What would be the benefit of all this extra work since we do not change the vast majority of the packages.
On Sat, Feb 19, 2011 at 4:17 AM, Johnny Hughes johnny@centos.org wrote:
For example, here is a problem that I had to solve for 4.9 yesterday. There is a hidden build requirement that the package gnome-volume-manager requires perl-XML-Parser to be in the mock build root for the package to build properly. This is NOT called out in the SRPM. We need to add it to the tree to build this package ... BUT, we do not modify the SRPM to make this happen, we instead modify the build root, and submit a BUG upstream for them to potentially fix this package.
Johnny,
Although one can read on this list that you are no longer with the CentOS Team, we are glad to hear that you are still on the CentOS Team.
Is what you describe above what Lamar describes on this list as sniggles?
What do you think is the root cause of such things @ the upstream?
kind regards/ldv/vaden@texoma.net
Following Troy's style manual,
p.s. In an effort to rid our site of proprietary backup for Windows boxen in favor of OSS backup, we ran into more or less the same thing with rsync (compilation errors in the BSD environs for revs > 2.6.8). This _may_ explain why RH5 uses rsync-2.6.8.
On 02/19/2011 06:34 AM, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 4:17 AM, Johnny Hughes johnny@centos.org wrote:
For example, here is a problem that I had to solve for 4.9 yesterday. There is a hidden build requirement that the package gnome-volume-manager requires perl-XML-Parser to be in the mock build root for the package to build properly. This is NOT called out in the SRPM. We need to add it to the tree to build this package ... BUT, we do not modify the SRPM to make this happen, we instead modify the build root, and submit a BUG upstream for them to potentially fix this package.
Johnny,
Although one can read on this list that you are no longer with the CentOS Team, we are glad to hear that you are still on the CentOS Team.
Is what you describe above what Lamar describes on this list as sniggles?
Well, I would say that the root cause of the problem is that they are somehow manually adding things to the buildroot for these packages. Why or how it happens (as in the process) I have no idea.
If all packages had to build in an automated system, if that automated system had to have one minimum build root and if nothing was allowed to be installed in a buildroot external to the spec file then this sort of thing could not happen.
Obviously they have a way to do some or all of the following:
1. Add some kind of "hinting" to the build system that is external to the SRPM.
2. A manual way to add packages from inside the build root if the package fails to build ... then rerun the package and not update the SPEC after completion.
3. Varying minimum buildroots for specific packages that do not follow the normal minimum buildroots.
What do you think is the root cause of such things @ the upstream?
What causes it is that they do not require the SRPM to stand alone and do the installs on an automated, single setup, single minimum buildroot system.
Why? No idea.
On Sat, Feb 19, 2011 at 7:38 AM, Johnny Hughes johnny@centos.org wrote:
What causes it is that they do not require the SRPM to stand alone and do the installs on an automated, single setup, single minimum buildroot system.
Why? No idea.
We all stand on the shoulders of the OSS giants who write the code which we run.
YOMV, but to this poster it appears that RH has helped itself to a ladder to put atop the shoulders of the giants.
legal@redhat.com should order their troops to stop short shipping the SRPMS and make the SRPMS stand alone without sniggles (Lamar's choice of a descriptive term).
regards/ldv/vaden@texoma.net
On Sat, Feb 19, 2011 at 7:38 AM, Johnny Hughes johnny@centos.org wrote:
Well, I would say that the root cause of the problem is that they are somehow manually adding things to the buildroot for these packages. Why or how it happens (as in the process) I have no idea.
If all packages had to build in an automated system, if that automated system had to have one minimum build root and if nothing was allowed to be installed in a buildroot external to the spec file then this sort of thing could not happen.
Johnny,
Have you ever seen a case where instead of modifying the build root you modified the .src.rpm and couldn't reach binary compatibility?
On 02/19/2011 09:46 AM, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 7:38 AM, Johnny Hughes johnny@centos.org wrote:
Well, I would say that the root cause of the problem is that they are somehow manually adding things to the buildroot for these packages. Why or how it happens (as in the process) I have no idea.
If all packages had to build in an automated system, if that automated system had to have one minimum build root and if nothing was allowed to be installed in a buildroot external to the spec file then this sort of thing could not happen.
Johnny,
Have you ever seen a case where instead of modifying the build root you modified the .src.rpm and couldn't reach binary compatibility?
No, if we changed it, we would be compatible with the RPMS. But we do not want to change except for trademarks.
----- Original Message -----
Well, I would say that the root cause of the problem is that they are somehow manually adding things to the buildroot for these packages. Why or how it happens (as in the process) I have no idea.
If all packages had to build in an automated system, if that automated system had to have one minimum build root and if nothing was allowed to be installed in a buildroot external to the spec file then this sort of thing could not happen.
Obviously they have a way to do some or all of the following:
- Add some kind of "hinting" to the build system that is external to
the SRPM.
- A manual way to add packages from inside the build root if the
package fails to build ... then rerun the package and not update the SPEC after completion.
- Varying minimum buildroots for specific packages that do not follow
the normal minimum buildroots.
So, if someone could provide a build system that would allow altering of build requirements outside of the SPEC file, in such a way that those build requirements were recorded for later use, that would be useful to the CentOS maintainers? What if the build system wasn't mock?
I've been considering doing a rebuild of RHEL this way using rPath's "rMake" build system. The build system is meant to create conary packages, not rpm, but having it produce rpm artifacts as part of a conary package is trivial.
There's a little bit of work to be done (mostly to parse spec files and pull out the build reqs which *are* in the SPEC file, which should be easy), and it's a pretty significant change from how you guys are building things now, but it seems like the appropriate time to toss the information out there just to see if there's any interest. (There a decent chance that I'll be working on this within the next couple of months regardless of interest, but knowing that someone else might contribute or benefit from it helps for motivation...)
--Andy
On Saturday, February 19, 2011 11:14:37 am Andy Grimm wrote:
There's a little bit of work to be done (mostly to parse spec files and pull out the build reqs which *are* in the SPEC file, which should be easy), and it's a pretty significant change from how you guys are building things now, but it seems like the appropriate time to toss the information out there just to see if there's any interest. (There a decent chance that I'll be working on this within the next couple of months regardless of interest, but knowing that someone else might contribute or benefit from it helps for motivation...)
This work has been done; it's called koji.
From my quick reading this morning, it's probably a safe speculation that RHEL6 was built with a Red Hat-internal koji instance. ( http://www.redhat.com/archives/epel-devel-list/2010-December/msg00128.html )
Koji is proven technology; it gets a continuous workout building Fedora.
And it has a learning curve; perhaps working through the problem the hard way first could be educational; perhaps seeing how a large extremely open project went about it could be just as educational, it depends upon what you want to learn, and where you want to spend your time.
On 02/19/2011 04:14 PM, Andy Grimm wrote:
So, if someone could provide a build system that would allow altering of build requirements outside of the SPEC file, in such a way that those build requirements were recorded for later use, that would be useful to the CentOS maintainers? What if the build system wasn't mock?
As I mentioned sometime in Nov last year ( or was it Dec ? ) and we have done many times in the past, we have run ( since 2006 ? ) and continue to run a basic system that has dynamic buildroots. Think of it as an 'everything install' that is used to run rpmbuilds inside it.
- KB
On 2/19/11 6:38 AM, Johnny Hughes wrote:
- Add some kind of "hinting" to the build system that is external to
the SRPM.
- A manual way to add packages from inside the build root if the
package fails to build ... then rerun the package and not update the SPEC after completion.
- Varying minimum buildroots for specific packages that do not follow
the normal minimum buildroots.
Forget my previous message, it sounds like you're on the same page. :)
Steve
On 2/19/11 3:17 AM, Johnny Hughes wrote:
Since our goal is NOT to change upstream packages at all, this would not show up in this "SVN" or "GIT" tree of all the packages ... since we do not change (or want to change) the package that upstream has produced. In any other project besides CentOS, the fix would take 1 minute, it would be to add a "Build Requires: perl-XML-Parser" to the spec file in the SVN repo and regenerate the SRPM package.
Would it make sense to have a script that preps the build system for building a certain package, and maintain individual scripts or configurations for each package? These configurations would prepare the build environment itself rather than modifying the SRPM. It seems like this would help build for multiple architectures, as well as help with future package builds. Ideally, it would probably have you be able to choose how much of the configuration to follow, so you can try new SRPMS without the config to see if they've been fixed.
Steve
Am 19.02.11 17:43, schrieb Steve Meyers:
Would it make sense to have a script that preps the build system for building a certain package, and maintain individual scripts or configurations for each package? These configurations would prepare the build environment itself rather than modifying the SRPM.
The problem is that in the case where CentOS needs to change the packages, the SRPMS which CentOS provides also need to be changed, as they cannot be redistributed without the changes. But maybe I am not really understanding the problem which is being tried to solve here. The already changed RPMs are easy to discern from the not-needed-to-change RPMs, as they have a ".centos." in the naming.
Ralph
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
On Sat, Feb 19, 2011 at 6:32 PM, Dag Wieers dag@wieers.com wrote:
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
Hi Dag,
Help this old former ASR33 operator understand, please: are you saying
1) the changes aren't called out in the bug report to the upstream -or- 2) the bug reports to the upstream aren't timely -or- 3) your choice of words.
In your operation of the very well known rpmforge repo, if you encountered an example like Johnny mentioned, namely an incomplete/incorrect SRPM, unlike the constraints on CentOS developers, do you have the freedom to modify the SRPM and thus run a constant build environment?
Or is it the case that you _always_build your own SRPMS?
Regardless of why, are there cases where you have to make adjustments to the build environment in order to get a clean compile/binary?
If so, how do you document said?
Have you already migrated to koji or are you planning to _or_?
kind regards/ldv/vaden@texoma.net
On Sat, 19 Feb 2011, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 6:32 PM, Dag Wieers dag@wieers.com wrote:
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
Hi Dag,
Help this old former ASR33 operator understand, please: are you saying
- the changes aren't called out in the bug report to the upstream
-or- 2) the bug reports to the upstream aren't timely -or- 3) your choice of words.
You cut away the meat of my message and focussed on the least important bit, the non-transparency. I am more interested how we can do a better job in the future.
Remind you that we have had the same discussions on this list in the past, including the promises that it would be better in the future. And here we are again and the situation is worse than it ever was.
So:
4) CentOS is not able to release CentOS 5.6 after 2 months and nobody is allowed to be critical about it.
(Despite the fact that the effort to rebuild CentOS 5.6 packages is a lot easier than CentOS 6.0 which is already 3 months late)
5) The same 3 people are responsible for CentOS 4, CentOS 5 and CentOS 6. What's more, the fact that there would be three update releases in 3 months was predictable.
So despite all the automation, QA team, past promises and whatnot, we are not doing a better job today and I had hoped at least some people would agree instead of denying there's something wrong with the process and blaming the non-volunteers/community for even bringing it up.
And despite what some people may think, I am not _against_ CentOS, in fact the only reason why I am bringing it up is because * I * still * care !
On 02/20/2011 06:11 AM, Dag Wieers wrote:
On Sat, 19 Feb 2011, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 6:32 PM, Dag Wieers dag@wieers.com wrote:
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
Hi Dag,
Help this old former ASR33 operator understand, please: are you saying
- the changes aren't called out in the bug report to the upstream
-or- 2) the bug reports to the upstream aren't timely -or- 3) your choice of words.
You cut away the meat of my message and focussed on the least important bit, the non-transparency. I am more interested how we can do a better job in the future.
Remind you that we have had the same discussions on this list in the past, including the promises that it would be better in the future. And here we are again and the situation is worse than it ever was.
So:
- CentOS is not able to release CentOS 5.6 after 2 months and nobody is allowed to be critical about it.
You call what you are doing NON-CRITICAL? I think you are not only allowed, but are being QUITE CRITICAL about it. I wonder how understanding and nice YOU would be if I came to YOUR mailing list and showed the same level of CRITICALNESS towards something there.
(Despite the fact that the effort to rebuild CentOS 5.6 packages is a lot easier than CentOS 6.0 which is already 3 months late)
- The same 3 people are responsible for CentOS 4, CentOS 5 and CentOS 6. What's more, the fact that there would be three update releases in 3 months was predictable.
So despite all the automation, QA team, past promises and whatnot, we are not doing a better job today and I had hoped at least some people would agree instead of denying there's something wrong with the process and blaming the non-volunteers/community for even bringing it up.
And despite what some people may think, I am not _against_ CentOS, in fact the only reason why I am bringing it up is because * I * still * care !
Thank you for your concern.
Oracle does not have the same issues and they just released their product. SL has not released a final version of their 5.6 or 6.0 either. Maybe you should put this in perspective.
Le 20/02/2011 16:31, Johnny Hughes a écrit :
On 02/20/2011 06:11 AM, Dag Wieers wrote:
On Sat, 19 Feb 2011, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 6:32 PM, Dag Wieers dag@wieers.com wrote:
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
Hi Dag,
Help this old former ASR33 operator understand, please: are you saying
- the changes aren't called out in the bug report to the upstream
-or- 2) the bug reports to the upstream aren't timely -or- 3) your choice of words.
You cut away the meat of my message and focussed on the least important bit, the non-transparency. I am more interested how we can do a better job in the future.
Remind you that we have had the same discussions on this list in the past, including the promises that it would be better in the future. And here we are again and the situation is worse than it ever was.
So:
- CentOS is not able to release CentOS 5.6 after 2 months and nobody is allowed to be critical about it.
You call what you are doing NON-CRITICAL? I think you are not only allowed, but are being QUITE CRITICAL about it. I wonder how understanding and nice YOU would be if I came to YOUR mailing list and showed the same level of CRITICALNESS towards something there.
(Despite the fact that the effort to rebuild CentOS 5.6 packages is a lot easier than CentOS 6.0 which is already 3 months late)
- The same 3 people are responsible for CentOS 4, CentOS 5 and CentOS 6. What's more, the fact that there would be three update releases in 3 months was predictable.
So despite all the automation, QA team, past promises and whatnot, we are not doing a better job today and I had hoped at least some people would agree instead of denying there's something wrong with the process and blaming the non-volunteers/community for even bringing it up.
And despite what some people may think, I am not _against_ CentOS, in fact the only reason why I am bringing it up is because * I * still * care !
Thank you for your concern.
Oracle does not have the same issues and they just released their product. SL has not released a final version of their 5.6 or 6.0 either. Maybe you should put this in perspective.
Hello,
Could I ask a simple question: When the Centos6 build (for i386 or x86_64) was release / build at 100% (or close) ?
Regards,
js.
On 02/20/2011 06:37 AM, jean-seb wrote:
Le 20/02/2011 16:31, Johnny Hughes a écrit :
On 02/20/2011 06:11 AM, Dag Wieers wrote:
On Sat, 19 Feb 2011, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 6:32 PM, Dag Wieers dag@wieers.com wrote:
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
Hi Dag,
Help this old former ASR33 operator understand, please: are you saying
- the changes aren't called out in the bug report to the upstream
-or- 2) the bug reports to the upstream aren't timely -or- 3) your choice of words.
You cut away the meat of my message and focussed on the least important bit, the non-transparency. I am more interested how we can do a better job in the future.
Remind you that we have had the same discussions on this list in the past, including the promises that it would be better in the future. And here we are again and the situation is worse than it ever was.
So:
- CentOS is not able to release CentOS 5.6 after 2 months and nobody is allowed to be critical about it.
You call what you are doing NON-CRITICAL? I think you are not only allowed, but are being QUITE CRITICAL about it. I wonder how understanding and nice YOU would be if I came to YOUR mailing list and showed the same level of CRITICALNESS towards something there.
(Despite the fact that the effort to rebuild CentOS 5.6 packages is a lot easier than CentOS 6.0 which is already 3 months late)
- The same 3 people are responsible for CentOS 4, CentOS 5 and CentOS 6. What's more, the fact that there would be three update releases in 3 months was predictable.
So despite all the automation, QA team, past promises and whatnot, we are not doing a better job today and I had hoped at least some people would agree instead of denying there's something wrong with the process and blaming the non-volunteers/community for even bringing it up.
And despite what some people may think, I am not _against_ CentOS, in fact the only reason why I am bringing it up is because * I * still * care !
Thank you for your concern.
Oracle does not have the same issues and they just released their product. SL has not released a final version of their 5.6 or 6.0 either. Maybe you should put this in perspective.
Hello,
Could I ask a simple question: When the Centos6 build (for i386 or x86_64) was release / build at 100% (or close) ?
If your question is, when will the CentOS6 build for i386 or x86_64 be released ... and if you want a hard date, well I can not give you one.
It will be released the DAY we get a build that passes all our checks that I pointed to here:
http://mirror.centos.org/centos-4/4/build/distro/tmverifyrpms
We will then move it to QA where it will be tested.
Once it is tested (and we fix any issues), it will be released.
It might be 2 weeks from now or 2 months from now. I would like to think it will be closer to 2 weeks, but it will be completed when it gets completed.
I would point out that the original "REAL" CentOS release (version 3.1) took about 6-7 months, from sometime in October 2003 (when development started ) until March 19th, 2004 when there was a release.
Le 20/02/2011 16:56, Johnny Hughes a écrit :
On 02/20/2011 06:37 AM, jean-seb wrote:
Le 20/02/2011 16:31, Johnny Hughes a écrit :
On 02/20/2011 06:11 AM, Dag Wieers wrote:
On Sat, 19 Feb 2011, Larry Vaden wrote:
On Sat, Feb 19, 2011 at 6:32 PM, Dag Wieers dag@wieers.com wrote:
On Sat, 19 Feb 2011, Johnny Hughes wrote:
> For the vast majority of packages, we make no changes. We rebuild it > and test it. If the binary passes the test, we use it. If the binary > does not pass the test we troubleshoot and figure out why it does not > pass the test ... and we change things OUTSIDE the SRPM to fix the > problem. Yes, and those changes are closed.
Hi Dag,
Help this old former ASR33 operator understand, please: are you saying
- the changes aren't called out in the bug report to the upstream
-or- 2) the bug reports to the upstream aren't timely -or- 3) your choice of words.
You cut away the meat of my message and focussed on the least important bit, the non-transparency. I am more interested how we can do a better job in the future.
Remind you that we have had the same discussions on this list in the past, including the promises that it would be better in the future. And here we are again and the situation is worse than it ever was.
So:
- CentOS is not able to release CentOS 5.6 after 2 months and nobody is allowed to be critical about it.
You call what you are doing NON-CRITICAL? I think you are not only allowed, but are being QUITE CRITICAL about it. I wonder how understanding and nice YOU would be if I came to YOUR mailing list and showed the same level of CRITICALNESS towards something there.
(Despite the fact that the effort to rebuild CentOS 5.6 packages is a lot easier than CentOS 6.0 which is already 3 months late)
- The same 3 people are responsible for CentOS 4, CentOS 5 and CentOS 6. What's more, the fact that there would be three update releases in 3 months was predictable.
So despite all the automation, QA team, past promises and whatnot, we are not doing a better job today and I had hoped at least some people would agree instead of denying there's something wrong with the process and blaming the non-volunteers/community for even bringing it up.
And despite what some people may think, I am not _against_ CentOS, in fact the only reason why I am bringing it up is because * I * still * care !
Thank you for your concern.
Oracle does not have the same issues and they just released their product. SL has not released a final version of their 5.6 or 6.0 either. Maybe you should put this in perspective.
Hello,
Could I ask a simple question: When the Centos6 build (for i386 or x86_64) was release / build at 100% (or close) ?
If your question is, when will the CentOS6 build for i386 or x86_64 be released ... and if you want a hard date, well I can not give you one.
It will be released the DAY we get a build that passes all our checks that I pointed to here:
http://mirror.centos.org/centos-4/4/build/distro/tmverifyrpms
We will then move it to QA where it will be tested.
Once it is tested (and we fix any issues), it will be released.
It might be 2 weeks from now or 2 months from now. I would like to think it will be closer to 2 weeks, but it will be completed when it gets completed.
I would point out that the original "REAL" CentOS release (version 3.1) took about 6-7 months, from sometime in October 2003 (when development started ) until March 19th, 2004 when there was a release.
No no, I would like to know the date you had build it "almost" completely (there is some @$§! packages that are hard to build using mock), It's to have a reference into the "initial build" (buggy but close to be build) and the first "alpha release", specially for Centos6.
Regards,
js.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 02/20/2011 01:07 PM, jean-seb wrote:
No no, I would like to know the date you had build it "almost" completely (there is some @$§! packages that are hard to build using mock), It's to have a reference into the "initial build" (buggy but close to be build) and the first "alpha release", specially for Centos6.
We have been over this in the past a few times. What would you hope to achieve from this alpha release ? The goal for centos isnt to be 'almost there', its about a platform that meets a certain spec.
- KB
On Sun, 20 Feb 2011, Johnny Hughes wrote:
Could I ask a simple question: When the Centos6 build (for i386 or x86_64) was release / build at 100% (or close) ?
It might be 2 weeks from now or 2 months from now. I would like to think it will be closer to 2 weeks, but it will be completed when it gets completed.
Johnny,
So it's absolutely normal a CentOS 5.6 release is 10 weeks late and there's no intent to speed up the process to lower the time to do future releases ?
If that is the case, we might want to make that more clear on the wiki, eg. in my CentOS introduction presentation from 2008 we still mention that releases are (up to) 4 weeks behind RHEL.
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
On Sun, 2011-02-20 at 18:13 +0100, Dag Wieers wrote:
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
I would say that is a good point 10 weeks without security updates is a black eye for the project.
On Feb 20, 2011, at 12:29 PM, lostson wrote:
On Sun, 2011-02-20 at 18:13 +0100, Dag Wieers wrote:
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
I would say that is a good point 10 weeks without security updates is a black eye for the project.
So wear an eye-patch and try a tin-foil hat to secure your thoughts.
Truly: this thread -- and the need to repond/snser -- are what is delaying CentOS releasing 5.6 and 6.0.
There's nothing wrong with post-mortem anaylysis, and there's nothing wrong with doing that transparently, but isn't the real issue here
Where are the package and the release?
And that means that Getting Things Done is more important than the rest.
I'll be quiet now ... but this thread went noplace several times historically and there is no hope of final answers here.
73 de Jeff
On Sun, 2011-02-20 at 12:34 -0500, Jeff Johnson wrote:
On Feb 20, 2011, at 12:29 PM, lostson wrote:
On Sun, 2011-02-20 at 18:13 +0100, Dag Wieers wrote:
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
I would say that is a good point 10 weeks without security updates is a black eye for the project.
So wear an eye-patch and try a tin-foil hat to secure your thoughts.
Oh wow can you feel the love, thanks Jeff
On 02/20/2011 05:29 PM, lostson wrote:
I would say that is a good point 10 weeks without security updates is a black eye for the project.
how did you work out 5.6 is 10 weeks late ? Secondly, what are these critical security updates you speak of ?
have you actually *looked* at the updates so far ?
- KB
Hello Karanbir,
On Mon, 2011-02-21 at 15:23 +0000, Karanbir Singh wrote:
Secondly, what are these critical security updates you speak of ?
Arguably not "critical" as per RHs vulnerability levels, but still "important":
krb5-1.6.1-55.el5.src.rpm 2010-12-03(!!) https://rhn.redhat.com/errata/RHSA-2010-0926.html (that's 5.5, where my 5.5 system only has krb5-libs-1.6.1-36.el5_5.6)
krb5-1.6.1-55.el5_6.1.src.rpm 2011-02-04 https://rhn.redhat.com/errata/RHSA-2011-0199.html (that's 5.6)
And presumably every security update released since January 17th, amongst others: kernel-2.6.18-238.1.1.el5.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0163.html), libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html), openoffice.org-3.1.1-19.5.el5_5.6.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0182.html)
Regards, Leonard.
On Mon, 2011-02-21 at 20:44 +0100, Leonard den Ottolander wrote:
libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html),
The correct SRPM for 5 being: libuser-0.54.7-2.1.el5_5.2.src.rpm , CentOS-4 actually is up to date wrt this update.
On Feb 21, 2011, at 2:50 PM, Leonard den Ottolander wrote:
On Mon, 2011-02-21 at 20:44 +0100, Leonard den Ottolander wrote:
libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html),
The correct SRPM for 5 being: libuser-0.54.7-2.1.el5_5.2.src.rpm , CentOS-4 actually is up to date wrt this update.
Updates for both RHEL and CentOS are dead fish in a barrel on the web.
Why not set up a web page listing any packages that RHEL has that CentOS does not?
Endless recitations of out-of-date and available are just a foggy blur, lacking even US Homeland security BLUE <-> GREEN <-> PURPLE <-> LAVENDAR <-> color coding to minimize info overload.
For extra credit: Calculate and display the lag between RHEL <-> CentOS releasing.
And for those who simply MUST_BASH_CENTOS: mark all CentOS deficiencies in *BLINKING* RED 48pt type
It likely isn't an enormous amount of PHP to get that job done. Alas C, not PHP, here, until I get to the RPM+PHP embedding todo++.
hth
73 de Jeff
On Mon, Feb 21, 2011 at 1:58 PM, Jeff Johnson n3npq@mac.com wrote:
On Feb 21, 2011, at 2:50 PM, Leonard den Ottolander wrote:
On Mon, 2011-02-21 at 20:44 +0100, Leonard den Ottolander wrote:
libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html),
The correct SRPM for 5 being: libuser-0.54.7-2.1.el5_5.2.src.rpm , CentOS-4 actually is up to date wrt this update.
Updates for both RHEL and CentOS are dead fish in a barrel on the web.
Yes, clearly the intent is to distract list members from the key issues of the thread. "Look, over there, dead fish in a barrel. Research them, and report back with your findings." :-)
jerry
On Feb 21, 2011, at 3:11 PM, Jerry Amundson wrote:
On Mon, Feb 21, 2011 at 1:58 PM, Jeff Johnson n3npq@mac.com wrote:
On Feb 21, 2011, at 2:50 PM, Leonard den Ottolander wrote:
On Mon, 2011-02-21 at 20:44 +0100, Leonard den Ottolander wrote:
libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html),
The correct SRPM for 5 being: libuser-0.54.7-2.1.el5_5.2.src.rpm , CentOS-4 actually is up to date wrt this update.
Updates for both RHEL and CentOS are dead fish in a barrel on the web.
Yes, clearly the intent is to distract list members from the key issues of the thread. "Look, over there, dead fish in a barrel. Research them, and report back with your findings." :-)
A web-page comparing the current differences between RHEL <-> CentOS is more informative and more useful (and likely more accurate, no additional e-mail straightening out which krb5 version it _REALLY_ was) than the current traffic through e-mail.
I have no clear intents, give it up.
73 de Jeff
On Mon, Feb 21, 2011 at 2:20 PM, Jeff Johnson n3npq@mac.com wrote:
On Feb 21, 2011, at 3:11 PM, Jerry Amundson wrote:
On Mon, Feb 21, 2011 at 1:58 PM, Jeff Johnson n3npq@mac.com wrote:
On Feb 21, 2011, at 2:50 PM, Leonard den Ottolander wrote:
On Mon, 2011-02-21 at 20:44 +0100, Leonard den Ottolander wrote:
libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html),
The correct SRPM for 5 being: libuser-0.54.7-2.1.el5_5.2.src.rpm , CentOS-4 actually is up to date wrt this update.
Updates for both RHEL and CentOS are dead fish in a barrel on the web.
Yes, clearly the intent is to distract list members from the key issues of the thread. "Look, over there, dead fish in a barrel. Research them, and report back with your findings." :-)
A web-page comparing the current differences between RHEL <-> CentOS is more informative and more useful (and likely more accurate, no additional e-mail straightening out which krb5 version it _REALLY_ was) than the current traffic through e-mail.
I have no clear intents, give it up.
Sorry, lazy wording on my part - my context wasn't directed toward you, it was directed towards KB playing the "what are these critical security updates you speak of ?" card. I just also liked the dead fish in a barrel "visual". :-)
jerry
On 02/21/2011 07:50 PM, Leonard den Ottolander wrote:
On Mon, 2011-02-21 at 20:44 +0100, Leonard den Ottolander wrote:
libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html),
The correct SRPM for 5 being: libuser-0.54.7-2.1.el5_5.2.src.rpm , CentOS-4 actually is up to date wrt this update.
I got a couple of emails about this offlist yesterday - we seem to come up against this every release, and its really been answered a few times already. Maybe we need a FAQ somewhere for this :)
all updates to the /5/ tree are monitored and anything which has a remote or local exploit will get pushed into the /5/ tree; things in 5.6 and against 5.6 that dont meet that criteria wait for 5.6 release. build order, linking, inheriting upstream testing etc etc to blame.
- KB
On 22 February 2011 10:20, Karanbir Singh mail-lists@karan.org wrote:
On 02/21/2011 07:50 PM, Leonard den Ottolander wrote:
libuser-0.52.5-1.1.el4_8.1.src.rpm (https://rhn.redhat.com/errata/RHSA-2011-0170.html),
The correct SRPM for 5 being: libuser-0.54.7-2.1.el5_5.2.src.rpm , CentOS-4 actually is up to date wrt this update.
I got a couple of emails about this offlist yesterday - we seem to come up against this every release, and its really been answered a few times already. Maybe we need a FAQ somewhere for this :)
We also see this being raised on the fora at every point release. A wiki FAQ entry would be a good idea.
Calling Phil (Schaffner) -- A little job for you. ;-)
Alan.
On Mon, Feb 21, 2011 at 11:44 AM, Leonard den Ottolander leonard@den.ottolander.nl wrote:
Arguably not "critical" as per RHs vulnerability levels, but still "important":
krb5-1.6.1-55.el5.src.rpm 2010-12-03(!!) https://rhn.redhat.com/errata/RHSA-2010-0926.html (that's 5.5, where my 5.5 system only has krb5-libs-1.6.1-36.el5_5.6)
Actually, krb5 for CentOS 5.5 is up-to-date as far as I can see. The version referenced above is for 5.6.
However, there are some pending updates for CentOS *5.5*. For details, see this bug report:
http://bugs.centos.org/view.php?id=4689
Hopefully they will come out soon.
Akemi
Hello Akemi,
On Mon, 2011-02-21 at 12:04 -0800, Akemi Yagi wrote:
krb5-1.6.1-55.el5.src.rpm 2010-12-03(!!) https://rhn.redhat.com/errata/RHSA-2010-0926.html (that's 5.5, where my 5.5 system only has krb5-libs-1.6.1-36.el5_5.6)
Actually, krb5 for CentOS 5.5 is up-to-date as far as I can see.
No! The version above is 5.5, the one I mentioned below that is 5.6. For 5 we are currently using 1.6.1-36.el5_5.6 where 1.6.1-55.el5 was released 2010-12-03 by Red Hat, just 2 days after CentOS released the previous.
Regards, Leonard.
Hello Akemi,
On Mon, 2011-02-21 at 21:16 +0100, Leonard den Ottolander wrote:
Actually, krb5 for CentOS 5.5 is up-to-date as far as I can see.
No! The version above is 5.5,
Oops. Sorry for the mixup, you are correct. 1.6.1-36.el5_5.6 is indeed the 2010-12-01 update. It's the date on the krb5-1.6.1-55.el5.src.rpm which is much earlier than the release date of 5.6 that confused me.
Regards, Leonard.
On 02/20/2011 06:13 PM, Dag Wieers wrote:
So it's absolutely normal a CentOS 5.6 release is 10 weeks late and there's no intent to speed up the process to lower the time to do future releases ?
If that is the case, we might want to make that more clear on the wiki, eg. in my CentOS introduction presentation from 2008 we still mention that releases are (up to) 4 weeks behind RHEL.
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
Right, but as you said so in your multiple CentOS presentations, there are no warranty nor SLA on a delivery time : IIRC you explained that very clearly in the Pros/Cons slides between RHEL and CentOS ;-)
Working a little bit behind the scene and knowing the CentOS developers, i'm quite astonished that all the people complaining about the 'delay' always think about technical issues that CentOS developers have to deal with and not with their personal problems they have to deal with ... Until now i've *never* seen any comment like 'we hope that everything is ok on the family point-of-view' etc, etc ... I don't think that the CentOS developers want to discuss what happens in their private life, nor the problems they have to deal with at $work, etc, etc ...
And on each release it's the same thread coming. It seems to me like a 'chicken and eggs' problem : what has to be solved first ? people wanting a faster distro release or documenting it first ? Don't misunderstand me : i really would like to see the whole process documented and i think that some other members agree on that fact. (It seems SL team documents more what they are doing for example). But here is now a simple fact : consider how much time Johnny took to answer all the same questions (and even answered multiple times with the same answer) and so the time he couldn't spend on the build process itself ...
Fabian Arrotin
On Sun, 20 Feb 2011, Fabian Arrotin wrote:
On 02/20/2011 06:13 PM, Dag Wieers wrote:
So it's absolutely normal a CentOS 5.6 release is 10 weeks late and there's no intent to speed up the process to lower the time to do future releases ?
If that is the case, we might want to make that more clear on the wiki, eg. in my CentOS introduction presentation from 2008 we still mention that releases are (up to) 4 weeks behind RHEL.
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
Right, but as you said so in your multiple CentOS presentations, there are no warranty nor SLA on a delivery time : IIRC you explained that very clearly in the Pros/Cons slides between RHEL and CentOS ;-)
Fabian,
I did say that was a con for CentOS, but we did mention that security updates may be delayed for 48 hours and releases may be delayed up to 4 weeks. Both are no longer the case. We have had security updates delayed for 3 months (!) and a whole release delayed for 3 months since I wrote that presentation.
I haven't done any CentOS presentation since I left the team, but it is undeniable that despite any automation work since then releases only take longer.
Working a little bit behind the scene and knowing the CentOS developers, i'm quite astonished that all the people complaining about the 'delay' always think about technical issues that CentOS developers have to deal with and not with their personal problems they have to deal with ...
True, but there are ways to overcome those problems if, and only if, we consider this important. Up to now this was _never_ considered important. Remember: "we release it when it is ready".
That is not what users like to hear in this context, because it basically means there is no way to speed it up. There's not even a plan to look exactly what is the bottleneck and where can we improve it.
I remember one CentOS 5 release was delayed for one additional month because a single developer was getting married. We all sympathized, and something like this can (should!) happen ;-) But shouldn't the project foresee and/or protect the process from such occasions ?
In 2007 CentOS had a lower limit of about 5 million installations, that might be a lower limit of 10 million today. Maybe even a multitude ?
And on each release it's the same thread coming. It seems to me like a 'chicken and eggs' problem : what has to be solved first ? people wanting a faster distro release or documenting it first ? Don't misunderstand me : i really would like to see the whole process documented and i think that some other members agree on that fact. (It seems SL team documents more what they are doing for example). But here is now a simple fact : consider how much time Johnny took to answer all the same questions (and even answered multiple times with the same answer) and so the time he couldn't spend on the build process itself ...
That argument has been used in the past too to silence any critical voice. But as soon as the release is out, nothing seems to really happen despite any promises. And the delay is becoming longer. We used to be able to release CentOS-5 release in one month, remember ?
There's no reason that CentOS 5.6 is any more difficult than CentOS 5.0, while CentOS 5.0 (a major release !) only took 1 month to produce. Sure CentOS 6.0 is a lot bigger, but CentOS 5.6 is not, and CentOS 4.8 certainly was not.
On 02/20/2011 07:06 PM, Dag Wieers wrote:
On Sun, 20 Feb 2011, Fabian Arrotin wrote:
On 02/20/2011 06:13 PM, Dag Wieers wrote:
So it's absolutely normal a CentOS 5.6 release is 10 weeks late and there's no intent to speed up the process to lower the time to do future releases ?
If that is the case, we might want to make that more clear on the wiki, eg. in my CentOS introduction presentation from 2008 we still mention that releases are (up to) 4 weeks behind RHEL.
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
Right, but as you said so in your multiple CentOS presentations, there are no warranty nor SLA on a delivery time : IIRC you explained that very clearly in the Pros/Cons slides between RHEL and CentOS ;-)
Fabian,
I did say that was a con for CentOS, but we did mention that security updates may be delayed for 48 hours and releases may be delayed up to 4 weeks. Both are no longer the case. We have had security updates delayed for 3 months (!) and a whole release delayed for 3 months since I wrote that presentation.
*nod*
I haven't done any CentOS presentation since I left the team, but it is undeniable that despite any automation work since then releases only take longer.
Working a little bit behind the scene and knowing the CentOS developers, i'm quite astonished that all the people complaining about the 'delay' always think about technical issues that CentOS developers have to deal with and not with their personal problems they have to deal with ...
True, but there are ways to overcome those problems if, and only if, we consider this important. Up to now this was _never_ considered important. Remember: "we release it when it is ready".
That is not what users like to hear in this context, because it basically means there is no way to speed it up. There's not even a plan to look exactly what is the bottleneck and where can we improve it.
I remember one CentOS 5 release was delayed for one additional month because a single developer was getting married. We all sympathized, and something like this can (should!) happen ;-) But shouldn't the project foresee and/or protect the process from such occasions ?
Also true indeed ...
In 2007 CentOS had a lower limit of about 5 million installations, that might be a lower limit of 10 million today. Maybe even a multitude ?
And on each release it's the same thread coming. It seems to me like a 'chicken and eggs' problem : what has to be solved first ? people wanting a faster distro release or documenting it first ? Don't misunderstand me : i really would like to see the whole process documented and i think that some other members agree on that fact. (It seems SL team documents more what they are doing for example). But here is now a simple fact : consider how much time Johnny took to answer all the same questions (and even answered multiple times with the same answer) and so the time he couldn't spend on the build process itself ...
That argument has been used in the past too to silence any critical voice. But as soon as the release is out, nothing seems to really happen despite any promises. And the delay is becoming longer. We used to be able to release CentOS-5 release in one month, remember ?
Yes and once again, don't get me wrong : i'm not arguing against any critical voice or to silence comments. The fact is that $now doesn't seem (once again) the right time to do it. I know you'll answer directly to that with a 'so when is a right time to discuss that again ?' and i'll answer (still *my* opinion and not the project's answer) that just after the release would be a good time. This is a very particular time and i think that it's the first time in the project lifetime that there are 3 releases to cover at the same time (4.9, 5.6 and 6.0)
There's no reason that CentOS 5.6 is any more difficult than CentOS 5.0, while CentOS 5.0 (a major release !) only took 1 month to produce. Sure CentOS 6.0 is a lot bigger, but CentOS 5.6 is not, and CentOS 4.8 certainly was not.
Yeah and one thing we can all agree on is the fact that this time for 6.0 we tried to open the process and let people participate and that it was a big fail ....
My own conclusion (still *my* opinion and not the project's position on that question) is that most people just want to have a 'cut-and-paste' solution to automate their own rebuild, instead of seeing CentOS to release a distro faster. I know i've already said that in that thread (but a lot of people have 'echoed' their own answers too, right ? :-) ) but i've had personally the case where people were asking to 'help the project' and when they were pointed to either improving the website, translate the wiki, chasing after potential banding issues, etc, etc .. the only answer i've got *multiple* times was "no, i'm not interested in doing that : i just want to rebuild packages" .. so each time it proved me that such people aren't interested in helping the project as a whole, but instead just want to focus on build issues. I'm really wondering (and still *my* opinion) if those people are interested in CentOS as a project, or just want to 'suck' some build scripts (which are just wrappers around mock/plague as stated so much times in that thread) to produce their own respins. Once again, don't get me wrong : documenting that would be very fantastic (still my opinion) and that's what i would like to see from a FLOSS project (but Red Hat doesn't do it either, otherwise it would be 'too easy' to rebuild it :-) )
Fabian
On 2/20/11 12:03 PM, Fabian Arrotin wrote:
I know i've already said that in that thread (but a lot of people have 'echoed' their own answers too, right ?:-) ) but i've had personally the case where people were asking to 'help the project' and when they were pointed to either improving the website, translate the wiki, chasing after potential banding issues, etc, etc .. the only answer i've got*multiple* times was "no, i'm not interested in doing that : i just want to rebuild packages" .. so each time it proved me that such people aren't interested in helping the project as a whole, but instead just want to focus on build issues. I'm really wondering (and still*my* opinion) if those people are interested in CentOS as a project, or just want to 'suck' some build scripts (which are just wrappers around mock/plague as stated so much times in that thread) to produce their own respins.
Does rebuilding packages not count as helping the project? If the release speed is seen as the biggest problem with the project, why do you assume ulterior motives for people who want to help out with the effort?
For goodness sake, it's an open source project. Who cares if the occasional person wants to produce their own respin.
Steve Meyers
On 02/20/2011 07:21 PM, Steve Meyers wrote:
On 2/20/11 12:03 PM, Fabian Arrotin wrote:
I know i've already said that in that thread (but a lot of people have 'echoed' their own answers too, right ?:-) ) but i've had personally the case where people were asking to 'help the project' and when they were pointed to either improving the website, translate the wiki, chasing after potential banding issues, etc, etc .. the only answer i've got*multiple* times was "no, i'm not interested in doing that : i just want to rebuild packages" .. so each time it proved me that such people aren't interested in helping the project as a whole, but instead just want to focus on build issues. I'm really wondering (and still*my* opinion) if those people are interested in CentOS as a project, or just want to 'suck' some build scripts (which are just wrappers around mock/plague as stated so much times in that thread) to produce their own respins.
Does rebuilding packages not count as helping the project? If the release speed is seen as the biggest problem with the project, why do you assume ulterior motives for people who want to help out with the effort?
For goodness sake, it's an open source project. Who cares if the occasional person wants to produce their own respin.
External rebuilds of packages could never be used by this project, or any other project.
On 2/20/11 7:21 PM, Johnny Hughes wrote:
External rebuilds of packages could never be used by this project, or any other project.
Agreed, but if I successfully rebuilt it on my own, I could submit to the project the details build environment that I used (repos and such). That would (in theory) help, would it not?
Steve Meyers
On 02/20/2011 08:28 PM, Steve Meyers wrote:
On 2/20/11 7:21 PM, Johnny Hughes wrote:
External rebuilds of packages could never be used by this project, or any other project.
Agreed, but if I successfully rebuilt it on my own, I could submit to the project the details build environment that I used (repos and such). That would (in theory) help, would it not?
Yes, if that was what happened.
But instead, what happens is someone builds the RPMs ... puts it in their blog. All their buddies download it. The build requirements are broken and it causes bugs. A month later, we get them logging in to the forums or the mailing lists or IRC with the broken packages that have the same EVR numbers as ours and don't get replaced by the real packages and it is a bad experience for everyone.
Or, we have thousands of users with varying levels of capability, some of which are very knowledgeable and would produce data that helps us a lot. Pick a percentage of people where that data is good ... 1%, 10%, 20%, 30% ... the rest of the data is incorrect. How long does it take us to verify that the data is correct or incorrect and how does that compare to the time spent if we just build it and test it?
etc, etc, etc.
On 2/20/11 8:51 PM, Johnny Hughes wrote:
But instead, what happens is someone builds the RPMs ... puts it in their blog. All their buddies download it. The build requirements are broken and it causes bugs. A month later, we get them logging in to the forums or the mailing lists or IRC with the broken packages that have the same EVR numbers as ours and don't get replaced by the real packages and it is a bad experience for everyone.
That seems very, very unlikely from people who won't use the available SL betas.
Or, we have thousands of users with varying levels of capability, some of which are very knowledgeable and would produce data that helps us a lot. Pick a percentage of people where that data is good ... 1%, 10%, 20%, 30% ... the rest of the data is incorrect. How long does it take us to verify that the data is correct or incorrect and how does that compare to the time spent if we just build it and test it?
If you have a tool that can verify correctness, how can having a larger farm of brute force builds and tests, and submissions of reproducible recipes for the correct ones not speed things up?
On Sun, Feb 20, 2011 at 8:51 PM, Johnny Hughes johnny@centos.org wrote:
On 02/20/2011 08:28 PM, Steve Meyers wrote:
On 2/20/11 7:21 PM, Johnny Hughes wrote:
External rebuilds of packages could never be used by this project, or any other project.
Agreed, but if I successfully rebuilt it on my own, I could submit to the project the details build environment that I used (repos and such). That would (in theory) help, would it not?
Yes, if that was what happened.
But instead, what happens is someone builds the RPMs ... puts it in their blog. All their buddies download it. The build requirements are broken and it causes bugs. A month later, we get them logging in to the
[snip]
... and that's why this theme lives and breaths to this day. Note the word "theme", as the "subject matter" of this *thread* has been re-visited for years.
The obvious solution to the "someone builds the RPMs ..." support problem is the documentation that has been requested all along:
Q: [broken, ftbfs, whatever ....] A; Was your environment and build done *exactly* as described in http://nice-url-here-with-info-all-centos-rebuilders-need
No? then go see it. Yes? then let's have a meaningful conversation.
Anything less leaves room for the CentOS "community" to state amazingly rude things such as "Please don't let the door get scuffed on your way out." and for the CentOS core to easily play the "Go here to research How To Contribute" card.
Where there's smoke, there's fire. Threads like this re-occur for a reason.
jerry
On 2/20/11 7:51 PM, Johnny Hughes wrote:
Or, we have thousands of users with varying levels of capability, some of which are very knowledgeable and would produce data that helps us a lot. Pick a percentage of people where that data is good ... 1%, 10%, 20%, 30% ... the rest of the data is incorrect. How long does it take us to verify that the data is correct or incorrect and how does that compare to the time spent if we just build it and test it?
It sounds like our help is not wanted. We should all just shut up and wait. I apologize for wanting to contribute in a meaningful way towards the CentOS 6 release.
Steve Meyers
On Sun, Feb 20, 2011 at 08:56:28PM -0700, Steve Meyers wrote:
It sounds like our help is not wanted. We should all just shut up and wait. I apologize for wanting to contribute in a meaningful way towards the CentOS 6 release.
Where were you when the call for assistance with branding issues went out many weeks ago? Just sayin'
John
On 2/20/11 10:06 PM, John R. Dennison wrote:
Where were you when the call for assistance with branding issues went out many weeks ago? Just sayin'
At the time, I had a day job. I now have more free time, which I am currently wasting reading this list instead of doing something productive. :)
Steve Meyers
On Sun, Feb 20, 2011 at 10:24:40PM -0700, Steve Meyers wrote:
At the time, I had a day job. I now have more free time, which I am currently wasting reading this list instead of doing something productive. :)
Heh - *lot* of that going around these days :)
John
On Mon, Feb 21, 2011 at 12:06 AM, John R. Dennison jrd@gerdesas.com wrote:
On Sun, Feb 20, 2011 at 08:56:28PM -0700, Steve Meyers wrote:
It sounds like our help is not wanted. We should all just shut up and wait. I apologize for wanting to contribute in a meaningful way towards the CentOS 6 release.
Where were you when the call for assistance with branding issues went out many weeks ago? Just sayin'
I, for one, couldn't replicate your build environment to rebuild the relevant components, and didn't want to publish bits that would fail regression testing.
On 02/21/2011 01:54 PM, Nico Kadel-Garcia wrote:
On Mon, Feb 21, 2011 at 12:06 AM, John R. Dennisonjrd@gerdesas.com wrote:
On Sun, Feb 20, 2011 at 08:56:28PM -0700, Steve Meyers wrote:
It sounds like our help is not wanted. We should all just shut up and wait. I apologize for wanting to contribute in a meaningful way towards the CentOS 6 release.
Where were you when the call for assistance with branding issues went out many weeks ago? Just sayin'I, for one, couldn't replicate your build environment to rebuild the relevant components, and didn't want to publish bits that would fail regression testing.
Sorry but i don't get the point with your last comment : John asked for 'assistance with branding issues' so what's the relationship with building the 'relevant components' ? As stated in the first call for branding issues, everybody was asked to setup rhel6beta2 (free to download and still on the mirrors) to look at packages with potential trademark issues. There is no build issue involved in that process ...
Fabian
On Sun, 20 Feb 2011, John R. Dennison wrote:
On Sun, Feb 20, 2011 at 08:56:28PM -0700, Steve Meyers wrote:
It sounds like our help is not wanted. We should all just shut up and wait. I apologize for wanting to contribute in a meaningful way towards the CentOS 6 release.
Where were you when the call for assistance with branding issues went out many weeks ago? Just sayin'
So because people may not have an interest in one thing, they shouldn't be helping with anything else ? That's not how Open Source works, is it ?
People help in those parts they are interested in. Besides, I don't think people really know what they are supposed to do with the branding/trademark and I'd like to know why there aren't any tools that help with that.
I'd be more interested to help with a tool that can catch (whitelist/blacklist) certain trademark/branding stuff, rather than doing that manually.
On Sun, 20 Feb 2011, Johnny Hughes wrote:
On 02/20/2011 07:21 PM, Steve Meyers wrote:
On 2/20/11 12:03 PM, Fabian Arrotin wrote:
I know i've already said that in that thread (but a lot of people have 'echoed' their own answers too, right ?:-) ) but i've had personally the case where people were asking to 'help the project' and when they were pointed to either improving the website, translate the wiki, chasing after potential banding issues, etc, etc .. the only answer i've got*multiple* times was "no, i'm not interested in doing that : i just want to rebuild packages" .. so each time it proved me that such people aren't interested in helping the project as a whole, but instead just want to focus on build issues. I'm really wondering (and still*my* opinion) if those people are interested in CentOS as a project, or just want to 'suck' some build scripts (which are just wrappers around mock/plague as stated so much times in that thread) to produce their own respins.
Does rebuilding packages not count as helping the project? If the release speed is seen as the biggest problem with the project, why do you assume ulterior motives for people who want to help out with the effort?
For goodness sake, it's an open source project. Who cares if the occasional person wants to produce their own respin.
External rebuilds of packages could never be used by this project, or any other project.
Johnny,
For heaven's sake. The fact that users can rebuild has many applications even if the RPMs will never be part of CentOS (for obvious reasons).
* You create a community of people that can help troubleshoot problems and report problems upstream (less effort for the CentOS developers !) Farkas Levente single-handedly reported most RHEL6 rebuild problems to Red Hat.
* This community of people has a higher standard than the current community. Which has been the reason for _not accepting_ more people in various positions (they first have to prove themselves, right ? Prove themselves doing what exactly ?)
* Thanks to more people understanding what is involved, the automation part (tools, scripts, ...) can improve as well. You mention that SRPMs are not being changed, but the environment for each build may be adapted. Looks to me a good tool describing this for those packages is useful. (If only to share that information between our advanced users)
* The more people involved, the more people you can choose from once crucial members of the team get married, have children, drop dead, or anything else in life that takes away free time put into the CentOS project. It's a clear win-win for the project.
You mentioned the Fedora project as the most open project you know. Why not learn from how they work ? Obviously packages build by a single Fedora user are not going into Fedora either, but at least nothing in the process is concealed to users, so users can advance and the project improves as well.
On Mon, Feb 21, 2011 at 8:22 AM, Dag Wieers dag@wieers.com wrote:
* Thanks to more people understanding what is involved, the automation part (tools, scripts, ...) can improve as well. You mention that SRPMs are not being changed, but the environment for each build may be adapted. Looks to me a good tool describing this for those packages is useful. (If only to share that information between our advanced users)
Dag,
Jeff Johnson has been very helpful in outlining some of the issues involved with SRPMS and, since you arguably maintain more RPMs than anyone else in the world, I'd like to ask you if the changes to the build environment (e.g., fPIC) can be done:
1) in the SRPM with extant structures 2) would require a mod to the data structures 3) (suboptimally) would require a separate database of compiler parms, etc.
THANKS for your response.
kind regards/ldv/vaden@texoma.net
Le 21/02/2011 18:22, Dag Wieers a écrit :
On Sun, 20 Feb 2011, Johnny Hughes wrote:
On 02/20/2011 07:21 PM, Steve Meyers wrote:
On 2/20/11 12:03 PM, Fabian Arrotin wrote:
I know i've already said that in that thread (but a lot of people have 'echoed' their own answers too, right ?:-) ) but i've had personally the case where people were asking to 'help the project' and when they were pointed to either improving the website, translate the wiki, chasing after potential banding issues, etc, etc .. the only answer i've got*multiple* times was "no, i'm not interested in doing that : i just want to rebuild packages" .. so each time it proved me that such people aren't interested in helping the project as a whole, but instead just want to focus on build issues. I'm really wondering (and still*my* opinion) if those people are interested in CentOS as a project, or just want to 'suck' some build scripts (which are just wrappers around mock/plague as stated so much times in that thread) to produce their own respins.
Does rebuilding packages not count as helping the project? If the release speed is seen as the biggest problem with the project, why do you assume ulterior motives for people who want to help out with the effort?
For goodness sake, it's an open source project. Who cares if the occasional person wants to produce their own respin.
External rebuilds of packages could never be used by this project, or any other project.
Johnny,
For heaven's sake. The fact that users can rebuild has many applications even if the RPMs will never be part of CentOS (for obvious reasons).
You create a community of people that can help troubleshoot problems and report problems upstream (less effort for the CentOS developers !) Farkas Levente single-handedly reported most RHEL6 rebuild problems to Red Hat.
This community of people has a higher standard than the current community. Which has been the reason for _not accepting_ more people in various positions (they first have to prove themselves, right ? Prove themselves doing what exactly ?)
Thanks to more people understanding what is involved, the automation part (tools, scripts, ...) can improve as well. You mention that SRPMs are not being changed, but the environment for each build may be adapted. Looks to me a good tool describing this for those packages is useful. (If only to share that information between our advanced users)
The more people involved, the more people you can choose from once crucial members of the team get married, have children, drop dead, or anything else in life that takes away free time put into the CentOS project. It's a clear win-win for the project.
You mentioned the Fedora project as the most open project you know. Why not learn from how they work ? Obviously packages build by a single Fedora user are not going into Fedora either, but at least nothing in the process is concealed to users, so users can advance and the project improves as well.
There are none so deaf as those who will not hear ... Centos could be rename as "CloseOS". Johnny, we all want the same thing; a good RHEL alternative, with a "best effort" to have security update in a reasonable time; Well .. maybe the main problem is that Centos is a toy for 2 (or 3) people that have problems with the concept so important in free software: "share knowledge, share the work".
It's simple: For a project so popular, if leaders don't care about the community; the project will die. Don't underestimate a fork ... see Xorg, Nouveau, Icinga etc... the reason for this was always the same: a restriction (a non sense when you're working with free software).
And like I said; if everyone can rebuild the current dev tree, check, see what's wrong; where is the problem?
Regards,
js.
Steve Meyers wrote:
On 2/20/11 12:03 PM, Fabian Arrotin wrote:
I know i've already said that in that thread (but a lot of people have 'echoed' their own answers too, right ?:-) ) but i've had personally the case where people were asking to 'help the project' and when they were pointed to either improving the website, translate the wiki, chasing after potential banding issues, etc, etc .. the only answer i've got*multiple* times was "no, i'm not interested in doing that : i just want to rebuild packages" .. so each time it proved me that such people aren't interested in helping the project as a whole, but instead just want to focus on build issues. I'm really wondering (and still*my* opinion) if those people are interested in CentOS as a project, or just want to 'suck' some build scripts (which are just wrappers around mock/plague as stated so much times in that thread) to produce their own respins.
Does rebuilding packages not count as helping the project? If the release speed is seen as the biggest problem with the project, why do you assume ulterior motives for people who want to help out with the effort?
For goodness sake, it's an open source project. Who cares if the occasional person wants to produce their own respin.
RH would!! Apparently!! If that occasional person develops to a more than "occasional".
I still stand behind my evaluation of the situation done here https://www.centos.org/modules/newbb/viewtopic.php?topic_id=29676&forum=... Apparently the people behind CentOS are so intricately professionally related to RH that CentOS exists because RH wants it to exist. Working in the background RH reserves its options for the future. As a corporation it evaluates the developing business environment (ex. Oracle buying Sun, killing OpenSolaris etc etc) and and takes appropriate action. Including making life harder for other corporations to compete. All these is perfectly understandable. It may, though, mean that CentOS dies quite likely a similar death to OpenSolaris.
Andreas Kasenides
Andreas Kasenides wrote:
Does rebuilding packages not count as helping the project? If the release speed is seen as the biggest problem with the project, why do you assume ulterior motives for people who want to help out with the effort?
For goodness sake, it's an open source project. Who cares if the occasional person wants to produce their own respin.
RH would!! Apparently!! If that occasional person develops to a more than "occasional".
I still stand behind my evaluation of the situation done here https://www.centos.org/modules/newbb/viewtopic.php?topic_id=29676&forum=... Apparently the people behind CentOS are so intricately professionally related to RH that CentOS exists because RH wants it to exist. Working in the background RH reserves its options for the future. As a corporation it evaluates the developing business environment (ex. Oracle buying Sun, killing OpenSolaris etc etc) and and takes appropriate action. Including making life harder for other corporations to compete. All these is perfectly understandable. It may, though, mean that CentOS dies quite likely a similar death to OpenSolaris.
Andreas Kasenides
That must be true in part where RH supports CentOS. That makes sense if you Look at RH as Open Source supporter, as well as good OSS business decision. They are in support business, at least with OS part. Making sure that there is free version of their OS that can be easily converted to full RHEL, and that there is large user base happy with the product and learning on RHEL clone makes sure that RH will always have customers. Even Microsoft testified in favor of illegal home user vs BSA because he did not want to frighten people into stop using Windows even illegally. If someone does not use your software home/outside the business, he also will not use it inside his business environment.
Looking from that perspective, CentOS will he around for many years to come.
This of course does not mean that RH can not create time-consuming problems to make sure that competition is always lagging behind to make sure mission critical systems have their payed support.
If that is necessary in order for me to use their huge R&D and HR potential for free, then I do not mind. This will make sure they have the money to keep developing the product I will be using for free.
If someone is not willing to accept this approach, if they want it now, then I advise them to pay for real thing, fully knowing that their narrow-mindness can not accept the fact that world is *not* revolving around their wishes. You can not stay virgin and have sex at the same time. Appearing to be is another matter.
Ljubomir.
Am 20.02.2011 um 18:13 schrieb Dag Wieers:
On Sun, 20 Feb 2011, Johnny Hughes wrote:
Could I ask a simple question: When the Centos6 build (for i386 or x86_64) was release / build at 100% (or close) ?
It might be 2 weeks from now or 2 months from now. I would like to think it will be closer to 2 weeks, but it will be completed when it gets completed.
Johnny,
So it's absolutely normal a CentOS 5.6 release is 10 weeks late and there's no intent to speed up the process to lower the time to do future releases ?
Dag, with all respect - polarizing doesn't help! RHEL5u6 is released 5 weeks ago (+2).
If that is the case, we might want to make that more clear on the wiki, eg. in my CentOS introduction presentation from 2008 we still mention that releases are (up to) 4 weeks behind RHEL.
The actual process is slowing down caused by the concurrent appearance of RHEL4u9, RHEL5u6 and RHEL6. Right, one could argument that the problem lies here now.
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
Centos != RHEL and therefore this implies a time-window between update availability. Using this immanent fact against the team is counterproductive.
PM
On Sun, 20 Feb 2011, Paulo Martinez wrote:
Dag, with all respect - polarizing doesn't help! RHEL5u6 is released 5 weeks ago (+2).
You're right, I am sorry for the misinformation. I clearly mixed up Beta and GA release dates for RHEL 5.6. (In fact, I noticed I never blogged about RHEL 5.6 GA release at all)
On 02/20/2011 11:13 AM, Dag Wieers wrote:
On Sun, 20 Feb 2011, Johnny Hughes wrote:
Could I ask a simple question: When the Centos6 build (for i386 or x86_64) was release / build at 100% (or close) ?
It might be 2 weeks from now or 2 months from now. I would like to think it will be closer to 2 weeks, but it will be completed when it gets completed.
Johnny,
So it's absolutely normal a CentOS 5.6 release is 10 weeks late and there's no intent to speed up the process to lower the time to do future releases ?
This CVE update (CVE-2010-4527) took 7 weeks to get into the kernel (Reported Dec 29th, 2010 ... issued 2/16/2011):
https://bugzilla.redhat.com/show_bug.cgi?id=667615
This one (CVE-2010-4655) took 18 weeks (reported October 11 2010, fixed in a release on 2/16/2011).
I can find security updates that take more than a year for upstream to get into just the kernel. I can find bug fix updates that take well in excess of a year to make it into the release.
Why do you try to hold CentOS to a different standard?
Yes, I find it perfectly acceptable for it to take what the WIKI says (4-8 weeks) to release a major point release:
http://wiki.centos.org/FAQ/General/RebuildReleaseProcess
If one wants to get and SLA, they can most certainly obtain one.
If that is the case, we might want to make that more clear on the wiki, eg. in my CentOS introduction presentation from 2008 we still mention that releases are (up to) 4 weeks behind RHEL.
The wiki has been updated on the page for quoted for some time.
I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic.
Are they aware that it might take much longer than 10 weeks to get into RHEL in the first place ... and if so, why is my deadline really tight but the original deadline open ended?
And as someone else already pointed out, it has been 5, not 10 weeks.
On Feb 20, 2011, at 3:13 PM, Johnny Hughes wrote:
Why do you try to hold CentOS to a different standard?
The "standard" is vendor-sec, where the exploits are known long before they are publically announced, and coordinated releases, with consistent patches across all vendors, are delivered.
The "standard" is _NOT_ the time delta between upstream and CentOS releasing. And with better info sooner, I suspect that security releasing would improve. All depends on volunteer efforts, security drills ain't fun.
CentOS may have lost 1 of its vendor-sec representatioves, but its a role that can be re-filled.
73 de Jeff
On Sun, 20 Feb 2011, Jeff Johnson wrote:
CentOS may have lost 1 of its vendor-sec representatioves, but its a role that can be re-filled.
Not sure what is meant there, but the vendor-sec process has been relatively quiet of late. Some updates ... thinking here of the recent OpenJDK set ... never passed on that list as to a co-ordinated release date. The real problem in CentOS' presence there is that as the project intentionally 'chases the tail-lights' to follow the upstream, warts and all, we rarely have anything to offer in the vendor-sec list
-- Russ herrold
On Sun, Feb 20, 2011 at 04:52:47PM -0500, R P Herrold wrote:
On Sun, 20 Feb 2011, Jeff Johnson wrote:
CentOS may have lost 1 of its vendor-sec representatioves, but its a role that can be re-filled.
Not sure what is meant there, but the vendor-sec process has been relatively quiet of late. Some updates ... thinking here of the recent OpenJDK set ... never passed on that list as to a co-ordinated release date. The real problem in CentOS' presence there is that as the project intentionally 'chases the tail-lights' to follow the upstream, warts and all, we rarely have anything to offer in the vendor-sec list
The time to exchange on security issues is for sure much higher than the efford to recompile rpms again for CentOS.
I think having CentOS presence there is still the right thing as the whole point of vendor-sec is to build a small group where information is shared, knowing that most people more read from this than actually contribute.
best regards,
Florian La Roche
On 02/20/2011 12:11 PM, Dag Wieers wrote:
- CentOS is not able to release CentOS 5.6 after 2 months and nobody is
allowed to be critical about it.
(Despite the fact that the effort to rebuild CentOS 5.6 packages is a lot easier than CentOS 6.0 which is already 3 months late)
has it been 2 months since 5.6 was released ? Add another point of real interest: when was it that red hat released all sources for 5.6 ?
- The same 3 people are responsible for CentOS 4, CentOS 5 and CentOS 6.
What's more, the fact that there would be three update releases in 3 months was predictable.
thats true. although upto 7 people can be involved at any given stage, not 3.
So despite all the automation, QA team, past promises and whatnot, we are not doing a better job today and I had hoped at least some people would agree instead of denying there's something wrong with the process and blaming the non-volunteers/community for even bringing it up.
The fact that there are disfunctional setups in place is not something that anyone ( I for one ) are deny'ing. But the fact that a call for help got zero traction for weeks is also worth considering. We could go back, stop everything that is going on at the moment and try to process engineer a better setup before we again start working on CentOS-6, I'd say a target of 2 to 3 months would be reasonable if we did that.
On the other hand, we can just get this done out of the door and then look at process engineering for the future. We are better, stronger as a group with a much larger contributor base than ever before - I see no reason why we could not strengthen that even further and split the roles out.
Besides, I've always argued that the idea of a QA team was wrong, the way it was setup was wrong and there is plenty of scope for us to change that. As a striking example: 70% of the QA team people never actually did any QA work at all. Losing them was step-1, moving as much as we can into an automated public stack is step-2, some work has happened on that already, but I doubt we can move to it completely in time for 6.
There are a *lot* of things like that going on around the edges, and are not visible or much touted at the moment. Because (a) we need to retain core focus and (b) the changes need to work through a process that has near zero user side impact. Whatever process we have now and have had in the past, clearly worked for a large number of people - and the fact that they trust the process. I guess another issue is that a vast majority of the centos userbase isn't represented here in the lists, the forums or irc. Which makes it harder for people who watch these media to sometimes comprehend the meandering.
And despite what some people may think, I am not _against_ CentOS, in fact the only reason why I am bringing it up is because * I * still * care !
I can believe that :) I just dont believe you understand the entire centos ecosystem. Maybe we need another beer session sometime soon. Shame that you were unable to make Fosdem.
- KB
On 2/21/11 8:19 AM, Karanbir Singh wrote:
The fact that there are disfunctional setups in place is not something that anyone ( I for one ) are deny'ing. But the fact that a call for help got zero traction for weeks is also worth considering. We could go back, stop everything that is going on at the moment and try to process engineer a better setup before we again start working on CentOS-6, I'd say a target of 2 to 3 months would be reasonable if we did that.
If you're referring to the branding issues call for help, I was unable to help at that time, but I also had trouble understanding exactly what was needed. There was a link to an Audit Status page on the wiki, without much explanation of what should be done with it.
Would it help to have someone in charge of organizing community involvement? Someone who would take the time to ensure that there is enough documentation of how people can help?
Steve Meyers
On 02/21/2011 05:39 PM, Steve Meyers wrote:
If you're referring to the branding issues call for help, I was unable to help at that time, but I also had trouble understanding exactly what was needed. There was a link to an Audit Status page on the wiki, without much explanation of what should be done with it.
When there is a bit of time, it would be interesting to see why it wasent clear - the questions were asked a few times, and we all went through a few iterations to workout how things could clear up. Quite a few people did get involved though. I am sure there will be plenty of opportunity for you to help as well :)
Would it help to have someone in charge of organizing community involvement? Someone who would take the time to ensure that there is enough documentation of how people can help?
that has been brought up a few times in the past as well, it might be something worth trying. Although that then creates another layer of abstraction between the people trying to get things done and the ones trying to help.
Having said that, over the next few months we are going to try and create more specific tasks, with tangible end points and try and see if that sort of a tasklist makes things easier for people to get involved with. The best thing is that the distro build isnt the only place people can help with.
- KB
On 2/21/11 10:43 AM, Karanbir Singh wrote:
When there is a bit of time, it would be interesting to see why it wasent clear - the questions were asked a few times, and we all went through a few iterations to workout how things could clear up. Quite a few people did get involved though. I am sure there will be plenty of opportunity for you to help as well:)
As I mentioned, I didn't have time then, so I probably didn't pay attention as much. I don't think having instructions on the mailing list is sufficient, though. While it is technically all "out there", it is difficult to wade through the rest of the list just to find the 2-3 messages that have the information you need. To me, that seems to be a perfect case for using the wiki.
Steve Meyers
On 02/21/2011 05:58 PM, Steve Meyers wrote:
As I mentioned, I didn't have time then, so I probably didn't pay attention as much. I don't think having instructions on the mailing list is sufficient, though. While it is technically all "out there", it is difficult to wade through the rest of the list just to find the 2-3 messages that have the information you need. To me, that seems to be a perfect case for using the wiki.
by design, we were not looking for people new to the process and to CentOS. We were focusing on people who have been on this list for a significant portion of time, people who understand the wider goals. And there are hundreds of them.
Within CentOS - there are always going to be areas for people to get involved in, one of which is the distro. And for the distro, there would almost always need to be some level of publicly acknowledged visibility in the communities; thats how things stand at the moment, and I dont see any reason why that needs to or should change in the short term. For specific tasks that can be fan'd out I am sure that we will make every effort to do that. And that should be totally optimized towards anyone / everyone - with zero conditions attached.
- KB
On Mon, Feb 21, 2011 at 05:43:01PM +0000, Karanbir Singh wrote:
that has been brought up a few times in the past as well, it might be something worth trying. Although that then creates another layer of abstraction between the people trying to get things done and the ones trying to help.
I think having someone work as a community information conduit would be a huge benefit to the project. You often serve in this role, but then when the twitter feed has no updates for weeks, the casual follower gets anxious. It'd be nice to have someone whose job it is to follow the internal communications and progress and produce regular updates.
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
Regards
js.
On 02/20/2011 06:16 AM, js wrote:
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
no, it will work once the person who wants to do the rebuild follows the instructions already published and uses the device named "brain".
On Sat, Feb 19, 2011 at 11:22 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 02/20/2011 06:16 AM, js wrote:
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
no, it will work once the person who wants to do the rebuild follows the instructions already published and uses the device named "brain".
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
On 02/19/2011 10:27 PM, Nico Kadel-Garcia wrote:
On Sat, Feb 19, 2011 at 11:22 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 02/20/2011 06:16 AM, js wrote:
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
no, it will work once the person who wants to do the rebuild follows the instructions already published and uses the device named "brain".
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
Ummm ... we haven't even got CentOS 6 to build on CentOS 5 yet.
On 02/19/2011 10:27 PM, Nico Kadel-Garcia wrote:
On Sat, Feb 19, 2011 at 11:22 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 02/20/2011 06:16 AM, js wrote:
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
no, it will work once the person who wants to do the rebuild follows the instructions already published and uses the device named "brain".
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
http://lists.centos.org/pipermail/centos-devel/2011-February/006775.html
http://wiki.centos.org/FAQ/General/RebuildReleaseProcess
http://www.karan.org/blog/index.php/2010/07/16/rpms-built-on-el6beta2-might-...
On Sat, Feb 19, 2011 at 11:58 PM, Johnny Hughes johnny@centos.org wrote:
On 02/19/2011 10:27 PM, Nico Kadel-Garcia wrote:
Or do you see something I don't?
http://lists.centos.org/pipermail/centos-devel/2011-February/006775.html
CentOS 5, not the existing CentOS 6 infrastructure.
Handwaving with mock. Got it.
http://www.karan.org/blog/index.php/2010/07/16/rpms-built-on-el6beta2-might-...
More informative, but also entirely CentOS 5. There are some subtle distinctions for CentOS 6, especially for a bootstrapping process.
I'd appreciate, as a programmer, some access to the already patched .spec files and replaced component tree. In particular, the new .spec policies of building documentation packages as "noarch" cause serious awkwardness with the RHEL 5 RPM packages. Recreating or personally reconstructing the bootstrap is as awkward now as it was for gcc, 20 years ago. I'd prefer not to burn my engineering time re-inventing that particular wheel.
As it is, we're in the position of asking where the matches are kept so we can help with the wienie roast, and those notes tell us where to dig for sulfur to put on the matchheads. Not helpful, really, even though I've actually done that myself in the past.
On 02/19/2011 10:27 PM, Nico Kadel-Garcia wrote:
On Sat, Feb 19, 2011 at 11:22 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 02/20/2011 06:16 AM, js wrote:
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
no, it will work once the person who wants to do the rebuild follows the instructions already published and uses the device named "brain".
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
There are MANY ways to invoke mock to build packages ...
1. Via the command line or via a script:
http://lists.centos.org/pipermail/centos-devel/2011-February/006775.html
2. Via a outdated build system called plague:
http://fedoraproject.org/wiki/Projects/Plague
3. Via the current fedora build system called koji:
http://fedoraproject.org/wiki/Koji
As far as CentOS 6 goes, we have not yet gotten it to build correctly, so we have no guidance to get it to build correctly.
On 02/20/2011 06:27 AM, Nico Kadel-Garcia wrote:
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
I do. :) Use for the build root the rhel6b2 binaries available on ftp.redhat.com and the configs from the mock package available in EPEL-6. There is no magic. Really ( At least for 98% of the work.)
On 02/20/2011 07:17 AM, Manuel Wolfshant wrote:
On 02/20/2011 06:27 AM, Nico Kadel-Garcia wrote:
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
I do. :) Use for the build root the rhel6b2 binaries available on ftp.redhat.com and the configs from the mock package available in EPEL-6. There is no magic. Really ( At least for 98% of the work.)
The beta tree is here (binary and source files):
ftp://ftp.redhat.com/redhat/linux/beta/
You will also find the fedora 12 binary and source files necessary:
http://download.fedora.redhat.com/pub/fedora/linux/releases/12/Fedora/
http://download.fedora.redhat.com/pub/fedora/linux/updates/12/
We (CentOS Project) need to perform lots of things on files that we would "Distribute". (Trademark stripping, etc.). We will not distribute our working files to try can get CentOS 6 built, as we have not and do not intend to perform the actions on them which would allow us to release them. That would mean rebuilding and vetting not only CentOS-6 but all those other trees too.
On Sun, Feb 20, 2011 at 8:49 AM, Johnny Hughes johnny@centos.org wrote:
On 02/20/2011 07:17 AM, Manuel Wolfshant wrote:
On 02/20/2011 06:27 AM, Nico Kadel-Garcia wrote:
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
I do. :) Use for the build root the rhel6b2 binaries available on ftp.redhat.com and the configs from the mock package available in EPEL-6. There is no magic. Really ( At least for 98% of the work.)
The beta tree is here (binary and source files):
ftp://ftp.redhat.com/redhat/linux/beta/
You will also find the fedora 12 binary and source files necessary:
http://download.fedora.redhat.com/pub/fedora/linux/releases/12/Fedora/
http://download.fedora.redhat.com/pub/fedora/linux/updates/12/
Cool. Which are you using, by preference? That information is unpublished, near as I can tell, and would help my efforts.
We (CentOS Project) need to perform lots of things on files that we would "Distribute". (Trademark stripping, etc.). We will not distribute our working files to try can get CentOS 6 built, as we have not and do not intend to perform the actions on them which would allow us to release them. That would mean rebuilding and vetting not only CentOS-6 but all those other trees too.
Does it? Are you concerned about trademark issues, or just lack the time to slip them into something like a "git" repository which would be clonable and thus accessible? Do you want help getting those into a decent git accessible structure so this can be shared, maybe in a future release?
On 02/20/2011 09:09 AM, Nico Kadel-Garcia wrote:
On Sun, Feb 20, 2011 at 8:49 AM, Johnny Hughes johnny@centos.org wrote:
On 02/20/2011 07:17 AM, Manuel Wolfshant wrote:
On 02/20/2011 06:27 AM, Nico Kadel-Garcia wrote:
And casts a magic spell to find those instructions. I'm looking through logs and wiki.centos.org, and having *real* difficulty finding them. In particular, the bootstrapping configurations necessary to build CentOS 6 from scratch on a CentOS 5.x machine seem missing, especially access to the testing SRPM's that have already been patched to work in a non-RHEL environment.
Or do you see something I don't?
I do. :) Use for the build root the rhel6b2 binaries available on ftp.redhat.com and the configs from the mock package available in EPEL-6. There is no magic. Really ( At least for 98% of the work.)
The beta tree is here (binary and source files):
ftp://ftp.redhat.com/redhat/linux/beta/
You will also find the fedora 12 binary and source files necessary:
http://download.fedora.redhat.com/pub/fedora/linux/releases/12/Fedora/
http://download.fedora.redhat.com/pub/fedora/linux/updates/12/
Cool. Which are you using, by preference? That information is unpublished, near as I can tell, and would help my efforts.
That is the thing we have to determine. There is absolutely no way to know what a specific binary is built against except to build it from the SRPM and look at out linking compared to their linking. If it matches up, we picked the right repo ... if it does not match up, we need to try building against a different one. If we exhaust all 3 places, then we have to look at the possibility that maybe something between the specific binaries OR AFTER the beta 2 and BEFORE the release was added to the upstream build root.
That is what I have been trying to explain ... this is not just dump some RPMs and kick off a build and everything comes out the other end built ... and if I would just tell you guys the one magic then, you could spin this in a couple hours.
Each package needs top be built and tested ... there are 4 possible repos where the requires might need to come from (the staged build as we build up the packages and the 3 listed above), and the possibility even exists that some of the build requires exist only in the RH build system and have never been released at all.
We (CentOS Project) need to perform lots of things on files that we would "Distribute". (Trademark stripping, etc.). We will not distribute our working files to try can get CentOS 6 built, as we have not and do not intend to perform the actions on them which would allow us to release them. That would mean rebuilding and vetting not only CentOS-6 but all those other trees too.
Does it? Are you concerned about trademark issues, or just lack the time to slip them into something like a "git" repository which would be clonable and thus accessible? Do you want help getting those into a decent git accessible structure so this can be shared, maybe in a future release?
We can not distribute certain things without the vetting since we are centos. A mirror site could distribute them as is, but since we distribute a "rebuilt software" of their sources, anything we distribute needs to be properly vetted to remove trademarks, etc.
Le 20/02/11 08:22, Manuel Wolfshant a écrit :
On 02/20/2011 06:16 AM, js wrote:
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
no, it will work once the person who wants to do the rebuild follows the instructions already published and uses the device named "brain".
I apply more credits to Dag so we can have more details. note: people equipped with brains are polite, think about it.
Regards
js.
js wrote:
I apply more credits to Dag so we can have more details. note: people equipped with brains are polite, think about it.
I do not see how you could ever reach this conclusion. Politeness has nothing to do with intelligence (If we overlook the fact that ALL people/homo sapiens HAVE the brain :-D ).
It's more of the emotional response to irritating environment. I for one become more aggressive when extreme heat is applied to my body making me aggressive driver when I have no way of cooling myself.
I also get highly irritated when those less intelligent then my self (99%) start *insisting* (repeating it over and over) that I explain to them some things they are not capable of grasping. I have reasonable tolerance built-in in my brain/personality. I do freelance IT maintenance and I am also a local WISP so I am used to explain absolute basics OVER AND OVER AND OVER... without snapping at them, but my tolerance caves under extended time of applied pressure. I then snap on them, or someone else around in order to vent-out.
Also, there must be a lot of people, that talked with me over the phone, believing that I was rude just because I would end the conversation right after we finished conversing the stuff call was all about. I just can not process the need mediocre/most of people have to prolong the conversation after the reason for calling is fulfilled, just because the conversation was very short (for example, they ask me when I can come to check something, I answer them and then try to finish the conversation so I can continue what I was doing). This excludes if I consider them friends or the caller starts the conversation with "I wanted to hear/talk to you" or similar.
Politeness is mostly used to mask someones true intent in order to have you like them, thus improving their influence over you. Take a look at the worst scum on this planet, politicians, lawyers and hustlers and there is not need for further explanation. It's JUST a mask, you will never be as polite to esthetically ugly person as you are to gorgeous female or VIP unless you realize this and forceably correct you behavior.
I prefer that people are open and honest to me, and to tell me to stop irritate them, then for them to pretend.
And when I work I *HATE* to waist my time trying to explain what exactly I am doing, especially if I am helping someone without compensation. "How much longer Papa Smurf?" makes me want to just give up and do something more gratifying.
P.S. Sorry for the great off-topic
Ljubomir
On 02/19/2011 10:16 PM, js wrote:
Le 20/02/11 04:32, Dag Wieers a écrit :
On Sat, 19 Feb 2011, Johnny Hughes wrote:
For the vast majority of packages, we make no changes. We rebuild it and test it. If the binary passes the test, we use it. If the binary does not pass the test we troubleshoot and figure out why it does not pass the test ... and we change things OUTSIDE the SRPM to fix the problem.
Yes, and those changes are closed.
But then again we first have to establish the notion that a CentOS release that is 2 or 3 months behind RHEL is a huge security problem to CentOS users (and probably to the CentOS infrastructure as well).
I don't think it makes any sense to discuss the CentOS project's transparency if we cannot admit that we are doing a lousy job regarding our core business. The lack of competition in this space surely didn't help keeping us on our toes.
Hello,
So, if for some reasons I want to rebuild a centos (for educational); It will not work because of missing "hack" never published?
There are no HACKS, no.
Red Hat has undocumented build requirements.
It is not a HACK to run the command yum install yum-metadata-parser and then rebuild the rpm again after you run the tmverifyrpms script and find that it needs to be added because of a bad link.
When did it become the CentOS Project's responsibility to publicly publish the upstream provider's missing build requirements?
On 2/19/11 10:44 PM, Johnny Hughes wrote:
Red Hat has undocumented build requirements.
It is not a HACK to run the command yum install yum-metadata-parser and then rebuild the rpm again after you run the tmverifyrpms script and find that it needs to be added because of a bad link.
When did it become the CentOS Project's responsibility to publicly publish the upstream provider's missing build requirements?
It's not a matter of responsibility, it's just the way things are improved. Would we even know something called Linux today if Linus hadn't published his work publicly instead of making people prove they were worthy to see it first?
On Feb 20, 2011, at 11:40 AM, Les Mikesell wrote:
On 2/19/11 10:44 PM, Johnny Hughes wrote:
Red Hat has undocumented build requirements.
It is not a HACK to run the command yum install yum-metadata-parser and then rebuild the rpm again after you run the tmverifyrpms script and find that it needs to be added because of a bad link.
When did it become the CentOS Project's responsibility to publicly publish the upstream provider's missing build requirements?
It's not a matter of responsibility, it's just the way things are improved. Would we even know something called Linux today if Linus hadn't published his work publicly instead of making people prove they were worthy to see it first?
Yes but ... Who wrote the bible?
And why are we devout atheists doomed to the hell of this thread?
73 de jeff
On 02/20/2011 10:40 AM, Les Mikesell wrote:
On 2/19/11 10:44 PM, Johnny Hughes wrote:
Red Hat has undocumented build requirements.
It is not a HACK to run the command yum install yum-metadata-parser and then rebuild the rpm again after you run the tmverifyrpms script and find that it needs to be added because of a bad link.
When did it become the CentOS Project's responsibility to publicly publish the upstream provider's missing build requirements?
It's not a matter of responsibility, it's just the way things are improved. Would we even know something called Linux today if Linus hadn't published his work publicly instead of making people prove they were worthy to see it first?
If it was MY code that had the missing build requirements, I would publish that no problem.
If it was CentOS' code that had the missing requirements, I would also publish that, no problem.
It is neither. It is the upstream code that has the issues. I am not sure they want us to publish this. I see no need to potentially irritate them to provide this information. If they wanted it published, they would publish it. If I publish it, then that helps other people like Oracle or whomever, build the upstream product. Have any of you considered what potential impact the CentOS relationship with the upstream provider might suffer if we started publishing things that are negative?
On Feb 20, 2011, at 2:16 PM, Johnny Hughes wrote:
It is neither. It is the upstream code that has the issues. I am not
All depends on where you choose to publish.
Try publishing at bugzilla.redhat.com ... which you may likely already have done.
And its not the publishing, but rather fixing, that is critical path. I'm sure I'm preaching to the choir ... glad to see you active again.
73 de Jeff
On 02/20/2011 01:29 PM, Jeff Johnson wrote:
On Feb 20, 2011, at 2:16 PM, Johnny Hughes wrote:
It is neither. It is the upstream code that has the issues. I am not
All depends on where you choose to publish.
Try publishing at bugzilla.redhat.com ... which you may likely already have done.
And its not the publishing, but rather fixing, that is critical path. I'm sure I'm preaching to the choir ... glad to see you active again.
And we do this ... submit missing build requirements as bugs.
On Feb 20, 2011, at 2:42 PM, Johnny Hughes wrote:
And we do this ... submit missing build requirements as bugs.
Knew you were active ...
BTW, I've always admired the tools used in CentOS to detect binary packaging differences.
I'll swipe those tools and distribute anytime you (meaning CentOS) choose to release them. Note that isn't a request for Yet More Effort, just a pending event in my todo++ queue.
Been there for years.
You might also ask for buildid to be added to ELF notes to track _EXACTLY_ what library was linked. That's likely not too hard to arrange. Rolling the die across 4 possible repositories can't be fun ...
73 de Jeff
On Sun, Feb 20, 2011 at 1:42 PM, Johnny Hughes johnny@centos.org wrote:
And we do this ... submit missing build requirements as bugs.
Hypothetical:
1) mission critical use of RHEL in a "life or death" environment, let's say it is an ICU application in a hospital 2) miscreant exploits vulnerability in RHEL, rendering it useless, as well as the 3 other machines performing the same function 3) experienced sysadmin diagnoses issue to the rpm level 4) e.s. loads build environment and the vulnerable SRPM and build environment fails to produce good RPM 5) e.s., being a RH rate-payer, is unaware that CentOS Team and Community has solved the issue with a kludge to the build environment
On Feb 20, 2011, at 3:02 PM, Larry Vaden wrote:
On Sun, Feb 20, 2011 at 1:42 PM, Johnny Hughes johnny@centos.org wrote:
And we do this ... submit missing build requirements as bugs.
Hypothetical:
- mission critical use of RHEL in a "life or death" environment,
let's say it is an ICU application in a hospital
hospitals pay huge premiums to avoid risk. And RHEL (like all software) carries all sorts of disclaimers in the fine print.
- miscreant exploits vulnerability in RHEL, rendering it useless, as
well as the 3 other machines performing the same function
miscreants aren't usually seeking, say, virtual kidneys when its so much easier to steal credit car numbers.
- experienced sysadmin diagnoses issue to the rpm level
Whoa: leave rpm out of this risk analysis please. Its not rpm, but rather yum, that routinely disables signature checking.
- e.s. loads build environment and the vulnerable SRPM and build
environment fails to produce good RPM
You're building SRPM's in an ICU now? Try AWS EC2 instead, far cheaper, and scales better.
- e.s., being a RH rate-payer, is unaware that CentOS Team and
Community has solved the issue with a kludge to the build environment
People die daily, hospitals can't save everyone, and there's always CentOS42 where this tedious thread will surely still be going on.
73 de jeff
On Sun, Feb 20, 2011 at 2:11 PM, Jeff Johnson n3npq@mac.com wrote:
- experienced sysadmin diagnoses issue to the rpm level
Whoa: leave rpm out of this risk analysis please. Its not rpm, but rather yum, that routinely disables signature checking.
Sorry, s/rpm/package/g
On Sun, Feb 20, 2011 at 13:11, Jeff Johnson n3npq@mac.com wrote:
- experienced sysadmin diagnoses issue to the rpm level
Whoa: leave rpm out of this risk analysis please. Its not rpm, but rather yum, that routinely disables signature checking.
s/yum/people using yum/
if you don't mind :).
On Feb 20, 2011, at 4:12 PM, Stephen John Smoogen wrote:
On Sun, Feb 20, 2011 at 13:11, Jeff Johnson n3npq@mac.com wrote:
- experienced sysadmin diagnoses issue to the rpm level
Whoa: leave rpm out of this risk analysis please. Its not rpm, but rather yum, that routinely disables signature checking.
s/yum/people using yum/
if you don't mind :).
I don't mind at all because I'm not tied to an EKG in an ICU using RHEL with yum.
But I can show you the line of code -- that can only be changed by developers, not "people" in the usual sense of the word -- hardwired in yum code.
OTOH, there's many threat/security models, and noone really knows which model SHOULD apply to *.rpm. Lord knows that RPM is the only major software installer in the world where applications like yum routinely choose to disable signature/digest checking for performance and the rather useless Do you "trust" this pubkey(yN)? EULA-like dialog that reassures users but is only as secure as well as "trust" is defined. Smells like a BackOrifice to me and heck its spelled P-U-B-L-I-C K-E-Y
(We now return you to the previous thread of CentOS bashing, sorry for the interruption).
73 de jeff
On Sun, Feb 20, 2011 at 3:21 PM, Jeff Johnson n3npq@mac.com wrote:
On Feb 20, 2011, at 4:12 PM, Stephen John Smoogen wrote:
On Sun, Feb 20, 2011 at 13:11, Jeff Johnson n3npq@mac.com wrote:
- experienced sysadmin diagnoses issue to the rpm level
Whoa: leave rpm out of this risk analysis please. Its not rpm, but rather yum, that routinely disables signature checking.
s/yum/people using yum/
if you don't mind :).
I don't mind at all because I'm not tied to an EKG in an ICU using RHEL with yum.
But I can show you the line of code -- that can only be changed by developers, not "people" in the usual sense of the word -- hardwired in yum code.
This could well be one of the 10 most interesting things I'll read in 2011.
Please shed a little more light on (or, elucidate wrt if you prefer :), this issue.
On 02/20/2011 02:16 PM, Johnny Hughes wrote:
If I publish it, then that helps other people like Oracle or whomever, build the upstream product. Have any of you considered what potential impact the CentOS relationship with the upstream provider might suffer if we started publishing things that are negative?
Oh. My previous comment was sent before I noticed this other branch of this thread on the archives. Having read this now, my suggestion of publishing 'BRPM' type files would not make sense, if a goal of the CentOS project is to prevent potential downstreams (i.e. spins).
That's not open-source-cool in my book, but I didn't mean to be tilting at windmills on this list.
-Bill
On 02/22/2011 12:16 PM, Bill McGonigle wrote:
On 02/20/2011 02:16 PM, Johnny Hughes wrote:
If I publish it, then that helps other people like Oracle or whomever, build the upstream product. Have any of you considered what potential impact the CentOS relationship with the upstream provider might suffer if we started publishing things that are negative?
Oh. My previous comment was sent before I noticed this other branch of this thread on the archives. Having read this now, my suggestion of publishing 'BRPM' type files would not make sense, if a goal of the CentOS project is to prevent potential downstreams (i.e. spins).
That's not open-source-cool in my book, but I didn't mean to be tilting at windmills on this list.
-Bill
We have no issue with people rebuilding things ... we just do not think it is our responsibility to hold their hand. We provide more information than any other project out there.
We have provided scripts that use mock, we have provided rpmmacros, we have provided buildsys-build files, we published an ISO build script and a distro build script, we publish every SRPM (including all our changes), we published a list of all the hidden build requirements on the mailing list.
I am available for consulting if you would like for me to install things or build things for you (you being anyone on the list who wants to pay for my services).
On 02/19/2011 05:17 AM, Johnny Hughes wrote:
... and we change things OUTSIDE the SRPM to fix the problem.
For example, here is a problem that I had to solve for 4.9 yesterday. There is a hidden build requirement that the package gnome-volume-manager requires perl-XML-Parser to be in the mock build root for the package to build properly. This is NOT called out in the SRPM. We need to add it to the tree to build this package ... BUT, we do not modify the SRPM to make this happen, we instead modify the build root, and submit a BUG upstream for them to potentially fix this package.
Since our goal is NOT to change upstream packages at all, this would not show up in this "SVN" or "GIT" tree of all the packages ... since we do not change (or want to change) the package that upstream has produced. In any other project besides CentOS, the fix would take 1 minute, it would be to add a "Build Requires: perl-XML-Parser" to the spec file in the SVN repo and regenerate the SRPM package.
So, this time consuming tree that you want guys want us to create is not worth a hill of beans and adds nothing for the vast majority of packages, since the SRPM is unmodified from upstream.
<delurk/>
This is a very helpful explanation; thanks Johnny.
How are these changes codified? Is there, say, a 'BRPM' file, with a:
BuildRootRequires: perl-XML-Parser
line in it? If these files do exist, they could possibly be useful in a git tree for some. Some may call those files the CentOS Special Sauce.
A script to automatically file upstream bugs based on those files' check-ins would seem like a potential timesaver.
Upstream SRPMS + CentOS Special Sauce + mock = buildable distro? That would be an awesome start for a CentOS Spins project. A scientific spin, for instance.
Just thinking out loud. No doubt others have already gone further.
-Bill
On 02/22/2011 11:39 AM, Bill McGonigle wrote:
On 02/19/2011 05:17 AM, Johnny Hughes wrote:
... and we change things OUTSIDE the SRPM to fix the problem.
For example, here is a problem that I had to solve for 4.9 yesterday. There is a hidden build requirement that the package gnome-volume-manager requires perl-XML-Parser to be in the mock build root for the package to build properly. This is NOT called out in the SRPM. We need to add it to the tree to build this package ... BUT, we do not modify the SRPM to make this happen, we instead modify the build root, and submit a BUG upstream for them to potentially fix this package.
Since our goal is NOT to change upstream packages at all, this would not show up in this "SVN" or "GIT" tree of all the packages ... since we do not change (or want to change) the package that upstream has produced. In any other project besides CentOS, the fix would take 1 minute, it would be to add a "Build Requires: perl-XML-Parser" to the spec file in the SVN repo and regenerate the SRPM package.
So, this time consuming tree that you want guys want us to create is not worth a hill of beans and adds nothing for the vast majority of packages, since the SRPM is unmodified from upstream.
<delurk/>
This is a very helpful explanation; thanks Johnny.
How are these changes codified? Is there, say, a 'BRPM' file, with a:
BuildRootRequires: perl-XML-Parser
line in it? If these files do exist, they could possibly be useful in a git tree for some. Some may call those files the CentOS Special Sauce.
A script to automatically file upstream bugs based on those files' check-ins would seem like a potential timesaver.
Upstream SRPMS + CentOS Special Sauce + mock = buildable distro? That would be an awesome start for a CentOS Spins project. A scientific spin, for instance.
Just thinking out loud. No doubt others have already gone further.
I did post this list of files yesterday ... but we do not build directly from the list because the SRPMS are generated as part of the build and they must match upstream. Here is the list:
http://lists.centos.org/pipermail/centos/2011-February/106570.html
You can add them to your build root manually, see the "mock sandbox" info at the bottom of the page here:
On 02/22/2011 01:22 PM, Johnny Hughes wrote:
I did post this list of files yesterday ... but we do not build directly from the list because the SRPMS are generated as part of the build and they must match upstream. Here is the list:
http://lists.centos.org/pipermail/centos/2011-February/106570.html
Oh, great, thanks for posting the list, Johnny. I didn't think to check on the centos@ list.
I was thinking more along the lines of codifying/automating adding the packages to the build-root and upstream bug reporting, not changing the SRPM's, but I'll wait until the three in-progress builds are out to bug you guys about that again. Thanks for all the work you do for the project.
-Bill
On Tue, Feb 22, 2011 at 11:39 AM, Bill McGonigle bill@bfccomputing.com wrote:
Upstream SRPMS + CentOS Special Sauce + mock = buildable distro? That would be an awesome start for a CentOS Spins project. A scientific spin, for instance.
Or a Server Only spin that is secure out of the box, minimal services, and doesn't enable ISDN services, e.g.
On 02/22/2011 12:22 PM, Larry Vaden wrote:
On Tue, Feb 22, 2011 at 11:39 AM, Bill McGonigle bill@bfccomputing.com wrote:
Upstream SRPMS + CentOS Special Sauce + mock = buildable distro? That would be an awesome start for a CentOS Spins project. A scientific spin, for instance.
Or a Server Only spin that is secure out of the box, minimal services, and doesn't enable ISDN services, e.g.
You can do any of these things with a kickstart file ...
On Tue, Feb 22, 2011 at 12:32 PM, Johnny Hughes johnny@centos.org wrote:
You can do any of these things with a kickstart file ...
Thank you; I missed that one at Owl River.
On Feb 22, 2011, at 1:22 PM, Larry Vaden wrote:
On Tue, Feb 22, 2011 at 11:39 AM, Bill McGonigle <bill@bfccomputing.com
wrote:
would be an awesome start for a CentOS Spins project. A scientific spin, for instance.
Or a Server Only spin that is secure out of the box, minimal services, and doesn't enable ISDN services, e.g.
Spins can be done from the binary trees with revisor and other tools; no need to recompile from source RPMs unless you just want the education in how to do that (nothing wrong with wanting to do it the hard way, as long as you're wanting yourself and not someone else to do it, that is!).
See the Fedora Spins information; the revisor tool is in EPEL for C5; it's not yet in EPEL6, but it is in Fedora and shouldn't be too hard to rebuild from SRPM. I'm sure if you dug around in the EPEL pages you might find out why it's not yet in EPEL6, but that doesn't keep you from rebuilding the F12 or even F13 SRPM on EL6 yourself (don't know if the version in rawhide will build/work on EL6 or not; why not try it out and let us know?).
See: https://fedorahosted.org/revisor/ and http://spins.fedoraproject.org/about and https://fedoraproject.org/wiki/Spins_Process#Creating_a_Spin to see how it's done on Fedora.
While I've not personally tried it with CentOS, it should be possible, and even more so with C6 once it is out.
On 2/22/2011 12:41 PM, Lamar Owen wrote:
Spins can be done from the binary trees with revisor and other tools; no need to recompile from source RPMs unless you just want the education in how to do that (nothing wrong with wanting to do it the hard way, as long as you're wanting yourself and not someone else to do it, that is!).
I thought that the CentOS project had stated that their branding had to be removed if anything is changed in the distribution. Not sure how that plays out for things like SMEserver and ClearOS. K12ltsp-EL seems to have faded away although there is still a working 5.x install and you can probably work around the conflicts in the update.
See the Fedora Spins information; the revisor tool is in EPEL for C5; it's not yet in EPEL6, but it is in Fedora and shouldn't be too hard to rebuild from SRPM. I'm sure if you dug around in the EPEL pages you might find out why it's not yet in EPEL6, but that doesn't keep you from rebuilding the F12 or even F13 SRPM on EL6 yourself (don't know if the version in rawhide will build/work on EL6 or not; why not try it out and let us know?).
See: https://fedorahosted.org/revisor/ and http://spins.fedoraproject.org/about and https://fedoraproject.org/wiki/Spins_Process#Creating_a_Spin to see how it's done on Fedora.
While I've not personally tried it with CentOS, it should be possible, and even more so with C6 once it is out.
It is included in SL: http://www.scientificlinux.org/distributions/6x/build/sites
On Tue, Feb 22, 2011 at 1:08 PM, Les Mikesell lesmikesell@gmail.com wrote:
It is included in SL: http://www.scientificlinux.org/distributions/6x/build/sites
THANK YOU, Les and Lamar.
This will get us the minimal CD/DVD (without ISDN et al :) as a base install for our single-purpose-built-boxen; then, each machine can yum the current edition of its sole reason for being from a local repo.
Again, THANKS.
On Tue, Feb 22, 2011 at 12:39 PM, Bill McGonigle bill@bfccomputing.com wrote:
This is a very helpful explanation; thanks Johnny.
How are these changes codified? Is there, say, a 'BRPM' file, with a:
BuildRootRequires: perl-XML-Parser
From really harsh experience: such lines should, ideally say:
BuildRequires: perl(XML::Parser) # in the .spec file
The Debian model of "apply these packages to the base tarball or someone else's package" works pretty well, and the model might be fasible for SRPM building. (I actually assume a structure like that is already in place: it's the sort of thing I'd like access to, rather than rewriting from scratch.)
It's really important that published SRPM's be complete for mock compilation.
On 02/22/2011 06:44 PM, Nico Kadel-Garcia wrote:
On Tue, Feb 22, 2011 at 12:39 PM, Bill McGonigle bill@bfccomputing.com wrote:
This is a very helpful explanation; thanks Johnny.
How are these changes codified? Is there, say, a 'BRPM' file, with a:
BuildRootRequires: perl-XML-Parser
From really harsh experience: such lines should, ideally say:
BuildRequires: perl(XML::Parser) # in the .spec fileThe Debian model of "apply these packages to the base tarball or someone else's package" works pretty well, and the model might be fasible for SRPM building. (I actually assume a structure like that is already in place: it's the sort of thing I'd like access to, rather than rewriting from scratch.)
It's really important that published SRPM's be complete for mock compilation.
I am aware, but it also is very important that we (the CentOS Project) do not change the SRPMS (or the source tar balls, or any other piece of source) for any reason except to remove trademarks and copyright info. It is the whole purpose of the CentOS Project.
The bottom line is, people can figure out how to recompile the packages just like we did ... but we don't change the sources. This is not going to change. If you want the sources changed, figure out what needs to be changed and ping on the upstream people as required to change their source files.
They are the ones who can:
1. Make the distro self hosting 2. Get rid of hidden build requirements
The CentOS Project rebuilds upstream sources as released ... if you are looking for "something else", then this is not your distro.
On Feb 22, 2011, at 8:15 PM, Johnny Hughes wrote:
It is the whole purpose of the CentOS Project.
It *IS* a bit daft not to be be permitted to modify dependencies.
Not changing sources (or risking behavioral changes with fepping creaturism) is a different matter.
The bottom line is, people can figure out how to recompile the packages just like we did ... but we don't change the sources. This is not going to change. If you want the sources changed, figure out what needs to be changed and ping on the upstream people as required to change their source files.
They are the ones who can:
- Make the distro self hosting
- Get rid of hidden build requirements
Fixing "hidden" (or more likely missing) dependencies without being able to just add what is needed is a bit arduous I'm sure.
73 de jeff
2011/2/23 Jeff Johnson n3npq@mac.com:
On Feb 22, 2011, at 8:15 PM, Johnny Hughes wrote:
It is the whole purpose of the CentOS Project.
It *IS* a bit daft not to be be permitted to modify dependencies.
Not changing sources (or risking behavioral changes with fepping creaturism) is a different matter.
That's right.
Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
What are you waiting for @ CentOS team??? Until Red Hat released the missing build dependencies?
Then you can probably wait a long time.
Best regards,
Morten
On Wed, Feb 23, 2011 at 02:56:12AM +0100, Morten P.D. Stevens wrote:
Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
"Just", "probably". Do these types of guessing games work out well for you in your professional life?
What are you waiting for @ CentOS team??? Until Red Hat released the missing build dependencies?
Do you wake up in the morning thinking of how you can be the most selfish, arrogant and entitled jerk possible or is it something that comes to you on the spur of the moment?
Then you can probably wait a long time.
It's a shame that releases can't be done in a fully selective manner; if so I would plead with and bribe, if necessary, the CentOS developers to release to everyone *except* you.
Here's a thought for you:
How about you no longer comment in a project DEVELOPMENT channel on those subjects you aren't technically proficient enough to understand? Even better, how about you just go away? Go use another distro or attempt to build your own or buy Redhat or whatever you choose to do; it's quite apparent you aren't happy here and you likely won't ever be so go try something else.
John
2011/2/23 John R. Dennison jrd@gerdesas.com:
On Wed, Feb 23, 2011 at 02:56:12AM +0100, Morten P.D. Stevens wrote:
Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
"Just", "probably". Do these types of guessing games work out well for you in your professional life?
Look here: https://www.scientificlinux.org/distributions/6x/build/problembyrpm
Otherwise you cannot build these packages.
Best regards,
Morten
On Tue, Feb 22, 2011 at 8:41 PM, Morten P.D. Stevens mstevens@imt-systems.com wrote:
2011/2/23 John R. Dennison jrd@gerdesas.com:
On Wed, Feb 23, 2011 at 02:56:12AM +0100, Morten P.D. Stevens wrote:
Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
"Just", "probably". Do these types of guessing games work out well for you in your professional life?
Look here: https://www.scientificlinux.org/distributions/6x/build/problembyrpm
Otherwise you cannot build these packages.
If RedHat were to be assigned a grade of "C" for this, it would surely be interesting to know which distros get a "D" or "F".
Lamar's use of "sniggles" seems more succinct each day as the Team reveals more.
Note that Troy's litmus test in the list is "wouldn't build" and that could explain the difference between Troy's count and Karanbir's count.
Are there honest security types on the list who would like to comment on whether this lack of QA could have potential security ramifications?
On Feb 22, 2011, at 8:56 PM, Morten P.D. Stevens wrote:
Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
What are you waiting for @ CentOS team??? Until Red Hat released the missing build dependencies?
Please note that I did _NOT_ intend to re-start flames or CentOS bashing.
There is however a logical inconsistency between By policy, CentOS changes nothing (but removes trademarks to be legal) and 1. Make the distro self hosting 2. Get rid of hidden build requirements
How does one detect "hidden" if every package is "de facto" and unchangeable by policy?
(aside) And there's even reasons to not change dependencies, because that has some (modest imho) risk of changing depslover (sic) behavior.
But if you CAN detect "hidden" or "missing" (and I'm quite sure Johnny can), then adding a dependency is likely best for everyone involved, policy be damned.
Why re-distribute SRPM's with "hidden" (or missing) dependencies? That kinda misses the point of dependencies in package metadata.
hth
73 de Jeff
On Tue, Feb 22, 2011 at 8:26 PM, Jeff Johnson n3npq@mac.com wrote:
But if you CAN detect "hidden" or "missing" (and I'm quite sure Johnny can), then adding a dependency is likely best for everyone involved, policy be damned.
Why re-distribute SRPM's with "hidden" (or missing) dependencies? That kinda misses the point of dependencies in package metadata.
+1 (read: Amen!)
2011/2/23 Jeff Johnson n3npq@mac.com:
On Feb 22, 2011, at 8:56 PM, Morten P.D. Stevens wrote:
Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
What are you waiting for @ CentOS team??? Until Red Hat released the missing build dependencies?
Please note that I did _NOT_ intend to re-start flames or CentOS bashing.
Hi Jeff,
Don't get me wrong. No one here is interested in bashing CentOS or whatever.
It's only about improving the development process.
Best regards,
Morten
Jeff Johnson wrote:
On Feb 22, 2011, at 8:56 PM, Morten P.D. Stevens wrote:
Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
What are you waiting for @ CentOS team??? Until Red Hat released the missing build dependencies?
Please note that I did _NOT_ intend to re-start flames or CentOS bashing.
There is however a logical inconsistency between By policy, CentOS changes nothing (but removes trademarks to be legal) and
- Make the distro self hosting
- Get rid of hidden build requirements
How does one detect "hidden" if every package is "de facto" and unchangeable by policy?
(aside) And there's even reasons to not change dependencies, because that has some (modest imho) risk of changing depslover (sic) behavior.
But if you CAN detect "hidden" or "missing" (and I'm quite sure Johnny can), then adding a dependency is likely best for everyone involved, policy be damned.
Why re-distribute SRPM's with "hidden" (or missing) dependencies? That kinda misses the point of dependencies in package metadata.
I'll try to explain the purpose of CentOS project in layman terms.
Many business applications are written for RHEL, some of them specifically relaying on "bugs" if they could be called that. So if you want to create the "free" copy of RHEL source code and at the same time make sure that ALL applications for RHEL will also work for your distro.
This goal of binary compatibility serves multiple purposes: 1. Red Hat has free version of RHEL so vast number of people can educate on it and if they choose use it for non-time-critical systems.
2. Software developers have wider user base for software developed/ported for RHEL, making their development more profitable, with lesser development cost per sold license.
3. User can sleep peacefully knowing that Red Hat is behind the actual development of their OS, and knowing that, if they choose so (need for support, their business/systems becoming time/mission critical), they can CONVERT their CentOS to RHEL by JUST buying subscription license and changing from where yum gets it's upgrades. There is no need to reinstall every single system and databases/applications in order to switch from Open source system to "paid for support" RHEL. Just think how you would feel if you had to reinstall 20-30 servers in the middle of production use just because beancounters decided they want security of 24/7 support.
This last item is why I (and a lot of others) decided to use/learn CentOS (I actually started experimenting with WhiteBox first). Keeping CentOS binary and sources SAME (as in ABSOLUTELY THE SAME as much as possible ) as is in RHEL, makes my knowledge and apps I develop applicable to RHEL if I even run into situation to maintain it or to sell some software for RHEL.
If you are not able to wrap your head around this notion and those purposes are not important to you, then find some other distro or create tour own RHEL respin where you will change SRPMS at your whim, but do not be surprised if only small number of people decides to use it instead of CentOS, since once you start changing SRPMS you will never ever stop and it will not be RHEL respin any more.
Ljubomir
On Tue, Feb 22, 2011 at 7:15 PM, Johnny Hughes johnny@centos.org wrote:
If you want the sources changed, figure out what needs to be changed and ping on the upstream people as required to change their source files.
They are the ones who can:
- Make the distro self hosting
- Get rid of hidden build requirements
"This running a Government is kinder like our movie business. You are only as good as your last picture." Will Rogers (1935), ibid., 37.
Two great loads/////pictures in one day, Johnny!
At the same time, this sub-thread would have been much shorter if you had made the pictures much earlier. Private emails from well informed sources have suggested that _several_ platforms are used).
On Tue, Feb 22, 2011 at 08:17:11PM -0600, Larry Vaden wrote:
At the same time, this sub-thread would have been much shorter if you had made the pictures much earlier. Private emails from well informed sources have suggested that _several_ platforms are used).
You're another one. You're about as technically competent as a garden gnome. Can you please stop polluting this list with your rampant prattle and noise? Please? I'd even be willing to pay you to just go the hell away.
John
On Tue, Feb 22, 2011 at 8:19 PM, John R. Dennison jrd@gerdesas.com wrote:
On Tue, Feb 22, 2011 at 08:17:11PM -0600, Larry Vaden wrote:
At the same time, this sub-thread would have been much shorter if you had made the pictures much earlier. Private emails from well informed sources have suggested that _several_ platforms are used).
You're another one. You're about as technically competent as a garden gnome. Can you please stop polluting this list with your rampant prattle and noise? Please? I'd even be willing to pay you to just go the hell away.
John
We only think when we are confronted with problems.
-- John Dewey (1859-1952), American philosopher, educator
John, Will Rogers was right; I think every time you want to call someone ignorant, you should point out one of your own ignorances and reduce you sig line count by one each time also, so that you are eventually in compliance with list guidelines about sig length. e.g., if you could redact/modify the above post, you would only need to utter 4 things about which about which you are as ignorant as you claim several of us are. Or, maybe you are a little fascist practicing to be a big Fascist. In America, the majority (> 50%) rules; in Ralph's Germany, you need 5% (as the Green Party knows so well) to have representation.
Larry Vaden wrote:
On Tue, Feb 22, 2011 at 8:19 PM, John R. Dennison jrd@gerdesas.com wrote:
On Tue, Feb 22, 2011 at 08:17:11PM -0600, Larry Vaden wrote:
At the same time, this sub-thread would have been much shorter if you had made the pictures much earlier. Private emails from well informed sources have suggested that _several_ platforms are used).
You're another one. You're about as technically competent as a garden gnome. Can you please stop polluting this list with your rampant prattle and noise? Please? I'd even be willing to pay you to just go the hell away. John-- We only think when we are confronted with problems.
-- John Dewey (1859-1952), American philosopher, educator
John, Will Rogers was right; I think every time you want to call someone ignorant, you should point out one of your own ignorances and reduce you sig line count by one each time also, so that you are eventually in compliance with list guidelines about sig length. e.g., if you could redact/modify the above post, you would only need to utter 4 things about which about which you are as ignorant as you claim several of us are. Or, maybe you are a little fascist practicing to be a big Fascist. In America, the majority (> 50%) rules; in Ralph's Germany, you need 5% (as the Green Party knows so well) to have representation.
More precise would be to say:
In America, the majority (> 50%) of those voting (36%-56%) rules.
So essentially 18%-28% should rule. When you add that big companies are allowed to legally lobby (Only in America?) for their profit (and recent lobbying affairs), and the fact that no one has access to examine the code of the software calculating votes (so software company can change the code to show what ever they want and in doing so change the results of election) and there is no paper trail, it turns out that in fact tiny minority rules in America. Australia is another matter. Voting there is compulsory and voter turnout is always ~95%. Sorry to burst your bubble on this one.
And you are absolutely ignorant (or at least perceived in this way) when it comes to package/distro building/recompiling. I can understand if you want to learn, but your way of learning is not productive, just extremly irritant. You need to burst your bubble of misconceptions and start over by first questioning every stand you have with thorough research before you accept it. It can be scary, but also a lot of fun, from first hand self-questioning experience I've had so far.
Ljubomir
On Tue, 22 Feb 2011, Johnny Hughes wrote:
I am aware, but it also is very important that we (the CentOS Project) do not change the SRPMS (or the source tar balls, or any other piece of source) for any reason except to remove trademarks and copyright info. It is the whole purpose of the CentOS Project.
The bottom line is, people can figure out how to recompile the packages just like we did ... but we don't change the sources.
No they can not. The bottom line is, people can try to reverse engineer the process CentOS is using, but they may never be sure it's like what CentOS did. So your statement is incorrect.
Hence my joke that the 'C' in CentOS actually means Closed.
That said, if CentOS wants it this way they sure have every right to do it like this. But it would be nice to state that upfront.
Hi Dag,
On 02/23/2011 10:01 AM, Dag Wieers wrote:
No they can not. The bottom line is, people can try to reverse engineer the process CentOS is using, but they may never be sure it's like what CentOS did. So your statement is incorrect.
I am not sure how to say this any other way, its been said many times over and over again : we dont use any super magic juice anywhere, its mostly just mock in a for loop. Lets assume that there still exists some fear and doubt somewhere about the process in exact terms.
then lets take up the conversation on list where I said that once 6 is our of the door, I'll document what and how things worked for the build process ( including the pause's and why they took place. Would that remove some of this FUD layers ?
Hence my joke that the 'C' in CentOS actually means Closed.
I dont agree, if you said 'C' in CentOS is mispelled 'Slower than ideal', I'd agree :)
That said, if CentOS wants it this way they sure have every right to do it like this. But it would be nice to state that upfront.
Propose a wording snippet ?
- KB
On Wed, Feb 23, 2011 at 10:59:28AM +0000, Karanbir Singh wrote:
Hi Dag,
On 02/23/2011 10:01 AM, Dag Wieers wrote:
No they can not. The bottom line is, people can try to reverse engineer the process CentOS is using, but they may never be sure it's like what CentOS did. So your statement is incorrect.
I am not sure how to say this any other way, its been said many times over and over again : we dont use any super magic juice anywhere, its mostly just mock in a for loop. Lets assume that there still exists some fear and doubt somewhere about the process in exact terms.
then lets take up the conversation on list where I said that once 6 is our of the door, I'll document what and how things worked for the build process ( including the pause's and why they took place. Would that remove some of this FUD layers ?
A good start for this is available at http://www.scientificlinux.org/distributions/6x/build/
Some further bits are also available in bugzilla reports at redhat.com, so this should really be updated to reflectthe complete data, also from the CentOS project.
Hence my joke that the 'C' in CentOS actually means Closed.
I dont agree, if you said 'C' in CentOS is mispelled 'Slower than ideal', I'd agree :)
That said, if CentOS wants it this way they sure have every right to do it like this. But it would be nice to state that upfront.
Propose a wording snippet ?
Having the discussion on how to move between Closed / Slow / Community is hopefully a good sign for the project. It hurts that rebuilding parts of e.g. 5.6 is so easy and we seem to spoil any efford to combine forces for a quick rebuild that also builds up more and more knowledge for a solid rebuild...
best regards,
Florian La Roche
On Wed, 23 Feb 2011, Karanbir Singh wrote:
On 02/23/2011 10:01 AM, Dag Wieers wrote:
No they can not. The bottom line is, people can try to reverse engineer the process CentOS is using, but they may never be sure it's like what CentOS did. So your statement is incorrect.
I am not sure how to say this any other way, its been said many times over and over again : we dont use any super magic juice anywhere, its mostly just mock in a for loop. Lets assume that there still exists some fear and doubt somewhere about the process in exact terms.
The modifications (of the buildsystem/process) per package is the magic juice.
Again I don't mind if that's the case, but if there's a reason it takes weeks/months for a release to go into QA, then obviously it doesn't all build fine in mock.
then lets take up the conversation on list where I said that once 6 is our of the door, I'll document what and how things worked for the build process ( including the pause's and why they took place. Would that remove some of this FUD layers ?
That would be great. The upside of having all releases in a small timeframe is that there's more time in between releases ! I don't think it's about FUD, fact is that people don't understand why it takes so long and don't understand why they cannot helps speed up the process.
On the other hand some of the developers blame the ignorance of users, so a clear and transparent process may bring more people up to a higher level to understand and make better suggestions.
Hence my joke that the 'C' in CentOS actually means Closed.
I dont agree, if you said 'C' in CentOS is mispelled 'Slower than ideal', I'd agree :)
Of course, it's not completely closed. Looking in a thesaurus, the only thing coming close to 'Slow' in there that starts with a C is Constipated ;-)
That said, if CentOS wants it this way they sure have every right to do it like this. But it would be nice to state that upfront.
Propose a wording snippet ?
Well, as you promised to open it up after the release, there's no reason to debate it now. Maybe some of the content of the presentation (pros/cons) should be on the wiki in an About section, it would at least change what people expected.
I think the biggest problem is that people expect something else than what is implied, delivered and/or promised, maybe because in the past releases were quicker, or communication was different, or because one simply expects that more is being automated and hence releases are quicker.
On Wed, Feb 23, 2011 at 7:59 AM, Dag Wieers dag@wieers.com wrote:
Hence my joke that the 'C' in CentOS actually means Closed.
I dont agree, if you said 'C' in CentOS is mispelled 'Slower than ideal', I'd agree :)
Of course, it's not completely closed. Looking in a thesaurus, the only thing coming close to 'Slow' in there that starts with a C is Constipated ;-)
Congealed?
That said, if CentOS wants it this way they sure have every right to do it like this. But it would be nice to state that upfront.
Propose a wording snippet ?
Well, as you promised to open it up after the release, there's no reason to debate it now. Maybe some of the content of the presentation (pros/cons) should be on the wiki in an About section, it would at least change what people expected.
I think the biggest problem is that people expect something else than what is implied, delivered and/or promised, maybe because in the past releases were quicker, or communication was different, or because one simply expects that more is being automated and hence releases are quicker.
For example, I'd appreciate a hint as to which version of mock you're using. I'd previously suggested upgrading from the CentOS 5 one, but the latest epel-testing one is giving me problems and spewing errors when I try to compile *anything*. The epel default one works, but is relatively slow due to mishandling of bulky and unnecessary files such as /var/log/lastlog in the cached tarballs.
The one from RPMforge seems to be working well. (Thanks, Dag and your comrades over at RPMforge!!!!)
Hello Nico,
On Wed, 2011-02-23 at 08:08 -0500, Nico Kadel-Garcia wrote:
For example, I'd appreciate a hint as to which version of mock you're using.
Of the top of my head I would say 1.1.6 but I could be mistaken. What I am sure about is that this should be in the archives. It's been mentioned a couple of times in mails from Karanbir in which he indicated not to upgrade the version of mock the CentOS team uses for 6. So it's the same version they used for 5 and perhaps even 4.
Regards, Leonard.
On 2/23/11 4:59 AM, Karanbir Singh wrote:
I am not sure how to say this any other way, its been said many times over and over again : we dont use any super magic juice anywhere, its mostly just mock in a for loop. Lets assume that there still exists some fear and doubt somewhere about the process in exact terms.
If it is just mock in a for loop, then wouldn't spreading it over more machines be guaranteed to make it complete faster? And if you drop the problem in enough people's laps, maybe someone will come up with a better automation to reverse-engineer the RHEL binaries to predict the correct build order and the right missing libraries. I'm too dumb to do it, so don't bother pointing that out (as Johnny likes to), but it doesn't seem like an impossible problem - or one that should be done case-by-case, manually.
Les Mikesell wrote:
On 2/23/11 4:59 AM, Karanbir Singh wrote:
I am not sure how to say this any other way, its been said many times over and over again : we dont use any super magic juice anywhere, its mostly just mock in a for loop. Lets assume that there still exists some fear and doubt somewhere about the process in exact terms.
If it is just mock in a for loop, then wouldn't spreading it over more machines be guaranteed to make it complete faster? And if you drop the problem in enough people's laps, maybe someone will come up with a better automation to reverse-engineer the RHEL binaries to predict the correct build order and the right missing libraries. I'm too dumb to do it, so don't bother pointing that out (as Johnny likes to), but it doesn't seem like an impossible problem - or one that should be done case-by-case, manually.
You should have few things in mind. My envisioning the rebuilding process is:
1. It was pointed out that they (have) run first mock loop with default/basic environment and selected non-building SRPMS for further analysis and problem solving. They will not re-run SRPMS that can build until they start the final build.
2. When you deal with hidden dependencies, what comes to my mind is to first see dependencies from Fedora12(+) packages by *manually* extracting and comparing .spec files one SRPMS at the time (everybody from team was assigned part of the non-building SRPMS).
3. Dependencies that are found to be missing are added to the building list, and if there are no SRPMS for them bug is filed to Red Hat and then I guess they add the SRPM from Fedora and reconfigure the .spec file, or maybe wait for Red Hat to publish missing SRPM.
4. SRPMS that have dependencies that will not build left for the end.
5. For those SRPMS that only have missing dependency, they start comfiguring mock config that will allow them to build that SRPMS.
6. Built RPMS from item 5 are then compared to the RHEL original. If they pass the test, their mock config if filed for final build and package is marked solved. If RPMS are not the same as RHEL's, they have to, again manually, to find why, what is different. This comparing is mostly done one by one, as soon as one of the team members thinks (s)he finished it.
As you can see, there is no much automation going on except for few initial runs, just hard manual labor and frustration. I have tried to compile many packages for CentOS 5.x that depend on much newer core files, and finding out what packages I also need to recompile from Fedora was highly frustrating, and I was just using known dependencies from existing .spec files.
Certain packages (especially their newer versions) would have as much as 15-20 dependencies (6-7 layers of dependencies deep) until I would hit some core package I was unwilling to change. And then I would start with older package version hopping that they do nor require those core packages.
It would take me even 10-12 hours (until I learn how to cut it shorter), for a single package.
Ljubomir
On 2/23/2011 9:34 AM, Ljubomir Ljubojevic wrote:
- When you deal with hidden dependencies, what comes to my mind is to
first see dependencies from Fedora12(+) packages by *manually* extracting and comparing .spec files one SRPMS at the time (everybody from team was assigned part of the non-building SRPMS).
Aren't there some tools that are designed to find binary similarities (think anti-virus or things that try to detect copied code sections)? ldd should tell you about any dynamically-linked libraries needed, but there should be a way to fingerprint the likely suspect libraries and identify static libs that are linked - at least to the extent you could identify a code virus in a binary.
- Built RPMS from item 5 are then compared to the RHEL original.
Can't whatever they are comparing here be used directly in some clever test to predict what would be needed instead of a trial and error approach?
As you can see, there is no much automation going on except for few initial runs, just hard manual labor and frustration.
What happens with script-language packages that do their own equivalent of dynamic linking at runtime?
I have tried to compile many packages for CentOS 5.x that depend on much newer core files, and finding out what packages I also need to recompile from Fedora was highly frustrating, and I was just using known dependencies from existing .spec files.
Certain packages (especially their newer versions) would have as much as 15-20 dependencies (6-7 layers of dependencies deep) until I would hit some core package I was unwilling to change. And then I would start with older package version hopping that they do nor require those core packages.
It would take me even 10-12 hours (until I learn how to cut it shorter), for a single package.
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds. And if those people aren't part of the trusted few, they could send back the info needed to duplicate the build. But, I suppose you'd need to export hash fingerprints or something similar to test against for people who don't have access to the official RHEL binaries.
On Wed, Feb 23, 2011 at 10:11 AM, Les Mikesell lesmikesell@gmail.com wrote:
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds.
History seems irrelevant to many; if that is the case with the reader, hit DELETE now.
Soon to be 50 years ago, Control Data's SCOPE (simultaneous control of program execution) had 'lgo' (load-and-go) which obviously had to resolve dependencies at run-time, and it produced a load map. It would seem this approach would be useful, but I dunno.
Perhaps it is a tool that Jeff or someone would like to investigate further, perhaps not. IMHO, there's nothing unfathomable about a package reaching out to include other packages.
IFF this turns out to be a useful approach, I would like to thank Dr. James Browne at utexas.edu for his mentoring of our group, particularly for his guidance in scheduling and proving program correctness.
Larry Vaden wrote:
On Wed, Feb 23, 2011 at 10:11 AM, Les Mikesell lesmikesell@gmail.com wrote:
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds.
History seems irrelevant to many; if that is the case with the reader, hit DELETE now.
Soon to be 50 years ago, Control Data's SCOPE (simultaneous control of program execution) had 'lgo' (load-and-go) which obviously had to resolve dependencies at run-time, and it produced a load map. It would seem this approach would be useful, but I dunno.
Perhaps it is a tool that Jeff or someone would like to investigate further, perhaps not. IMHO, there's nothing unfathomable about a package reaching out to include other packages.
IFF this turns out to be a useful approach, I would like to thank Dr. James Browne at utexas.edu for his mentoring of our group, particularly for his guidance in scheduling and proving program correctness.
This is not just a simple "find a library" task, sometimes you need to find out what *exact* version of the called library *must* be used to keep compatibility (in case of hidden dependency without published matching SRPMS) with RHEL.
Ljubomir
On Wed, Feb 23, 2011 at 11:24 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
This is not just a simple "find a library" task, sometimes you need to find out what *exact* version of the called library *must* be used to keep compatibility (in case of hidden dependency without published matching SRPMS) with RHEL.
IMHO, the binary, when invoked on the system one is trying to clone, presents all necessary information for the interested reader to digest.
At this moment, apparently, the only interested reader of said binary is the load routine :(
Whether it is a jump to 'panic' or a return jump to invoke a library routine, it is available for the interested reader of the binary.
This process worked in a tightly clustered group of 31 processors where the object of the invocation could be in the memory of the CPU (or need to be loaded) or it could be in the memory of a PPU (or need to be loaded), of which there were 30.
Of course, there was a prologue section for each callable routine which identified it and its version number among other things and that may or may not exist in RHEL, I dunno.
Les Mikesell wrote:
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds. And if those people aren't part of the trusted few, they could send back the info needed to duplicate the build. But, I suppose you'd need to export hash fingerprints or something similar to test against for people who don't have access to the official RHEL binaries.
I agree it would go faster, but core of the team would have to hold new arrivals by the hand most of the time. This is not practical in the middle or on the start of the rebuild process.
I do not believe that absolutely all interested should be included in the rebuild process, just ones with existing packaging experience, to avoid havoc.
My suggestion would be that once versions 4.9, 5.6 and 6.0 are out core team creates environment exactly as is now for 6.0, and take some apprentices under their wing, people with enough existing knowledge, and drop them head first into rebuilding process (with proficiently documented process), so they can select candidates for additional rebuild members and train them. Questions candidates would ask would be used to fill the documentation and FAQ for rebuilding process, weather it is for public or "private" use.
Ljubomir
On Wednesday, February 23, 2011 11:11:57 am Les Mikesell wrote:
Aren't there some tools that are designed to find binary similarities (think anti-virus or things that try to detect copied code sections)?
Can't whatever they are comparing here be used directly in some clever test to predict what would be needed instead of a trial and error approach?
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds.
Please see if what you're talking about is found in http://mirror.centos.org/centos/build/ (and note the dates).
Note that the built results of some of those SRPMs will be needed for later SRPM builds, and those may need to be done in a deterministic order. IOW, not something easily parallelized.
And do note that some of the packages take a very long time to build; things like KDE, for instance. So if multiple iterations have to happen on a package that takes a long time to build.....
Here's you some homework, Les: build a 'builddep solver' that will tell you in what order the packages need to be built, starting from the bare minimum buildroot. Of course, you don't necessarily know the bare minimum buildroot, and the upstream isn't telling you.
And make it match the released upstream at the binary dependency level. It's not enough to just get the packages to build; the goal is binary and bug-for-bug compatibility.
Now for an arch that upstream doesn't ship you could probably get away without that strict binary level compatibility (say SPARC, for instance, since there is an outside chance an EL6 for SPARC could actually be done, since F12 for SPARC exists in beta form). And, yeah, I'm going to spend some cycles this spring working on that for my own use here, and I'm not planning to hurry with it. Given entitlement syndrome I may not even release it; but may just release instructions on how I did it and let people do it themselves.
But for x86 and x86_64 strict binary-level compatibility seems to be rather elusive.
I haven't run any verification scripts on the SL RC; and even if I were to do that I'd post about it on the SL list, not here....
On 02/24/2011 08:59 AM, Lamar Owen wrote:
On Wednesday, February 23, 2011 11:11:57 am Les Mikesell wrote:
Aren't there some tools that are designed to find binary similarities (think anti-virus or things that try to detect copied code sections)?
Can't whatever they are comparing here be used directly in some clever test to predict what would be needed instead of a trial and error approach?
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds.
Please see if what you're talking about is found in http://mirror.centos.org/centos/build/ (and note the dates).
Note that the built results of some of those SRPMs will be needed for later SRPM builds, and those may need to be done in a deterministic order. IOW, not something easily parallelized.
And do note that some of the packages take a very long time to build; things like KDE, for instance. So if multiple iterations have to happen on a package that takes a long time to build.....
Here's you some homework, Les: build a 'builddep solver' that will tell you in what order the packages need to be built, starting from the bare minimum buildroot. Of course, you don't necessarily know the bare minimum buildroot, and the upstream isn't telling you.
And make it match the released upstream at the binary dependency level. It's not enough to just get the packages to build; the goal is binary and bug-for-bug compatibility.
Now for an arch that upstream doesn't ship you could probably get away without that strict binary level compatibility (say SPARC, for instance, since there is an outside chance an EL6 for SPARC could actually be done, since F12 for SPARC exists in beta form). And, yeah, I'm going to spend some cycles this spring working on that for my own use here, and I'm not planning to hurry with it. Given entitlement syndrome I may not even release it; but may just release instructions on how I did it and let people do it themselves.
But for x86 and x86_64 strict binary-level compatibility seems to be rather elusive.
I haven't run any verification scripts on the SL RC; and even if I were to do that I'd post about it on the SL list, not here....
I also want to throw out "thetango", which was used to bootstrap an ia64 distro for Fedora. The code and the project seem dead now. This suggests a build order based on a group of SRPMS. It is very hard to setup and use, but I have used it when working on C5 sparc in the past:
https://fedorahosted.org/thetango/browser
(Read the README)
And Les ... no, this is NOT easy to do.
Thanks, Johnny
On 02/24/2011 10:47 AM, Johnny Hughes wrote:
On 02/24/2011 08:59 AM, Lamar Owen wrote:
On Wednesday, February 23, 2011 11:11:57 am Les Mikesell wrote:
Aren't there some tools that are designed to find binary similarities (think anti-virus or things that try to detect copied code sections)?
Can't whatever they are comparing here be used directly in some clever test to predict what would be needed instead of a trial and error approach?
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds.
Please see if what you're talking about is found in http://mirror.centos.org/centos/build/ (and note the dates).
Note that the built results of some of those SRPMs will be needed for later SRPM builds, and those may need to be done in a deterministic order. IOW, not something easily parallelized.
And do note that some of the packages take a very long time to build; things like KDE, for instance. So if multiple iterations have to happen on a package that takes a long time to build.....
Here's you some homework, Les: build a 'builddep solver' that will tell you in what order the packages need to be built, starting from the bare minimum buildroot. Of course, you don't necessarily know the bare minimum buildroot, and the upstream isn't telling you.
And make it match the released upstream at the binary dependency level. It's not enough to just get the packages to build; the goal is binary and bug-for-bug compatibility.
Now for an arch that upstream doesn't ship you could probably get away without that strict binary level compatibility (say SPARC, for instance, since there is an outside chance an EL6 for SPARC could actually be done, since F12 for SPARC exists in beta form). And, yeah, I'm going to spend some cycles this spring working on that for my own use here, and I'm not planning to hurry with it. Given entitlement syndrome I may not even release it; but may just release instructions on how I did it and let people do it themselves.
But for x86 and x86_64 strict binary-level compatibility seems to be rather elusive.
I haven't run any verification scripts on the SL RC; and even if I were to do that I'd post about it on the SL list, not here....
I also want to throw out "thetango", which was used to bootstrap an ia64 distro for Fedora. The code and the project seem dead now. This suggests a build order based on a group of SRPMS. It is very hard to setup and use, but I have used it when working on C5 sparc in the past:
https://fedorahosted.org/thetango/browser
(Read the README)
And Les ... no, this is NOT easy to do.
I Found this ... so someone else seems to have the same idea to use it for CentOS:
On 2/24/2011 10:47 AM, Johnny Hughes wrote:
And Les ... no, this is NOT easy to do.
Which makes it seem like you'd want to attract additional resources that might be able to help. That's the part I'm missing, not the difficulty or time/resource consuming nature of the problem.
On 02/24/2011 10:57 AM, Les Mikesell wrote:
On 2/24/2011 10:47 AM, Johnny Hughes wrote:
And Les ... no, this is NOT easy to do.
Which makes it seem like you'd want to attract additional resources that might be able to help. That's the part I'm missing, not the difficulty or time/resource consuming nature of the problem.
We have released everything that we do ... I am not understanding the problem here.
We released the script we use to check the built RPMS, we released examples of the mock files, we released the ISO and Distro build script, we released the version of software we use on the builders (centos-5, up2date), we even released a list of all the hidden build requirements. There is NOTHING closed. There is NOTHING that someone can't grab and start working on the problem if they want to do so.
What we will not do is give access to our internal infrastructure (the machines) or the ability to actually include anything built someplace else.
The issue here is, no one wants to do the hard work, they just assume that I am holding back some secret sauce (which we are not).
On Thu, Feb 24, 2011 at 11:07 AM, Johnny Hughes johnny@centos.org wrote:
On 02/24/2011 10:57 AM, Les Mikesell wrote:
On 2/24/2011 10:47 AM, Johnny Hughes wrote:
And Les ... no, this is NOT easy to do.
Which makes it seem like you'd want to attract additional resources that might be able to help. That's the part I'm missing, not the difficulty or time/resource consuming nature of the problem.
We have released everything that we do ... I am not understanding the problem here.
We released the script we use to check the built RPMS, we released examples of the mock files, we released the ISO and Distro build script, we released the version of software we use on the builders (centos-5, up2date), we even released a list of all the hidden build requirements. There is NOTHING closed. There is NOTHING that someone can't grab and start working on the problem if they want to do so.
Specifically where is all this released? I have looked, I see only a tmrpmverify from 2007.
Ant.
On Thursday, February 24, 2011 12:23:23 pm Antaryami Khuda wrote:
Specifically where is all this released? I have looked, I see only a tmrpmverify from 2007.
Perhaps they're still using the same version, because it still works?
Also please look in http://mirror.centos.org/centos/build/
While one might think "oh, that's just old stuff" perhaps one should consider that 'if it ain't broke, don't fix it' and 'if the old rev works, use it.' IncrementVersionItis is a plague, and when an old version of a script still works just fine, you don't rev the version just to get a later date..... Hrmph, I'm still using scripts and things in production that were originally written in 1997, and they still do the job they were written to do; why should I care if it's an old script, as long as it works.
Much of the rest is in the centos-devel archives. You need to bootstrap yourself in how mock is being used to do this, and how it works, and then look at how a rebuild is done, from SRPMs.
To quote Po from Kung Fu Panda (one of my three and eight year olds' favorite movies at the moment) "There is no secret ingredient!" There has been enough information crossed this list to do the job at this point.
On 02/24/2011 11:23 AM, Antaryami Khuda wrote:
On Thu, Feb 24, 2011 at 11:07 AM, Johnny Hughes <johnny@centos.org mailto:johnny@centos.org> wrote:
On 02/24/2011 10:57 AM, Les Mikesell wrote: > On 2/24/2011 10:47 AM, Johnny Hughes wrote: >> >> And Les ... no, this is NOT easy to do. >> > > Which makes it seem like you'd want to attract additional resources that > might be able to help. That's the part I'm missing, not the difficulty > or time/resource consuming nature of the problem. > We have released everything that we do ... I am not understanding the problem here. We released the script we use to check the built RPMS, we released examples of the mock files, we released the ISO and Distro build script, we released the version of software we use on the builders (centos-5, up2date), we even released a list of all the hidden build requirements. There is NOTHING closed. There is NOTHING that someone can't grab and start working on the problem if they want to do so.Specifically where is all this released? I have looked, I see only a tmrpmverify from 2007.
Ant.
http://people.centos.org/hughesjr/buildsystem/
http://mirror.centos.org/centos-4/4/build/distro/
http://lists.centos.org/pipermail/centos/2011-February/106570.html
On Thursday, February 24, 2011 11:47:18 am Johnny Hughes wrote:
I also want to throw out "thetango", which was used to bootstrap an ia64 distro for Fedora. The code and the project seem dead now. This suggests a build order based on a group of SRPMS. It is very hard to setup and use, but I have used it when working on C5 sparc in the past:
Cool; thanks for the pointer.
On Thursday, February 24, 2011 11:47:18 am Johnny Hughes wrote:
https://fedorahosted.org/thetango/browser
(Read the README)
No kidding. The README alone is a great resource.
On 2/24/2011 8:59 AM, Lamar Owen wrote:
On Wednesday, February 23, 2011 11:11:57 am Les Mikesell wrote:
Aren't there some tools that are designed to find binary similarities (think anti-virus or things that try to detect copied code sections)?
Can't whatever they are comparing here be used directly in some clever test to predict what would be needed instead of a trial and error approach?
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds.
Please see if what you're talking about is found in http://mirror.centos.org/centos/build/ (and note the dates).
Note that the built results of some of those SRPMs will be needed for later SRPM builds, and those may need to be done in a deterministic order. IOW, not something easily parallelized.
So you want me to build gcc starting from nothing but SRPMs? I think the premise is wrong here.
And do note that some of the packages take a very long time to build; things like KDE, for instance. So if multiple iterations have to happen on a package that takes a long time to build.....
Here's you some homework, Les: build a 'builddep solver' that will tell you in what order the packages need to be built, starting from the bare minimum buildroot. Of course, you don't necessarily know the bare minimum buildroot, and the upstream isn't telling you.
Again, your premise is wrong. I'm not claiming _I_ can solve this problem. Any more than I could have added all the parts to Linux that Linus didn't write by himself. My contention is that if Linus had made people prove they were worthy before letting them have a copy of his work. we wouldn't be talking about Linux as something useful today. And likewise, if enough smart people have access to each others' work on this problem, someone will improve the state of the art. But, I don't see the point of a bare minimum buildroot anyway.
And make it match the released upstream at the binary dependency level. It's not enough to just get the packages to build; the goal is binary and bug-for-bug compatibility.
Which means you have to have access to all of the already-built binary RPMS to test against and since you aren't going to change the SRPMs to fix any missing dependencies, you might as well throw them all in your build environment from the start, then repeat later in an environment built from your first-run output to purge any possible static inclusions of the trademarked parts. The hard parts come when the shipping RHEL versions won't actually rebuild a match to their binary and you have to guess at whether some fedora or RHEL 5.x version of some needed library happened to be available to the original build without the matching dependency noted in the SRPM or the inclusion of that library in the binary RPMs.
If I've gotten that wrong, that still doesn't change my belief that either someone, somewhere is smart enough to come up with an automated approach or that a lot of people using a trial-and-error approach on a larger number of machines could do it faster. But I'm willing to admit that is approaching religion even though there is a lot of history to back up the idea of getting unexpected improvements by opening projects.
On Thursday, February 24, 2011 11:49:41 am Les Mikesell wrote:
So you want me to build gcc starting from nothing but SRPMs? I think the premise is wrong here.
But that is exactly what has to be done, here. Not only does gcc have to be rebuilt from source RPM, it has to be built with the same build dependencies and binary linkages as upstream, without patching the source RPM. Multiply the effort by the number of packages in EL6, including glibc, kernel, etc. ALL of the packages require a from-source rebuild, and different ones apparently require some finagling of the contents of the buildroot or of the repos from which the buildroot is populated. This is hard, sequential, work. Once the full dep tree is built, then it can be analyzed to see how it can be paralleled; and so C6.x where x>0 won't be quite as big of a task. Getting the sequence correct *is* the hard part, and a fully rebuilt system happens to be the side-effect of getting the sequence correct.
And I'll be honest about it; it's just been in the last two weeks that I really started grasping the full magnitude of what bootstrapping from SRPM-only (with a bare minimum buildroot to start with) would be like. Oh, believe you me, I *thought* I understood.
And maybe I still don't fully grasp it; but, if nothing else, the last couple of weeks of threads on this list have given me the motivation and maybe even the tools and a start at the skillset to bootstrap my own EL6 rebuild on SPARC; to the point that I just finished grabbing a little over 160GB of various versions of Aurora, Fedora/SPARC, and the two betas of CentOS SPARC (4.2 and a 5.x) lying around to seed things. We'll see how it goes, but I don't expect it to go fast. Even on the E6500 here, with 16 CPU's and 18GB of RAM, I expect the builds themselves to take a long time.....
And I'm going to do the grunt work of it for my own educational benefit; if that produces a useful rebuild, that will allow me to put our cache of SPARC boxen to good use, that will be a nice side-effect; essentially, I want to do it so that I can, well, say that I've done it. And unless I miss my guess, everything I need to do it is now out there; it's my turn to figure out how the pieces go together.
If I've gotten that wrong, that still doesn't change my belief that either someone, somewhere is smart enough to come up with an automated approach or that a lot of people using a trial-and-error approach on a larger number of machines could do it faster.
The more automated approach is out there, and it's called koji, but the hard work of figuring out what binary packages from which repo are required in the buildroot is still not automatic, as can be seen on Troy's SL pages. The SL folk have been working on the buildsystem since June (IIRC).
Honestly, I don't know enough about the behind-the-scenes SL work to be able to speculate on how close to binary-compatible SL is or will be, so I'll not comment on that.
On 02/23/2011 04:01 AM, Dag Wieers wrote:
On Tue, 22 Feb 2011, Johnny Hughes wrote:
I am aware, but it also is very important that we (the CentOS Project) do not change the SRPMS (or the source tar balls, or any other piece of source) for any reason except to remove trademarks and copyright info. It is the whole purpose of the CentOS Project.
The bottom line is, people can figure out how to recompile the packages just like we did ... but we don't change the sources.
No they can not. The bottom line is, people can try to reverse engineer the process CentOS is using, but they may never be sure it's like what CentOS did. So your statement is incorrect.
Hence my joke that the 'C' in CentOS actually means Closed.
That said, if CentOS wants it this way they sure have every right to do it like this. But it would be nice to state that upfront.
W#e did state it up front ... no changes to the SRPMS except for trademark changes. ===================================================================================== We stated here in 2003:
http://www.centos.org/modules/tinycontent/index.php?id=5
"CentOS uses the original sources whenever possible. Under normal circumstances CentOS will NOT add patches to original upstream source packages. The vast majority of changes made will be made to comply with the upstream vendor's re-distribution policies concerning trademarked names or logos." ===================================================================================== We stated it here in 2003:
"CentOS exists to provide a free enterprise class computing platform to anyone who wishes to use it. CentOS 2, 3, and 4 are built from publically available open source SRPMS provided by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork.)."
===================================================================================== We stated it here in 2004:
http://www.centos.org/modules/smartfaq/faq.php?faqid=11
"Does CentOS change the upstream Source RPMs?
No. CentOS' key mandate for our base and updates repositories is NOT extending or enhancing packages or features beyond those supplied by the upstream Source RPM's." =====================================================================================
We have stated numerous times over the last 7+ years that we are not changing that policy.
You have been bellyaching about this for the entire 8 years ... for you now to come here and say that we should have told you up front is unbelievably disingenuous. You have been told this dozens of times by me alone.
So, am I now also a bald-face liar as well as a totally incompetent maintainer? Haven't been told up front that we don't change sources ... Really, Dag ... REALLY?
On Wed, 23 Feb 2011, Johnny Hughes wrote:
On 02/23/2011 04:01 AM, Dag Wieers wrote:
On Tue, 22 Feb 2011, Johnny Hughes wrote:
I am aware, but it also is very important that we (the CentOS Project) do not change the SRPMS (or the source tar balls, or any other piece of source) for any reason except to remove trademarks and copyright info. It is the whole purpose of the CentOS Project.
The bottom line is, people can figure out how to recompile the packages just like we did ... but we don't change the sources.
No they can not. The bottom line is, people can try to reverse engineer the process CentOS is using, but they may never be sure it's like what CentOS did. So your statement is incorrect.
Hence my joke that the 'C' in CentOS actually means Closed.
That said, if CentOS wants it this way they sure have every right to do it like this. But it would be nice to state that upfront.
-snip-
You have been bellyaching about this for the entire 8 years ... for you now to come here and say that we should have told you up front is unbelievably disingenuous. You have been told this dozens of times by me alone.
So, am I now also a bald-face liar as well as a totally incompetent maintainer? Haven't been told up front that we don't change sources ... Really, Dag ... REALLY?
Johnny, cool down and read what I said. I am not even talking about SRPMS, you bring that up every single time. I talk about the changes to the *process* to make packages build and binary compatible.
If it was a simple as rebuilding packages in mock, we wouldn't even be discussing it here. A bunch of packages don't build cleanly without help, that's what we've been talking about. (eg. all the stuff Farkas opened bugzilla entries for)
But for me this is closed now, Karanbir promised to open those bits and I am sure this will help the community understand and discuss how we can open the process for a next release.
I wouldn't mind maintaining a list of questions/answers on the wiki, since I have plenty of those that could shed a light on the process.
Hello Dag,
On Wed, 2011-02-23 at 13:51 +0100, Dag Wieers wrote:
A bunch of packages don't build cleanly without help, that's what we've been talking about. (eg. all the stuff Farkas opened bugzilla entries for)
FYI, most of these build failures are with a version of mock that has the device node /dev/tty setup in the build root. This causes some of the build tests to fail.
I think mock-1.1.6 (the one the CentOS team is using if I'm not mistaken) does not suffer from this issue because that node is not there and the tests that fail with 1.1.8 are just skipped.
The solution for mock-1.1.9 seems to be to remove that device node for many versions of host systems, because there is uncertainty on how to add that device node correctly (https://bugzilla.redhat.com/show_bug.cgi?id=609201).
Regards, Leonard.
Hello Jonny,
W#e did state it up front ... no changes to the SRPMS except for trademark changes.
This is a good decision, but then you could also publish the list of changes you do e.g. within the build environment to let other people also work within the same environment. Duplicating the efford done from RHEL -> CentOS to each developer out there who e.g. wants to test a patched src.rpm keeps CentOS smaller than it could be.
On the other side also the page from SL at http://www.scientificlinux.org/distributions/6x/build/ shows that this is not "completely solved" within a script until now and needs further development work.
regards,
Florian La Roche
hi,
On 02/19/2011 07:31 AM, . wrote:
I do believe that if we had a system similar to what Dag is using;
good place to start would be this mailing list archives. Then consider that Rpmforge ( dag is a part of that ) is a very different kind of an issue. There are more model's than 1 of doing this work, I dont understand why people find that such a hard concept to get their heads around.
- KB
On 2/21/2011 7:02 AM, Karanbir Singh wrote:
On 02/19/2011 07:31 AM, . wrote:
I do believe that if we had a system similar to what Dag is using;good place to start would be this mailing list archives. Then consider that Rpmforge ( dag is a part of that ) is a very different kind of an issue. There are more model's than 1 of doing this work, I dont understand why people find that such a hard concept to get their heads around.
I understand completely that there are different models for the process, and I am stating that in my opinion the process rpmforge is using seems to be working better (as far as communities are concerned), and doesn't sound very hard to make work for CentOS. A model that expects people to go through the mailing list archives (even with google helping) doesn't make any sense. We need to make contributing to CentOS easy, currently it is not easy to find out where to start. Even if you find that most of the stuff in the http://wiki.centos.org/QaWiki/6/AuditStatus listed as 'confirmed, action required' have had action and there are patches posted, yet they remain.
by design, we were not looking for people new to the process and to CentOS. We were focusing on people who have been on this list for a significant portion of time, people who understand the wider goals. And there are hundreds of them.
I couldn't disagree more. You are in a situation where people are joining the list eager to help with Centos 6, but are being turned away due to it being difficult to find out how to help. I don't care if some 1st timer understands the wider goals of the Centos project, if they can make a working patch for a package that currently needs work, where is the problem? Lets use the resources we have available.
On Mon, Feb 21, 2011 at 3:04 PM, . fp@kraptastic.com wrote:
On 2/21/2011 7:02 AM, Karanbir Singh wrote:
by design, we were not looking for people new to the process and to CentOS. We were focusing on people who have been on this list for a significant portion of time, people who understand the wider goals. And there are hundreds of them.
I couldn't disagree more. You are in a situation where people are joining the list eager to help with Centos 6, but are being turned away due to it being difficult to find out how to help. I don't care if some 1st timer understands the wider goals of the Centos project, if they can make a working patch for a package that currently needs work, where is the problem? Lets use the resources we have available.
+1 Nobody *here* is "new" to the process and to CentOS any more than we are "new" to a mouse and keyboard.
jerry
On Mon, Feb 21, 2011 at 03:15:29PM -0600, Jerry Amundson wrote:
+1 Nobody *here* is "new" to the process and to CentOS any more than we are "new" to a mouse and keyboard.
Apparently you are "new" in how you envision things to work otherwise you'd let this go already. If you're unhappy, leave, go elsewhere. If you believe yourself technically competent enough to roll your own, do that. Either way, just let this go, would you?
John
On Mon, Feb 21, 2011 at 4:05 PM, John R. Dennison jrd@gerdesas.com wrote:
On Mon, Feb 21, 2011 at 03:15:29PM -0600, Jerry Amundson wrote:
+1 Nobody *here* is "new" to the process and to CentOS any more than we are "new" to a mouse and keyboard.
Apparently you are "new" in how you envision things to work otherwise you'd let this go already. If you're unhappy, leave, go elsewhere. If you believe yourself technically competent enough to roll your own, do that. Either way, just let this go, would you?
I'll forgive, but I won't forget.
jerry
On Mon, Feb 21, 2011 at 04:42:53PM -0600, Jerry Amundson wrote:
I'll forgive, but I won't forget.
Please take your veiled threats elsewhere, this is neither the time nor the place for such nonsense. If you insist on going down this road please do the rest of the subscribers to this list the courtesy of continuing out-of-band - the above email address is valid; I suggest using it.
John
On 02/21/2011 10:42 PM, Jerry Amundson wrote:
Nobody *here* is "new" to the process and to CentOS any more than we are "new" to a mouse and keyboard.
I dont accept that - its just FUD. People who missing postings about how the process might work are automatically too-new to get involved. Its not a hard concept.
I'll forgive, but I won't forget.
on the other hand, you could actually get involved and do something to help :)
- KB
On Mon, Feb 21, 2011 at 01:04:17PM -0800, . wrote:
I understand completely that there are different models for the process, and I am stating that in my opinion the process rpmforge is using seems to be working better (as far as communities are concerned), and doesn't sound very hard to make work for CentOS. A model that expects people to go through the mailing list archives (even with google helping) doesn't make any sense. We need to make contributing to CentOS easy, currently it is not easy to find out where to start. Even if you find that most of the stuff in the http://wiki.centos.org/QaWiki/6/AuditStatus listed as 'confirmed, action required' have had action and there are patches posted, yet they remain.
Why do you and others attempt to compare Dag's work against that of the CentOS project? This is comparing apples to farm tractors - the projects are completely different with different requirements and different end goals. This should really be clear to *everyone* taking part in this thread and the others; if it's not you need to take a step back and think about it for a while.
I couldn't disagree more. You are in a situation where people are joining the list eager to help with Centos 6, but are being turned away due to it being difficult to find out how to help. I don't care if some 1st timer understands the wider goals of the Centos project, if they can make a working patch for a package that currently needs work, where is the problem? Lets use the resources we have available.
Go start your own rebuild efforts if you think you can do any better. Go get your group of volunteers together and see just how easy it is in practice compared to this pipe dream you and others have about how the process chain *should* work.
Enough is enough already.
John
On 2/21/2011 2:03 PM, John R. Dennison wrote:
Why do you and others attempt to compare Dag's work against that of the CentOS project? This is comparing apples to farm tractors
- the projects are completely different with different
requirements and different end goals. This should really be clear to *everyone* taking part in this thread and the others; if it's not you need to take a step back and think about it for a while.
I am not comparing rpmforge to centos, I'm comparing the methodologies used to maintain the projects ( Dag's post here: http://lists.centos.org/pipermail/centos-devel/2011-February/006689.html). Whilst CentOS doesn't have many files that are patched, this would be useful for the ones that are. Another fun part is here: http://svn.rpmforge.net/svn/trunk/tools/ where they have common tools there for people to use including their mock config. If you don't think that is a better setup than what exists now, I guess we will have to agree to disagree.
I couldn't disagree more. You are in a situation where people are joining the list eager to help with Centos 6, but are being turned away due to it being difficult to find out how to help. I don't care if some 1st timer understands the wider goals of the Centos project, if they can make a working patch for a package that currently needs work, where is the problem? Lets use the resources we have available.
Go start your own rebuild efforts if you think you can do any better. Go get your group of volunteers together and see just how easy it is in practice compared to this pipe dream you and others have about how the process chain *should* work.
Enough is enough already.
Why so quick to turn away someone who clearly wants to help? I'm not trolling, I've put in some small patches, I'm trying to help but find it difficult to know where to go next, I found it very difficult to get started doing anything towards CentOS-6. I think others are having the same experience as I did. I am interested in making their experience easier than mine, and improving the process as a whole (if possible).
Harnessing the power of new people is a good thing, newbs become old school eventually.
Why so quick to turn away someone who clearly wants to help? I'm not trolling, I've put in some small patches, I'm trying to help but find it difficult to know where to go next, I found it very difficult to get started doing anything towards CentOS-6. I think others are having the same experience as I did. I am interested in making their experience easier than mine, and improving the process as a whole (if possible).
Harnessing the power of new people is a good thing, newbs become old school eventually.
Clearly they do not have the bandwidth or interest to bring on additional "help" right now, a better time to offer would be AFTER 6.0 is released and there is a little downtime to devote.
-David
On 2/16/2011 2:59 PM, Matthew Miller wrote:
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
Constantly "Are we there yet" to the devs doesn't do anything but annoy them. Just stay subbed to -devel and watch the chatter if you want updates; that's what I'm doing. I'm waiting on v6 for a major new mail server deployment, and trying to be as patient as possible.
Bugging busy people is not a way to get them to do it any faster!
So I say to the devs - Thank you!
I, for one, will continue to patiently wait and lurk, taking whatever information happens to be shared, without prodding the busy people!
- Nick
On Wed, Feb 16, 2011 at 16:09, Nick Bright nick.bright@valnet.net wrote:
On 2/16/2011 2:59 PM, Matthew Miller wrote:
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh:
http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
Constantly "Are we there yet" to the devs doesn't do anything but annoy them. Just stay subbed to -devel and watch the chatter if you want updates; that's what I'm doing. I'm waiting on v6 for a major new mail server deployment, and trying to be as patient as possible.
Bugging busy people is not a way to get them to do it any faster!
So I say to the devs - Thank you!
I, for one, will continue to patiently wait and lurk, taking whatever information happens to be shared, without prodding the busy people!
- Nick
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
You could say the same for unnecessary scolding. This list is all but silent, and current status is very opaque unless you specifically know where to look, and even then there is no real indication of actual work flow status, only vague inclinations thereof. I have to agree with Dag on this one, especially having watched the past few months regarding people trying to help.
Furthermore, look who you scolded, hardly an example of a backseat 8 year old asking incessant questions. What have you done to help the linux community as a whole in comparison?
-Blake
Matthew Miller wrote:
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
Progress can be tracked on this page: http://wiki.centos.org/QaWiki/6/AuditStatus
It looks like it is regularly updated.
Article did say "few weeks after 5.6 is released", it this context, so my "2-3 weeks more" estimate should be looked as a minimum.
Until 80-90% of AuditStatus items are in bottom table, there is no need to query the developers. I am simply dying for 6.0 to be released, but all we need for now is this Audit page to be able to monitor progress.
Ljubomir
On Thu, 17 Feb 2011, Ljubomir Ljubojevic wrote:
Matthew Miller wrote:
On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
You can read this interview with Karanbir Singh: http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-sing...
- There is about 2-3 weeks more before 6 is released.
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
Progress can be tracked on this page: http://wiki.centos.org/QaWiki/6/AuditStatus
It looks like it is regularly updated.
Article did say "few weeks after 5.6 is released", it this context, so my "2-3 weeks more" estimate should be looked as a minimum.
Until 80-90% of AuditStatus items are in bottom table, there is no need to query the developers. I am simply dying for 6.0 to be released, but all we need for now is this Audit page to be able to monitor progress.
RHEL6.1 is ready for a beta release, it's not unlikely CentOS 6 is released after RHEL6.1 beta (or even RHEL6.1 GA) ?
Dag Wieers wrote:
On Thu, 17 Feb 2011, Ljubomir Ljubojevic wrote:
RHEL6.1 is ready for a beta release, it's not unlikely CentOS 6 is released after RHEL6.1 beta (or even RHEL6.1 GA) ?
Scientific Linux 6.0 is yet to be released, and Oracle Unbreakable DVD's where released only 5 days ago. If CentOS development process/team is so slow, and 4 months behind as someone pointed out, how come SL and Oracle haven't released 6.0 over 2-3 months ago?
I belive I can not scold CentOS dev team about them being slow since I have not contributed anything. And since non-profit CentOS will be only 2-3 weeks (a month at maximum) behind well funded projects, I belive they are doing amazing job. And I do know and appreciate how much you have done for all of us.
Hi Matt,
On 02/16/2011 08:59 PM, Matthew Miller wrote:
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
We were still planning on having thing ready for last weekend, I'd say aiming for this weekend isnt unreasonable on the 5.6 front. 6 should be 2 weeks from 5.6.
Johnny is going to refocus and work with Tru on 4.9; and work on that has started already ( and should not really impact work on 6 )
I'll try and collect all the details etc and work with the other guys to have some sort of a tentative plan in the day today and post that.
- KB
On Thu, Feb 17, 2011 at 06:16:57AM +0000, Karanbir Singh wrote:
Since that interview was about two weeks ago, I don't think it's unreasonable to have a brief status update at this point.
We were still planning on having thing ready for last weekend, I'd say aiming for this weekend isnt unreasonable on the 5.6 front. 6 should be 2 weeks from 5.6.
Johnny is going to refocus and work with Tru on 4.9; and work on that has started already ( and should not really impact work on 6 )
I'll try and collect all the details etc and work with the other guys to have some sort of a tentative plan in the day today and post that.
Thanks -- I appreciate the update.
On 02/16/11 19:21, William L. Sebok wrote:
Any updates on progress, either on 5.6 or 6.0?
Well the earth's still spinning and the poles haven't reversed direction, the sun's still got about 4 billion year's worth of fuel left and I think we already have more than 6.0 billion people on this earth. So pretty good!
Glenn
Good answer. The C in cent means Community.
Sent from my BlackBerry® smartphone, powered by Cricket.
-----Original Message----- From: RedShift redshift@pandora.be Sender: centos-devel-bounces@centos.org Date: Wed, 16 Feb 2011 21:14:19 To: The CentOS developers mailing list.centos-devel@centos.org Reply-To: "The CentOS developers mailing list." centos-devel@centos.org Subject: Re: [CentOS-devel] progress?
On 02/16/11 19:21, William L. Sebok wrote:
Any updates on progress, either on 5.6 or 6.0?
Well the earth's still spinning and the poles haven't reversed direction, the sun's still got about 4 billion year's worth of fuel left and I think we already have more than 6.0 billion people on this earth. So pretty good!
Glenn _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, 16 Feb 2011, dsieme01@yahoo.com wrote:
Good answer. The C in cent means Community.
No, no, you have it all wrong ! The C in CentOS means Closed ;-)
On Wed, Feb 16, 2011 at 6:27 PM, Dag Wieers dag@wieers.com wrote:
On Wed, 16 Feb 2011, dsieme01@yahoo.com wrote:
Good answer. The C in cent means Community.
No, no, you have it all wrong ! The C in CentOS means Closed ;-)
Oh, my, Are you sure it doesn't mean "Catty"? ;-}======== (I had to add the beard: Dag has seen my beard.)
For folks new to this sort of thing, Dag is one of the wonderful people maintaing the RPMforge repository from which contemporary versions and non-RedHat published components such as contemporary git and subversion and nagios and perl modules are available. He's one of the *very* few of us in a position to actually snark at a maintainer of a major open source repository, as someone who does it himself.
When are you coming to the Boston area, Dag? I'm no longer in London, but if you come around here I'm sure I can arrange a gathering with some interesting people.
Dag,
On 02/16/2011 11:27 PM, Dag Wieers wrote:
The C in cent means Community.
No, no, you have it all wrong ! The C in CentOS means Closed ;-)
Thats not helpful, really. I know and thought we had previously established that the idea of this community is mostly alien to you. I am not sure why you insist on going down this route again.
Have you ever considered the idea that the centos developer community ( as opposed to the centos community at large ) are all people who have @redhat.com email address's ?
- KB
On Thu, Feb 17, 2011 at 12:20 AM, Karanbir Singh mail-lists@karan.org wrote:
Have you ever considered the idea that the centos developer community ( as opposed to the centos community at large ) are all people who have @redhat.com email address's ?
Karanbir,
Are you saying the centos developer community consists entirely of RH employees?
If so, that's a true joy to learn!
kind regards/ldv/vaden@texoma.net
On 02/17/2011 06:42 AM, Larry Vaden wrote:
Have you ever considered the idea that the centos developer community ( as opposed to the centos community at large ) are all people who have @redhat.com email address's ?
Are you saying the centos developer community consists entirely of RH employees? If so, that's a true joy to learn!
yum update mail-parser; try again :)
- KB
On Thu, Feb 17, 2011 at 12:43 AM, Karanbir Singh mail-lists@karan.org wrote:
On 02/17/2011 06:42 AM, Larry Vaden wrote:
Have you ever considered the idea that the centos developer community ( as opposed to the centos community at large ) are all people who have @redhat.com email address's ?
Are you saying the centos developer community consists entirely of RH employees? If so, that's a true joy to learn!
yum update mail-parser; try again :)
Thanks for answering again in binary.
On Thu, 17 Feb 2011, Karanbir Singh wrote:
On 02/16/2011 11:27 PM, Dag Wieers wrote:
The C in cent means Community.
No, no, you have it all wrong ! The C in CentOS means Closed ;-)
Thats not helpful, really. I know and thought we had previously established that the idea of this community is mostly alien to you.
I thought we previously established that the CentOS developer(s) were not interested in a transparent development process that would take advantage of the resources of our community to speed up releases.
Have you ever considered the idea that the centos developer community ( as opposed to the centos community at large ) are all people who have @redhat.com email address's ?
You seem to imply that there's only Red Hat and the CentOS community, if that's the case, and we all share the same privileges, where can I download the current state of the rebuild, the build-process, the current state of the changes ?
If this would be transparent, people would be able to help and improve the process. At the moment the community is at mercy to any weaknesses in the process for the security of their systems, held hostage by a handful of (volunteer) developers.
I, for one, do not think it is normal existing user's security is 2 or 3 months at stake. Especially if there are people willing to help in this regard and/or willing to roll their own if needed.
On Thu, Feb 17, 2011 at 7:26 AM, Dag Wieers dag@wieers.com wrote:
On Thu, 17 Feb 2011, Karanbir Singh wrote:
On 02/16/2011 11:27 PM, Dag Wieers wrote:
The C in cent means Community.
No, no, you have it all wrong ! The C in CentOS means Closed ;-)
Thats not helpful, really. I know and thought we had previously established that the idea of this community is mostly alien to you.
I thought we previously established that the CentOS developer(s) were not interested in a transparent development process that would take advantage of the resources of our community to speed up releases.
It's not always that helpful, Dag. Sometimes too many cooks *can* spoil the broth.
Have you ever considered the idea that the centos developer community ( as opposed to the centos community at large ) are all people who have @redhat.com email address's ?
You seem to imply that there's only Red Hat and the CentOS community, if that's the case, and we all share the same privileges, where can I download the current state of the rebuild, the build-process, the current state of the changes ?
I'd also appreciate access to the build tree. Dag's work over at RPMforge is an excellent example of how such an open structure *can* work, and some of us could help detect the bugs earlier.
If this would be transparent, people would be able to help and improve the process. At the moment the community is at mercy to any weaknesses in the process for the security of their systems, held hostage by a handful of (volunteer) developers.
I, for one, do not think it is normal existing user's security is 2 or 3 months at stake. Especially if there are people willing to help in this regard and/or willing to roll their own if needed.
Like me! For example, there are some changes in default structures for .spec files for RHEL 6. (The use of '^global' rather than '%define wherever feasible, and the use of '%BuildArch: noarch' for documentation packages.) I'd be happy to work with the components such as mock that are useful for both architectures and are critical parts of the "extras" utilities. EPEL has been doing this for RHEL 6 compatiblel components, and some modest tweaks would let the same .spec files work well for new and old versions of CentOS.
On Thu, Feb 17, 2011 at 6:26 AM, Dag Wieers dag@wieers.com wrote:
I, for one, do not think it is normal existing user's security is 2 or 3 months at stake.
+1
regards/ldv/vaden@texoma.net
You are free to take source and build your own package or buy redhat, oracle or other. Beating up Volunteers will not serve the community.
We owe the community for their work, not the other way around.
Sent from my BlackBerry® smartphone, powered by Cricket.
-----Original Message----- From: Larry Vaden vaden@texoma.net Sender: centos-devel-bounces@centos.org Date: Thu, 17 Feb 2011 08:13:35 To: The CentOS developers mailing list.centos-devel@centos.org Reply-To: "The CentOS developers mailing list." centos-devel@centos.org Subject: Re: [CentOS-devel] progress?
On Thu, Feb 17, 2011 at 6:26 AM, Dag Wieers dag@wieers.com wrote:
I, for one, do not think it is normal existing user's security is 2 or 3 months at stake.
+1
regards/ldv/vaden@texoma.net _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
theses words are just stupid (sorry, but I'm bored to read stuff like that "if you're unhappy, buy RH and Shut up"):
Ok, so that mean Centos is just a sand box and they should indicate in the web site: "Warning, This projet is just for fun, do not use for production" ???? You cannot, in a side be "an Enterprise-class Linux Distribution" (see http://www.centos.org/) and in the other side said "take source and build your own"; It's important to be coherent .... So if Centos cannot be reactive about security update ... remove the "Enterprise-class" from the web site and be clear about that.
Regards,
js.
Le 17/02/2011 18:20, dsieme01@yahoo.com a écrit :
You are free to take source and build your own package or buy redhat,
oracle or other. Beating up Volunteers will not serve the community.
We owe the community for their work, not the other way around.
Sent from my BlackBerry® smartphone, powered by Cricket.
-----Original Message----- From: Larry Vaden vaden@texoma.net Sender: centos-devel-bounces@centos.org Date: Thu, 17 Feb 2011 08:13:35 To: The CentOS developers mailing list.centos-devel@centos.org Reply-To: "The CentOS developers mailing list." centos-devel@centos.org Subject: Re: [CentOS-devel] progress?
On Thu, Feb 17, 2011 at 6:26 AM, Dag Wieers dag@wieers.com wrote:
I, for one, do not think it is normal existing user's security is 2 or 3 months at stake.
+1
regards/ldv/vaden@texoma.net _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Fellows, Karanbir just answered what we all wanted to know. There are no reasons to keep this stupid conversation/fight.
2011/2/17 jean-seb jsh@interlug.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
theses words are just stupid (sorry, but I'm bored to read stuff like that "if you're unhappy, buy RH and Shut up"):
Ok, so that mean Centos is just a sand box and they should indicate in the web site: "Warning, This projet is just for fun, do not use for production" ???? You cannot, in a side be "an Enterprise-class Linux Distribution" (see http://www.centos.org/) and in the other side said "take source and build your own"; It's important to be coherent .... So if Centos cannot be reactive about security update ... remove the "Enterprise-class" from the web site and be clear about that.
Regards,
js.
Le 17/02/2011 18:20, dsieme01@yahoo.com a écrit :
You are free to take source and build your own package or buy redhat,
oracle or other. Beating up Volunteers will not serve the community.
We owe the community for their work, not the other way around.
Sent from my BlackBerry® smartphone, powered by Cricket.
-----Original Message----- From: Larry Vaden vaden@texoma.net Sender: centos-devel-bounces@centos.org Date: Thu, 17 Feb 2011 08:13:35 To: The CentOS developers mailing list.centos-devel@centos.org Reply-To: "The CentOS developers mailing list." <centos-devel@centos.org
Subject: Re: [CentOS-devel] progress?
On Thu, Feb 17, 2011 at 6:26 AM, Dag Wieers dag@wieers.com wrote:
I, for one, do not think it is normal existing user's security is 2 or 3 months at stake.
+1
regards/ldv/vaden@texoma.net _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFNXTHpu8lcDdFEGbYRAkOJAJ9KqWIdNp2ohDG7MKfHC88iXacBEgCfZhsr qUIfqWDx5PYNv3EA4YkTDMk= =3Fk8 -----END PGP SIGNATURE-----
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
+1 on your response, Taimur.
On Thu, Feb 17, 2011 at 9:37 AM, Taimur Gibran taimurgibran@gmail.comwrote:
Fellows, Karanbir just answered what we all wanted to know. There are no reasons to keep this stupid conversation/fight.
2011/2/17 jean-seb jsh@interlug.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
theses words are just stupid (sorry, but I'm bored to read stuff like that "if you're unhappy, buy RH and Shut up"):
Ok, so that mean Centos is just a sand box and they should indicate in the web site: "Warning, This projet is just for fun, do not use for production" ???? You cannot, in a side be "an Enterprise-class Linux Distribution" (see http://www.centos.org/) and in the other side said "take source and build your own"; It's important to be coherent .... So if Centos cannot be reactive about security update ... remove the "Enterprise-class" from the web site and be clear about that.
Regards,
js.
Le 17/02/2011 18:20, dsieme01@yahoo.com a écrit :
You are free to take source and build your own package or buy redhat,
oracle or other. Beating up Volunteers will not serve the community.
We owe the community for their work, not the other way around.
Sent from my BlackBerry® smartphone, powered by Cricket.
-----Original Message----- From: Larry Vaden vaden@texoma.net Sender: centos-devel-bounces@centos.org Date: Thu, 17 Feb 2011 08:13:35 To: The CentOS developers mailing list.centos-devel@centos.org Reply-To: "The CentOS developers mailing list." <
centos-devel@centos.org>
Subject: Re: [CentOS-devel] progress?
On Thu, Feb 17, 2011 at 6:26 AM, Dag Wieers dag@wieers.com wrote:
I, for one, do not think it is normal existing user's security is 2 or
3
months at stake.
+1
regards/ldv/vaden@texoma.net _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFNXTHpu8lcDdFEGbYRAkOJAJ9KqWIdNp2ohDG7MKfHC88iXacBEgCfZhsr qUIfqWDx5PYNv3EA4YkTDMk= =3Fk8 -----END PGP SIGNATURE-----
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Taimur Gibran Rabuske Kuntz Researcher at Analog and Mixed-Signal Circuits Research Unit INESC-ID - Instituto de Engenharia de Sistemas e Computadores - Investigação e Desenvolvimento Lisbon - Portugal
GPG keyID: D4D0FEB8 @ pgp.mit.edu
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 02/17/2011 08:34 AM, jean-seb wrote:
Hello,
theses words are just stupid (sorry, but I'm bored to read stuff like that "if you're unhappy, buy RH and Shut up"):
Ok, so that mean Centos is just a sand box and they should indicate in the web site: "Warning, This projet is just for fun, do not use for production" ???? You cannot, in a side be "an Enterprise-class Linux Distribution" (see http://www.centos.org/) and in the other side said "take source and build your own"; It's important to be coherent .... So if Centos cannot be reactive about security update ... remove the "Enterprise-class" from the web site and be clear about that.
Look ... use CentOS or don't.
Help us test it or don't.
Build your own or don't.
If you don't like it .. don't use it.
On Fri, Feb 18, 2011 at 09:39:56AM -0600, Johnny Hughes wrote:
If you don't like it .. don't use it.
+1
You've been missed, Johnny.
John
Le 18/02/11 19:39, Johnny Hughes a écrit :
On 02/17/2011 08:34 AM, jean-seb wrote:
Hello,
theses words are just stupid (sorry, but I'm bored to read stuff like that "if you're unhappy, buy RH and Shut up"):
Ok, so that mean Centos is just a sand box and they should indicate in the web site: "Warning, This projet is just for fun, do not use for production" ???? You cannot, in a side be "an Enterprise-class Linux Distribution" (see http://www.centos.org/) and in the other side said "take source and build your own"; It's important to be coherent .... So if Centos cannot be reactive about security update ... remove the "Enterprise-class" from the web site and be clear about that.
Look ... use CentOS or don't.
Help us test it or don't.
Build your own or don't.
If you don't like it .. don't use it.
Hello,
Hello,
You don't understand, I think, the meaning of my email: When someone said "Ok, buy a RH license" to end a discussion and don't talk about problems is just not a good approch. My mail is not (to be clear) against Centos, but against those who use the "do it yourself" just to shutdown all argument :)
Regards
js.
On Fri, 18 Feb 2011, js wrote:
Le 18/02/11 19:39, Johnny Hughes a écrit :
On 02/17/2011 08:34 AM, jean-seb wrote:
theses words are just stupid (sorry, but I'm bored to read stuff like that "if you're unhappy, buy RH and Shut up"):
Ok, so that mean Centos is just a sand box and they should indicate in the web site: "Warning, This projet is just for fun, do not use for production" ???? You cannot, in a side be "an Enterprise-class Linux Distribution" (see http://www.centos.org/) and in the other side said "take source and build your own"; It's important to be coherent .... So if Centos cannot be reactive about security update ... remove the "Enterprise-class" from the web site and be clear about that.
Look ... use CentOS or don't.
Help us test it or don't.
Build your own or don't.
If you don't like it .. don't use it.
You don't understand, I think, the meaning of my email: When someone said "Ok, buy a RH license" to end a discussion and don't talk about problems is just not a good approch. My mail is not (to be clear) against Centos, but against those who use the "do it yourself" just to shutdown all argument :)
Mine too. The same things have been discussd for the past 4 years, and the same arguments have been used. And in 2011 it still takes months to release a new (minor !) release.
More than 2 months have passed since the release of RHEL5.6. Everyone running CentOS 5 did not have security updates for 71 (!) days and counting...
Considering that releases are 6 months apart, 2 months without security updates means CentOS 5 users have no security updates 33% of the time. (Luckily some releases shipped less than 2 months after RHEL !)
Calling me a baby is probably the easiest approach to the problem.
PS Looking back, CentOS 5.3 took 2 months, and CentOS 4.8 even took 3 months to be released. CentOS 6.0 is a new time low with a delay of more than 3 months, but without harming its userbase ;-)
On 2/18/2011 10:17 AM, Dag Wieers wrote:
Mine too. The same things have been discussd for the past 4 years, and the same arguments have been used. And in 2011 it still takes months to release a new (minor !) release.
More than 2 months have passed since the release of RHEL5.6. Everyone running CentOS 5 did not have security updates for 71 (!) days and counting...
Considering that releases are 6 months apart, 2 months without security updates means CentOS 5 users have no security updates 33% of the time. (Luckily some releases shipped less than 2 months after RHEL !)
Calling me a baby is probably the easiest approach to the problem.
PS Looking back, CentOS 5.3 took 2 months, and CentOS 4.8 even took 3 months to be released. CentOS 6.0 is a new time low with a delay of more than 3 months, but without harming its userbase ;-)
Nobody should take this as criticism of the CentOS team, I appreciate what they do; but I am curious:
What would it take to enhance the system to a point that the maximum delta between upstream release and CentOS release would be, for example, no more than three weeks?
Is it a compute power issue? Is it a manpower issue? Is it a work flow efficiency issue?
I think it's obvious from the reactions of the community at this point, that the majority of uses are not satisfied with the delta between upstream release and CentOS release - just look at this thread for proof, or go search the forum for "centos6".
Again, please don't read this as criticism. It's a simple question of "how can it be improved?"
--- - Nick Bright Network Administrator Valnet Tel 888-332-1616 x 315 Fax 620-331-0789
js wrote:
If you don't like it .. don't use it.
Hello,
Hello,
You don't understand, I think, the meaning of my email: When someone said "Ok, buy a RH license" to end a discussion and don't talk about problems is just not a good approch.
What problems? CentOS is/will be only 3-4 weeks behind Oracle Unbreakable Linux, and 0-2 weeks behind Scientific Linux, in both cases with PAID developers. So about WHAT problems are you talking about?
My mail is not (to be clear) against Centos, but against those who use the "do it yourself" just to shutdown all argument :)
We understand it EXTREMELY well. First of all, just to be clear, I have not contributed to the CentOS project in any measurable way. I did create public repo for CentOS desktop apps and I did create/recompiled 40-50 packages for CentOS in last few years, but no one ever contacted me about it, and MAYBE 2-3 developers ever browsed it.
Having that in mind, I claim that if you do not like how this (or any other open source project) is managed, it's speed of releases or any other aspect, you have 3 options: 1. Contribute your time and knowledge to that project. 2. Create a fork of the project and contribute your time and knowledge to that project. 3. After negative response to initial question(s) about things becoming better use it but do not complain any more.
You can hold someone responsible for not making your life better only in the degree of how much you (or someone else in your name) paid him. If he is not paid for it, you have NO MORAL RIGHT to complaint to him (after initial complaint).
Ljubomir
On 2/18/11 9:32 AM, Ljubomir Ljubojevic wrote:
- Contribute your time and knowledge to that project.
I get the impression that there are a lot of people that would like to do so, but don't know how. I think that's partly what Dag is complaining about as well.
Steve
On 2/18/2011 10:36 AM, Steve Meyers wrote:
On 2/18/11 9:32 AM, Ljubomir Ljubojevic wrote:
- Contribute your time and knowledge to that project.
I get the impression that there are a lot of people that would like to do so, but don't know how. I think that's partly what Dag is complaining about as well.
Steve
That is my observation as well.
- Nick
On Friday, February 18, 2011 11:36:18 am Steve Meyers wrote:
On 2/18/11 9:32 AM, Ljubomir Ljubojevic wrote:
- Contribute your time and knowledge to that project.
I get the impression that there are a lot of people that would like to do so, but don't know how. I think that's partly what Dag is complaining about as well.
There is a tab on the centos wiki (wiki.centos.org) that says Contribute. This links to http://wiki.centos.org/Contribute and describes the useful beginning contributions.
On the subject of useful contributions, I for one don't want some J Random Hacker building packages for direct distribution on CentOS. There must be a vetting process.
The Fedora process works for Fedora; CentOS is a smaller project, and it seems to me that if you want the trust from the stewards of The Keys you have to earn it; no entitlements here (pun intended). Someone cannot earn that trust when that someone repeatedly insults or annoys the project leads; ain't gonna happen.
Red Hat certainly isn't going to allow a random person to create a direct package for RHEL. From appearances, neither would Fermi for SL; they have Troy and Connie who do an outstanding job; but realize that it is really a part of their $dayjob to do that job, and also realize that their needs and goals are different. And so their process is different.
Even when I was building RPMs for PostgreSQL, and Red Hat was using my work in Red Hat Linux, there was a Red Hat employee who checked and rebuilt the packages that went into Red Hat Linux (and later into Enterprise Linux). That Red Hat employee and I got to know each other rather well. So I'd release the packages I built via PostgreSQL.org, and Red Hat would release theirs, that their packager had vetted/built through their channels. Red Hat is still shipping packages, for EL4 and 3, that I had a hand in getting off the ground, and unless they've trimmed the changelog you'll find me there.
How did I get started in that, and get to that point? I jumped in with both feet and started building packages, initially distributed them through my own server, and gradually earned the trust both of the PostgreSQL project and then Red Hat. There was no formal process, and there were no formalities. I just dug in and did the work. I am not going to say that everything was smooth sailing, because I was quite a bit more 'prickly' in personality eleven years ago. But I hung in there, and didn't clash too badly with folk. I applied SSology. (SS is short for a certain trademark of the company formerly known as the Children's Television Workshop).
I've seen repeated calls for specific help with the CentOS project lately, and that's more transparent than it has been, and I applaud that.
But, on a more personal note, I do wish that Dag and the CentOS group hadn't had their falling out, as Dag's repository is the primary third-party repository for many CentOS users. But, reasonable and talented folk can have unreasonable fallouts (the more highly talented, it seems, the more passionate the falling out), and as much as I respect Dag, and as much as I respect the members of the CentOS team, this falling out remains in my mind as one of the blackest of spots on CentOS. The falling out has echoed on the CentOS lists in the last couple of days; guys, please get ahold of yourselves, and if you're kidding around please drop a smiley in to show that..... or at least take it private. Please, for the sake of the projects' reps?
On Fri, Feb 18, 2011 at 11:09 AM, Lamar Owen lowen@pari.edu wrote:
The falling out has echoed on the CentOS lists in the last couple of days; guys, please get ahold of yourselves, and if you're kidding around please drop a smiley in to show that..... or at least take it private. Please, for the sake of the projects' reps?
1. Au contraire, transparency is a good thing; folks in the community need to be aware of the risks they are taking, whether using (Windows|RH|CentOS|SL|Ubuntu|et al).
2. s/project's reps/CentOS community/g
On Friday, February 18, 2011 12:20:43 pm Larry Vaden wrote:
On Fri, Feb 18, 2011 at 11:09 AM, Lamar Owen lowen@pari.edu wrote: Please, for the sake of the projects' reps?
- s/project's reps/CentOS community/g
No, I said what I meant; I just abbreviated it. The projects' (plural possessive) reps (as in reputations). Sorry for the confusion; it's just second nature for me to abbreviate 'reputation' as 'rep' (and it is an accepted practice in many circles); unfortunately the degree of ambiguity is directly proportional to the degree of abbreviation.
On Fri, 18 Feb 2011, Lamar Owen wrote:
On Friday, February 18, 2011 11:36:18 am Steve Meyers wrote:
On 2/18/11 9:32 AM, Ljubomir Ljubojevic wrote:
- Contribute your time and knowledge to that project.
I get the impression that there are a lot of people that would like to do so, but don't know how. I think that's partly what Dag is complaining about as well.
There is a tab on the centos wiki (wiki.centos.org) that says Contribute. This links to http://wiki.centos.org/Contribute and describes the useful beginning contributions.
On the subject of useful contributions, I for one don't want some J Random Hacker building packages for direct distribution on CentOS. There must be a vetting process.
Oh the irony. I started that wiki page !
But if you look closely, you will notice that none of what is listed there really benefits the CentOS release process. The very heart of what CentOS does is a guarded bastion with only a few people involved. A few more people get QA access, but we wouldn't want too much testing, would we ?
So the process doesn't scale, and everyone waiting for the next release or security update feels powerless to help there where it could be useful because the tools, the process and the changes are hidden.
This means that even though I am not even interested to have access to the keys or to push a package, one cannot help with tool development to automate the process better (think binary-compatibility testing) or with build-problems (there are no build problems!) or with help finding trademark problems. Or with many other things that are currently lacking, but would fit the CentOS project (eg. rebuilding the various channel packages, fastrack, ...)
But you are right, I should probably stop sending cynical messages. I simply do care about the project. I had a hard time keeping quiet for more than a year, but here we are in the same situation we were in 2009 and 2010 and we haven't learned a thing :-/
We could be doing a better job, but we aren't...
On 2/18/11 10:46 AM, Dag Wieers wrote:
So the process doesn't scale, and everyone waiting for the next release or security update feels powerless to help there where it could be useful because the tools, the process and the changes are hidden.
I would like it if I had access to make my own build environment that is the same as what CentOS uses, so I could get to know the process they use better. Then I would be able to start off by contributing patches and such. I don't have anywhere near the experience of Dag, but I've done a lot of RPM building in my previous jobs.
Being able to replicate the process would help new people to get involved.
Steve
On Fri, Feb 18, 2011 at 11:50 AM, Steve Meyers steve-centos@spamwiz.com wrote:
I would like it if I had access to make my own build environment that is the same as what CentOS uses, so I could get to know the process they use better. Then I would be able to start off by contributing patches and such. I don't have anywhere near the experience of Dag, but I've done a lot of RPM building in my previous jobs.
Being able to replicate the process would help new people to get involved.
+1
Perhaps Dag or some team member could document the build environment on the wiki so that the CentOS project is saying "if you want to roll your own because of our schedule, here's how we do it." rather than "GO ROLL YOUR OWN."
regards/ldv/vaden@texoma.net
On 02/18/2011 06:50 PM, Steve Meyers wrote:
On 2/18/11 10:46 AM, Dag Wieers wrote:
So the process doesn't scale, and everyone waiting for the next release or security update feels powerless to help there where it could be useful because the tools, the process and the changes are hidden.
I would like it if I had access to make my own build environment that is the same as what CentOS uses, so I could get to know the process they use better. Then I would be able to start off by contributing patches and such. I don't have anywhere near the experience of Dag, but I've done a lot of RPM building in my previous jobs.
Being able to replicate the process would help new people to get involved.
It has been said several times (but that would be useful to have it described on the wiki though , and everybody agrees on that fact ...) that the tools are the ones used by Fedora : Plague : http://fedoraproject.org/wiki/Projects/Plague Mock : http://fedoraproject.org/wiki/Projects/Mock
Fabian Arrotin
Le 18/02/2011 22:19, Fabian Arrotin a écrit :
On 02/18/2011 06:50 PM, Steve Meyers wrote:
On 2/18/11 10:46 AM, Dag Wieers wrote:
So the process doesn't scale, and everyone waiting for the next release or security update feels powerless to help there where it could be useful because the tools, the process and the changes are hidden.
I would like it if I had access to make my own build environment that is the same as what CentOS uses, so I could get to know the process they use better. Then I would be able to start off by contributing patches and such. I don't have anywhere near the experience of Dag, but I've done a lot of RPM building in my previous jobs.
Being able to replicate the process would help new people to get involved.
It has been said several times (but that would be useful to have it described on the wiki though , and everybody agrees on that fact ...) that the tools are the ones used by Fedora : Plague : http://fedoraproject.org/wiki/Projects/Plague Mock : http://fedoraproject.org/wiki/Projects/Mock
Fabian Arrotin
Hello,
Send links like this is like this situation: "Do you want to rebuild Libreoffice?" gcc: gcc.gnu.org/
So yes, a precise "how to build your own" will be very useful ;-)
Regards,
js.
On Fri, Feb 18, 2011 at 11:46 AM, Dag Wieers dag@wieers.com wrote:
We could be doing a better job, but we aren't...
The theme of the 1963 National Science Fair was Browning's "“Ah, but a man's reach should exceed his grasp, or what's a heaven for?”
regards/ldv/vaden@texoma.net
On 02/18/2011 06:46 PM, Dag Wieers wrote:
<big snip>
or with help finding trademark problems. Or with many other things that are currently lacking, but would fit the CentOS project (eg. rebuilding the various channel packages, fastrack, ...)
That's an interesting case : the Trademark issues. Look at the call for contributions on that specific point. A *lot* of people always complained about what can/could be done to push the centos wheel a little bit further and have faster releases. This time a specific call was sent for people wanting to contribute (on the centos-devel list and also on IRC *each* time that someone asked about 'how to contribute'). [1] Guess how much people really helped ? We can count on the fingers of *one* hand the people who really chased after branding issues for CentOS 6. I let you count how much people have discussed in this 'progress' thread, but haven't participated in the effort and do some simple maths ... That's quite 'interesting' to see that almost all people wanting to contribute just want to know the bits and bytes of the buildsystems (which aren't "hidden" because only using plague and mock), but nobody really wants to do something when pointed to something specific that doesn't seem 'geek oriented' at first sight ... :(
Just my two cents ...
Fabian Arrotin
[1] http://lists.centos.org/pipermail/centos-devel/2010-November/006018.html
On Friday, February 18, 2011 12:46:06 pm Dag Wieers wrote:
On Fri, 18 Feb 2011, Lamar Owen wrote:
There is a tab on the centos wiki (wiki.centos.org) that says Contribute. This links to http://wiki.centos.org/Contribute and describes the useful beginning contributions.
Oh the irony. I started that wiki page !
I know.
But if you look closely, you will notice that none of what is listed there really benefits the CentOS release process.
Perhaps not directly.
A few more people get QA access, but we wouldn't want too much testing, would we ?
It depends upon who 'we' is and what step in the process is being tested. (Yeah, who 'we' is; quoted plural pronoun is still singular in this usage.....)
So the process doesn't scale, and everyone waiting for the next release or security update feels powerless to help there where it could be useful because the tools, the process and the changes are hidden.
This is the real crux of the matter. It really depends upon how anxious one is to get the Latest Update and how important that update may or may not be. 'I want CentOS 5 for my SGI Altix 3000! Now would be good!' 'Oh, but it will be six months before it's powered up.....' (I have an SGI Altix 3000, and I do want C5 for IA64, but I put quotes around that since I'm kidding) And it also depends upon how one treats volunteers and free software projects; it is clear that some feel entitled to it, for free, and make that yesterday, and do it my way, chop chop!
That attitude is part of the reason I handed over the PostgreSQL RPMs back in 2004. While several people were genuinely helpful (and I chose one of them to be my 'successor' maintainer), the majority were either bound and determined to show me how wrong I was in the way I was doing it, or they started nagging me the instant the tarball was on the server and complained if the RPMs were even ten minutes later (and the whole idea that it takes time to build a package, much less to make all the patches and changes necessary, was completely alien to them; they wanted it, and thus they deserved it, by George!). And then complained if anything broke, even when they willingly ignored clear instructions.... Dag, you are no stranger to that, I know, as you've maintained your repository longer than I maintained my small set. And you do a fantastic job doing what you do.
But you are right, I should probably stop sending cynical messages.
Cynicism has its uses, for sure. Subtle humor in cynicism is lost when other non-humorous cynics abound.
I simply do care about the project. I had a hard time keeping quiet for more than a year, but here we are in the same situation we were in 2009 and 2010 and we haven't learned a thing :-/
We could be doing a better job, but we aren't...
'We' is a good word choice.
Thanks for all the hard work in maintaining EL sections in your repository, and the work with RPMforge as a whole; I certainly appreciate it.
Am 18.02.2011 um 17:36 schrieb Steve Meyers:
On 2/18/11 9:32 AM, Ljubomir Ljubojevic wrote:
- Contribute your time and knowledge to that project.
I get the impression that there are a lot of people that would like to do so, but don't know how. I think that's partly what Dag is complaining about as well.
I wonder why these perception comes up: Anyone starts small and for that go and start here e.g. :
http://wiki.centos.org/Contribute http://wiki.centos.org/FAQ/General
http://bugs.centos.org/ http://thread.gmane.org/gmane.linux.centos.devel/6903/
also good:
http://fedoraproject.org/wiki/PackagingGuidelines
and again, helping means an active action in diving in existing structures (processes) and if needed changing it from inside.
Regards
PM
Le 18/02/11 20:32, Ljubomir Ljubojevic a écrit :
js wrote:
If you don't like it .. don't use it.
Hello,
You don't understand, I think, the meaning of my email: When someone said "Ok, buy a RH license" to end a discussion and don't talk about problems is just not a good approch.
What problems? CentOS is/will be only 3-4 weeks behind Oracle Unbreakable Linux, and 0-2 weeks behind Scientific Linux, in both cases with PAID developers. So about WHAT problems are you talking about?
See previous emails please.
My mail is not (to be clear) against Centos, but against those who use the "do it yourself" just to shutdown all argument :)
We understand it EXTREMELY well. First of all, just to be clear, I have not contributed to the CentOS project in any measurable way. I did create public repo for CentOS desktop apps and I did create/recompiled 40-50 packages for CentOS in last few years, but no one ever contacted me about it, and MAYBE 2-3 developers ever browsed it.
Having that in mind, I claim that if you do not like how this (or any other open source project) is managed, it's speed of releases or any other aspect, you have 3 options:
- Contribute your time and knowledge to that project.
If it's open
- Create a fork of the project and contribute your time and knowledge
to that project.
Seems to be on the way
- After negative response to initial question(s) about things becoming
better use it but do not complain any more.
You can hold someone responsible for not making your life better only in the degree of how much you (or someone else in your name) paid him. If he is not paid for it, you have NO MORAL RIGHT to complaint to him (after initial complaint).
Ljubomir
excellent proof of ignorance about the functioning of free software in general
I'm stopping before godwin point :)
On Fri, 18 Feb 2011, Ljubomir Ljubojevic wrote:
js wrote:
If you don't like it .. don't use it.
You don't understand, I think, the meaning of my email: When someone said "Ok, buy a RH license" to end a discussion and don't talk about problems is just not a good approch.
What problems? CentOS is/will be only 3-4 weeks behind Oracle Unbreakable Linux, and 0-2 weeks behind Scientific Linux, in both cases with PAID developers. So about WHAT problems are you talking about?
My mail is not (to be clear) against Centos, but against those who use the "do it yourself" just to shutdown all argument :)
We understand it EXTREMELY well. First of all, just to be clear, I have not contributed to the CentOS project in any measurable way. I did create public repo for CentOS desktop apps and I did create/recompiled 40-50 packages for CentOS in last few years, but no one ever contacted me about it, and MAYBE 2-3 developers ever browsed it.
Having that in mind, I claim that if you do not like how this (or any other open source project) is managed, it's speed of releases or any other aspect, you have 3 options:
- Contribute your time and knowledge to that project.
- Create a fork of the project and contribute your time and knowledge
to that project. 3. After negative response to initial question(s) about things becoming better use it but do not complain any more.
You can hold someone responsible for not making your life better only in the degree of how much you (or someone else in your name) paid him. If he is not paid for it, you have NO MORAL RIGHT to complaint to him (after initial complaint).
You prove my point quite elegantly. I did spend a lot of time promoting CentOS and helped where I was allowed to help, I tried to get people involved in CentOS, did presentations, helped with the wiki, and genuinly tried to solve problems within the project. But things get blocked at the same level, so if you cannot get anything to move from within the project after 4 years, because things always block at the same level and nobody is prepared to fix that, there's nothing really left.
And from the people involved, I am not the only one who does complain, there are people in the CentOS team that have the same complaints (but prefer to stay in the team nevertheless), there are volunteers outside of the team with exactly the same objections who feel disappointed, but still contribute. I have a lot of respect for these people even though you should be able to discuss what's going wrong.
Hence my cynical reply.
If the project doesn't want to change, that's fine, but then don't try to find excuses or attack the messenger. Simply state those goals clearly.
On Thu, Feb 17, 2011 at 12:20 AM, Karanbir Singh mail-lists@karan.org wrote:
Have you ever considered the idea that the centos developer community ( as opposed to the centos community at large ) are all people who have @redhat.com email address's ?
Dag,
Since, IIRC, this was written to you and I've had 2 Internet2 types and one FedEx type (yes, the Big Purple Shipper uses RH _and_ VMware) parse the hell out of it without meaningful result, what did you take it to mean?
Is there significance to "idea" vs. "fact"?
IOW, if SRPMs are missing, how is the remark related to the situation at hand?
kind regards/ldv/vaden@texoma.net
-
. -
Akemi Yagi -
Alan Bartlett -
Andreas Kasenides -
Andy Grimm -
Antaryami Khuda -
Bill McGonigle -
Blake Dunlap -
Dag Wieers -
David Brian Chait -
dsieme01＠yahoo.com -
Fabian Arrotin -
Florian La Roche -
Garry Dale -
Guenther Boelter -
jean-seb -
jean-sebastien Hubert
-
Jeff Johnson -
Jerry Amundson -
John R. Dennison -
Johnny Hughes -
js
-
Karanbir Singh -
Lamar Owen -
Larry Vaden -
Leonard den Ottolander -
Les Mikesell -
Ljubomir Ljubojevic -
lostson -
Manuel Wolfshant -
Matthew Miller -
Morten P.D. Stevens -
Nick Bright -
Nico Kadel-Garcia -
Paulo Martinez -
Philippe Laurent -
R P Herrold -
Ralph Angenendt -
RedShift -
Stephen John Smoogen -
Steve Meyers -
Taimur Gibran -
Thomas Bendler -
William L. Sebok