Am 19.02.2011 um 12:49 schrieb js:

Le 19/02/11 15:42, Johnny Hughes a écrit :

...

On 02/18/2011 04:58 PM, Johnny Hughes wrote:

...

Can I get a couple of you guys to verify my SRPM list?

Note: The Red Hat FTP site is all updates since the release of RHEL 4.0. The CentOS 4.8 SRPMS are the ones on the 4.8 ISOs and the updates are those SRPMS updated since the release of 4.8. We are only interested in the newest SRPMS for each app.

I hear crickets ... where are all the community people who want to help?

Ok, so "Help" for you is to check if your rpm list is correct?

It's better to say "close the light when I leave my office, thanks".

Sorry, but what do imagine? Getting started as a big manager?

Give assistance, get trust and take then your own part managed by you. :-)

I think it is import to see the transition! and focusing that to get included and (again) if needed change things by transit it.

Bests

PM

Le 19/02/11 17:23, Johnny Hughes a écrit :

On 02/19/2011 05:49 AM, js wrote:

...

Le 19/02/11 15:42, Johnny Hughes a écrit :

...

On 02/18/2011 04:58 PM, Johnny Hughes wrote:

...

It seems Red Hat is not releasing media for the 4.9 release, so this seems to be just a bunch of updates that is going into the tree. Based on the SRPMS listed here:

ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/

And the current CentOS 4.8+updates SRPMS here:

http://mirror.centos.org/centos-4/4.8/os/SRPMS/

http://mirror.centos.org/centos-4/4.8/updates/SRPMS/

This is the list of SRPMS I have started building:

autofs-4.1.3-240.src.rpm autofs5-5.0.1-0.rc2.114.src.rpm bash-3.0-27.el4.src.rpm bind-9.2.4-37.el4.src.rpm centos-release-4-9.src.rpm comps-4AS-0.20110202.src.rpm coreutils-5.2.1-37.el4.src.rpm device-mapper-1.02.28-3.el4.src.rpm device-mapper-multipath-0.4.5-42.el4.src.rpm glibc-2.3.4-2.54.src.rpm gnome-volume-manager-1.1.0-9.src.rpm hal-0.4.2-9.el4_8.src.rpm httpd-2.0.52-47.ent.centos4.src.rpm hwdata-0.146.33.EL-19.src.rpm iscsi-initiator-utils-4.0.3.0-10.src.rpm kernel-2.6.9-100.EL.src.rpm kernel-utils-2.4-23.el4.src.rpm lvm2-2.02.42-9.el4.src.rpm net-snmp-5.1.2-20.el4.src.rpm nfs-utils-1.0.6-94.EL4.src.rpm nss_ldap-253-16.el4.src.rpm numactl-0.6.4-1.44.src.rpm procps-3.2.3-8.21.src.rpm python-2.3.4-14.9.el4.src.rpm quota-3.12-9.el4.src.rpm redhat-release-4AS-10.src.rpm rhnlib-2.1.4-17.el4_8.1.src.rpm rhpl-0.148.6-2.src.rpm rpmdb-redhat-4-0.20110202.src.rpm samba-3.0.33-0.29.el4.src.rpm sendmail-8.13.1-6.el4.src.rpm sysklogd-1.4.1-30.el4.src.rpm sysstat-5.0.5-27.el4.src.rpm system-config-lvm-1.1.4-4.el4.src.rpm system-config-network-1.3.22.0.EL.4.6-4.el4.src.rpm systemtap-1.3-5.el4.src.rpm tmpwatch-2.9.1-1.el4.2.src.rpm udev-039-10.30.el4.src.rpm up2date-4.9.1-29.el4.centos.src.rpm util-linux-2.12a-28.el4.src.rpm xorg-x11-6.8.2-1.EL.66.src.rpm

If there is more than one SRPM of the same package, I only took the latest SRPM.

Can I get a couple of you guys to verify my SRPM list?

Note: The Red Hat FTP site is all updates since the release of RHEL 4.0. The CentOS 4.8 SRPMS are the ones on the 4.8 ISOs and the updates are those SRPMS updated since the release of 4.8. We are only interested in the newest SRPMS for each app.

Thanks, Johnny Hughes

I hear crickets ... where are all the community people who want to help?

Hello,

Ok, so "Help" for you is to check if your rpm list is correct?

It's better to say "close the light when I leave my office, thanks".

I hope it's a joke, really :-)

So you don't really want to help, you just want us to tell you how to build CentOS.

Hello, I know that "open" a project is not easy, it's time consuming yes. But it seems nobody here cares about a good way to work in team. You have a guru, and "the others".

Let me take a simple example:

Today I have servers, can free cpu to compile stuff, can test build iso process, can test installation, validity of rpms etc.. How, today, can I help? I don't want to sign packages, no .. only add a few time to help, no more, no less: There is no "security" risk to do so.

If you think the "centos community" is some guys who count the number of srpms in a ftp server; ok, we can close the discussion; talk to a wall is a waste of time.

I hope you will understand my thinking: I know the work you do, and I'm glad to use it, but it does not solve this particular problem.

Regards,

js.

On 02/19/2011 07:40 AM, js wrote:

Le 19/02/11 17:23, Johnny Hughes a écrit :

...

On 02/19/2011 05:49 AM, js wrote:

...

Le 19/02/11 15:42, Johnny Hughes a écrit :

...

On 02/18/2011 04:58 PM, Johnny Hughes wrote:

...

It seems Red Hat is not releasing media for the 4.9 release, so this seems to be just a bunch of updates that is going into the tree. Based on the SRPMS listed here:

ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/

And the current CentOS 4.8+updates SRPMS here:

http://mirror.centos.org/centos-4/4.8/os/SRPMS/

http://mirror.centos.org/centos-4/4.8/updates/SRPMS/

This is the list of SRPMS I have started building:

autofs-4.1.3-240.src.rpm autofs5-5.0.1-0.rc2.114.src.rpm bash-3.0-27.el4.src.rpm bind-9.2.4-37.el4.src.rpm centos-release-4-9.src.rpm comps-4AS-0.20110202.src.rpm coreutils-5.2.1-37.el4.src.rpm device-mapper-1.02.28-3.el4.src.rpm device-mapper-multipath-0.4.5-42.el4.src.rpm glibc-2.3.4-2.54.src.rpm gnome-volume-manager-1.1.0-9.src.rpm hal-0.4.2-9.el4_8.src.rpm httpd-2.0.52-47.ent.centos4.src.rpm hwdata-0.146.33.EL-19.src.rpm iscsi-initiator-utils-4.0.3.0-10.src.rpm kernel-2.6.9-100.EL.src.rpm kernel-utils-2.4-23.el4.src.rpm lvm2-2.02.42-9.el4.src.rpm net-snmp-5.1.2-20.el4.src.rpm nfs-utils-1.0.6-94.EL4.src.rpm nss_ldap-253-16.el4.src.rpm numactl-0.6.4-1.44.src.rpm procps-3.2.3-8.21.src.rpm python-2.3.4-14.9.el4.src.rpm quota-3.12-9.el4.src.rpm redhat-release-4AS-10.src.rpm rhnlib-2.1.4-17.el4_8.1.src.rpm rhpl-0.148.6-2.src.rpm rpmdb-redhat-4-0.20110202.src.rpm samba-3.0.33-0.29.el4.src.rpm sendmail-8.13.1-6.el4.src.rpm sysklogd-1.4.1-30.el4.src.rpm sysstat-5.0.5-27.el4.src.rpm system-config-lvm-1.1.4-4.el4.src.rpm system-config-network-1.3.22.0.EL.4.6-4.el4.src.rpm systemtap-1.3-5.el4.src.rpm tmpwatch-2.9.1-1.el4.2.src.rpm udev-039-10.30.el4.src.rpm up2date-4.9.1-29.el4.centos.src.rpm util-linux-2.12a-28.el4.src.rpm xorg-x11-6.8.2-1.EL.66.src.rpm

If there is more than one SRPM of the same package, I only took the latest SRPM.

Can I get a couple of you guys to verify my SRPM list?

Note: The Red Hat FTP site is all updates since the release of RHEL 4.0. The CentOS 4.8 SRPMS are the ones on the 4.8 ISOs and the updates are those SRPMS updated since the release of 4.8. We are only interested in the newest SRPMS for each app.

Thanks, Johnny Hughes

I hear crickets ... where are all the community people who want to help?

Hello,

Ok, so "Help" for you is to check if your rpm list is correct?

It's better to say "close the light when I leave my office, thanks".

I hope it's a joke, really :-)

So you don't really want to help, you just want us to tell you how to build CentOS.

Hello, I know that "open" a project is not easy, it's time consuming yes. But it seems nobody here cares about a good way to work in team. You have a guru, and "the others".

Let me take a simple example:

Today I have servers, can free cpu to compile stuff, can test build iso process, can test installation, validity of rpms etc.. How, today, can I help? I don't want to sign packages, no .. only add a few time to help, no more, no less: There is no "security" risk to do so.

If you think the "centos community" is some guys who count the number of srpms in a ftp server; ok, we can close the discussion; talk to a wall is a waste of time.

I hope you will understand my thinking: I know the work you do, and I'm glad to use it, but it does not solve this particular problem.

Have you ever even seen the fedora project (the absolute most open project in the world, BTW) all people to compile SRPMS on their computers for inclusion into the project.

Absolutely not ...

They would NEVER allow someone to compile binaries somewhere else and ask that they somehow be included in the distribution. That is just crazy talk.

If you are one of the chosen people who are allowed to actually submit packages to the official fedora build system, that is one thing ... there are a few of those people. Not everyone who wants to is allowed to be the lead for fedora packages. See if they will let you be the fedora lead for glibc or the kernel. And this is the most open project out there.

I have no idea what you know about building packages because I have never met you, how does it help me to know that you can (or can not) build the packages on a non-controlled environment (non controlled by me)?

We have build systems that we use, we have a controlled environment on those build systems. The are setup so that only specific people have access. Those machines and are owned by donors who expect us to control the access on the machines, etc.

If you want to test the binaries that we have built before release, that is what the QA team does. There are currently 25 people in that group. We might ask for more people to join that group.

But none of that happens until we fix the build issues that we have after we build and test the packages. Building them on a non centos.org machine is not an option. Just like would not allow you to build a fedora package on a non-fedora machine.

On Saturday, February 19, 2011 11:09:43 am js wrote:

If yes, when a member find the problem, he can upload the srpm with the patch and let you rebuild it on a "genuine" centos.org

I think you missed Johnny's earlier point: the SRPM should not need patching to build, and in fact except for those packages that have to be patched to remove trademarks the CentOS SRPMs aren't patched in order to build; the build system is patched.

In other words, a patched SRPM won't (and shouldn't!) be accepted; a pointer to what is needed to make a package build correctly might be. The goal is to put vanilla Red Hat SRPMS in and get CentOS binary RPMs out without patching the SRPM in any way, shape, or form (again, except for trademarks/artwork/branding). I took that as axiomatic until seeing Johnny's post this morning, and then the light came on that some people simply aren't understanding what I 'just knew' all along.

And at this point, I don't think any of the CentOS gurus (there are more than one) need a whole lot of help in the C6 buildsystem (I reserve the right to be wrong should a CentOS core dev say so), and the C5 and C4 buildsystems are in maintenance mode. For C6 it's a matter of churning through the build and tweaking the build scripts (or order, or buildhost package versions, or whatnot).

Johnny asked for some specific help with the updates for C4u9 (I really don't like the point version notation, since upstream doesn't use that; you can't go to Red Hat and order 'RHEL 4.9' for instance; you order RHEL4, and get update 9's packages through RHN). There is a case where some grunt work is needed that could genuinely help C4 get its updates faster, but I guess that's not 'glamorous' enough for people....

On 02/19/2011 07:02 PM, js wrote:

Le 19/02/11 20:46, Lamar Owen a écrit :

...

On Saturday, February 19, 2011 11:09:43 am js wrote:

...

If yes, when a member find the problem, he can upload the srpm with the patch and let you rebuild it on a "genuine" centos.org

I think you missed Johnny's earlier point: the SRPM should not need patching to build, and in fact except for those packages that have to be patched to remove trademarks the CentOS SRPMs aren't patched in order to build; the build system is patched.

Hello, I'm curious how you can patch the build system.

here is a hint: config_opts['chroot_setup_cmd'] = 'install buildsys-build' #config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build'

...

In other words, a patched SRPM won't (and shouldn't!) be accepted; a pointer to what is needed to make a package build correctly might be. The goal is to put vanilla Red Hat SRPMS in and get CentOS binary RPMs out without patching the SRPM in any way, shape, or form (again, except for trademarks/artwork/branding). I took that as axiomatic until seeing Johnny's post this morning, and then the light came on that some people simply aren't understanding what I 'just knew' all along.

I don't remember (I think it was for Centos4 I think), but Centos fix a bug that was present in RHEL4;

Indeed there existed a very faulty kernel. But the version patched by Johny never ended in the main centos repos, it was published outside of it . And it was meant as a temporary workaround to be used until RH came with the fixed rpm

On Sat, Feb 19, 2011 at 11:46 AM, Lamar Owen lowen@pari.edu wrote:

But, as a fnal note (typo/pun intended), please read what Troy has to say in http://listserv.fnal.gov/scripts/wa.exe?A2=ind1011&L=SCIENTIFIC-LINUX-DE...

http://distrowatch.com/?newsid=06527 covers SL 6 RC1 for those who might want to play with koji.

On 02/19/2011 11:02 AM, js wrote:

Le 19/02/11 20:46, Lamar Owen a écrit :

...

On Saturday, February 19, 2011 11:09:43 am js wrote:

...

If yes, when a member find the problem, he can upload the srpm with the patch and let you rebuild it on a "genuine" centos.org

I think you missed Johnny's earlier point: the SRPM should not need patching to build, and in fact except for those packages that have to be patched to remove trademarks the CentOS SRPMs aren't patched in order to build; the build system is patched.

Hello, I'm curious how you can patch the build system.

...

In other words, a patched SRPM won't (and shouldn't!) be accepted; a pointer to what is needed to make a package build correctly might be. The goal is to put vanilla Red Hat SRPMS in and get CentOS binary RPMs out without patching the SRPM in any way, shape, or form (again, except for trademarks/artwork/branding). I took that as axiomatic until seeing Johnny's post this morning, and then the light came on that some people simply aren't understanding what I 'just knew' all along.

I don't remember (I think it was for Centos4 I think), but Centos fix a bug that was present in RHEL4; So ... sometimes you have no choice; you need to add a patch and hope it will no have consequences.

...

And at this point, I don't think any of the CentOS gurus (there are more than one) need a whole lot of help in the C6 buildsystem (I reserve the right to be wrong should a CentOS core dev say so), and the C5 and C4 buildsystems are in maintenance mode. For C6 it's a matter of churning through the build and tweaking the build scripts (or order, or buildhost package versions, or whatnot).

Johnny asked for some specific help with the updates for C4u9 (I really don't like the point version notation, since upstream doesn't use that; you can't go to Red Hat and order 'RHEL 4.9' for instance; you order RHEL4, and get update 9's packages through RHN). There is a case where some grunt work is needed that could genuinely help C4 get its updates faster, but I guess that's not 'glamorous' enough for people....

That make sense, So Centos, because of that, need to be like it is today... because this is only a "perfect clone of RHEL" :-/

but it will be very useful to be able to reproduce the build env anyway; seems to be a recurrent request.

The build environment is a staged install of CentOS. And mock. Every buildroot is created with a command to mock.

Here is an example scripts that I use to build "staged" extra's stuff for CentOS5:

http://people.centos.org/hughesjr/buildsystem/

You will notice there is nothing particularly special about any of that.

It just uses a local file:\ dir in the config, there is a createrepo in the build script between packages if it builds successfully.

The cfg files are the mock configs, the other files are the build scripts (the generate script creates some "lock files" in a list directory so we can have more than one machine build against the same directory of SRPMS. It orders them in reverse date order (build oldest file first).

There is no magic here.

Once built ... we use the tmverifyrpms against it from here:

http://mirror.centos.org/centos-4/4/build/distro/

The RPM either passes or fails the link test, the files test, and the size test ... if it fails, we figure out why and fix it.

Not sure what else you are looking for.

On 02/19/2011 09:05 PM, JohnS wrote:

On Sat, 2011-02-19 at 12:14 -0600, Johnny Hughes wrote:

...

Not sure what else you are looking for.

Here's a start:

rpm -qa|grep rpm from the actual build machine.

the output of the above command is completely useless. yum install mock will take you to the exact situation that you need.

On 02/20/2011 12:13 AM, JohnS wrote:

On Sat, 2011-02-19 at 22:53 +0200, Manuel Wolfshant wrote:

...

On 02/19/2011 09:05 PM, JohnS wrote:

...

On Sat, 2011-02-19 at 12:14 -0600, Johnny Hughes wrote:

...

Not sure what else you are looking for.

Here's a start:

rpm -qa|grep rpm from the actual build machine.

the output of the above command is completely useless. yum install mock will take you to the exact situation that you need.

That is exactly what I call bs! I suppose will be useless when others try to replicate Johnies configs. God help them. The fact is what is true is very true, people want to Replicate the BUILDS. You do not have all the info you will never unless you hack it all out by your self. It is not sitting in a car and putting it in drive like some would want you to think. What the hell maby "lzma" will attach to a few peoples built binaries then they want install.

The packages installed on the "hosting" machine are completely irrelevant when the actual build is taking place in mock. If I were to show you the output of rpm -qa on my builder you would probably cry "murder" because I have NEVER used centos on that machine. I have used Fedora 7, Fedora 10, now it's a RHEL 6. And I have always used mock ( with different configs, of course ) to build for everything from RHEL 3 to RHEL6 and for Fedora since F7 to the current rawhide. So once again, I reiterate what I have said: the output of rpm -qa on the builder is completely irrelevant. Actually the whole config of the machine is irrelevant as long as mock can be used. Even more, Johnny Hughes has shown you the actual mock configs to be used for a start. What you probably want to learn is "how to add packages to mock's build root so as to satisfy the build requires when the spec file is incorrect and does not include all the BRs which are actually needed". And I have answered this very problem a couple of hours ago. OTOH, if you still have not understood what has been told and you still think that your request is legitimate, you need to take a step back and start by learning about mock. Even if you still think that we're bs*ing you.

On 02/19/2011 05:32 PM, JohnS wrote:

On Sun, 2011-02-20 at 00:55 +0200, Manuel Wolfshant wrote:

...

Even if you still think that we're bs*ing you.

Stop right there..... Wo is this "We Are" in This? Do you have a @centos.org address?

No, but he has a fedora one:

http://fedoraproject.org/wiki/User:Wolfy

On Sat, Feb 19, 2011 at 06:58:31PM -0500, JohnS wrote:

Noted..But does not mean a hill of beans to me

Of course it doesn't. However, to the rest of us it gives an indication that Manuel is an active contributor to the Fedora project, and brings with him the experience and knowledge of how to *properly* build packages. As such, listening to what the man has to say without your attitude being present might actually be a good thing for you to try sometime.

John

On 02/20/2011 01:32 AM, JohnS wrote:

On Sun, 2011-02-20 at 00:55 +0200, Manuel Wolfshant wrote:

...

Even if you still think that we're bs*ing you.

Stop right there..... Wo is this "We Are" in This? Do you have a @centos.org address?

No, I do not. But both Johnny and I are telling you the same thing. Since it makes two of us, the plural is correct. Unless English grammar has changed during the last 38 years since I've learnt that part.

Funny cause I never told you that. I simply asked the rpm version what the hell is wrong with that?

And it seems that you still did not understand that the versions of packages from the builder machine are irrelevant. BTW, what was the "grep rpm" from your command supposed to do ? If you just wanted the version of the rpm& friends, rpm -qa rpm* would have done it faster. And a polite " what version of rpm do you use on the builder ?" would have been a more clear question. Not that the answer to this question would have had any relevance either wrt the build process...

On Feb 19, 2011, at 3:00 PM, Johnny Hughes wrote:

If you can not figure out how to rebuild the OS after the things I just gave you, then you are an idiot. You are too stupid to be in this thread. Unplug your dang computer, put it back in the box and ship it back to where you bought it and give us a freaking break.

Wow.

I subscribed to this list last week because I was curious to know the status of the CentOS 6 release. My perception of the CentOS release process before joining this list was that it wasn't well described, status updates were not given, and it was somewhat slow and ad hoc. (What was up with the call for votes on 5.6 v. 6? And where were the results posted?) Perceptions can of course be wrong.

Every machine in our company runs CentOS from developer machines, to servers (DHCPd, Bind, Kerberos, etc.) to our cluster and AMIs except for a couple of Solaris and Windows servers. We use CentOS because it is the right price and meets our virtualization requirements unlike some of the other OSes did back when we made the decision to adopt CentOS uniformly. A lot of us miss having the bells and whistles found on Fedora or Ubuntu but it's something we must live with given our IT resources.

So after watching for a week or so--albeit during a tense time in the release cycle--I have some observations and recommendations: 1. Johnny Hughes, you would do CentOS well to mind your words. Or better yet, don't respond to threads asking about the process or release status. Instead, take half a day and write up a description of it. 2. The CentOS process is opaque and secretive. It may indeed be very complex with justifiable restrictions over who can contribute at what level, but the process should be described somewhere. This would also help impartial observers/users of CentOS understand why things take as long as they do. The process and team appear to be dysfunctional to the point that using CentOS may be a risk. 3. A lot of people are frustrated with the level and type of communication from the CentOS inner circle. Increasing the level of communication--including release status--and politeness would be good for CentOS.

A few days on this list was enough to give me a fresh interest in finding an alternative to CentOS.

With that I bid you all good luck and thanks for five year of CentOS.

Rich

On Sat, Feb 19, 2011 at 05:52:40PM -0600, Larry Vaden wrote:

On Sat, Feb 19, 2011 at 5:27 PM, Richard McClellan richmc@gmail.com wrote:

1. it appears that the howto build information has been available all along
2. incomplete/incorrect SRPMS from upstream present the problems
3. the rest is challenging on a case by case basis (figuring out

what's missing from the SRPM and putting said into the build root) 4) apparently even #3 is documented in bug reports to the upstream 5) all of this goes out the door and into the trash with RHEL 6

And 5.7, and 4.9 and every other point release and every single update that comes down the pike from upstream.

But for once I have to admit I agree with everything you've stated. Thanks for the refreshing post.

John

On 02/19/2011 03:58 PM, John R. Dennison wrote:

On Sat, Feb 19, 2011 at 03:27:56PM -0800, Richard McClellan wrote:

...

1. Johnny Hughes, you would do CentOS well to mind your words. Or

better yet, don't respond to threads asking about the process or release status. Instead, take half a day and write up a description of it.

He already went over the build process in more than enough detail to permit someone outside the project to do so.

I think Mr. McClellan was suggesting a bit more documentation on the website. Not everyone interested in CentOS is necessarily going to subscribe to this list. It was a reasonable suggestion in that context.

...

2. The CentOS process is opaque and secretive. It may indeed be very

complex with justifiable restrictions over who can contribute at what level, but the process should be described somewhere. This would also help impartial observers/users of CentOS understand why things take as long as they do. The process and team appear to be dysfunctional to the point that using CentOS may be a risk.

Secretive? Just today there have been postings with enough information to permit someone familiar with development processes in general to do their own build. Do you need something along the lines of "Step 1: Collect and download to a staging area the necessary source RPMs from upstream." hand-holding?

Again, easily-gotten docs on the subject (aside from a dev list) would be very helpful and maybe cut down on at least some of the dialog here in the last couple of days (some of it unnecessarily heated).

...

3. A lot of people are frustrated with the level and type of

communication from the CentOS inner circle. Increasing the level of communication--including release status--and politeness would be good for CentOS.

This is arguably true to some extent, but by no means a necessary occurrence.

As a new subscriber and potentially a new user doing research before implementation, I sincerely hope so.

...

A few days on this list was enough to give me a fresh interest in finding an alternative to CentOS.

I hear Redhat would be happy to sell you a set of support subscriptions. Of course, you would be required to pay for them.

That is a very condescending, specious, and frankly rude reply, and does nothing to further your argument. your work, or the recommendation of your distribution. In any case, I have no doubt that we would not get similar disdain from Redhat to what was a very civil customer comment.

...

With that I bid you all good luck and thanks for five year of CentOS.

Please don't let the door get scuffed on your way out :)

Smiley or not, that was very Eric Cartman of you. I can only hope that such unprofessionalism is not indicative of the quality of either CentOS itself, or of the mindset of its support staff-at-large.

I have to also question whether deciding to choose to use CentOS is going to come with serious future regrets.

Best Regards, DJA.

On Sat, 19 Feb 2011, Johnny Hughes wrote:

That reply was not from a developer of CentOS ...

When I last used 'CentOS developer', I was corrected by Karanbir that there are only Red Hat developers and the CentOS community. There was nothing in-between.

On Sat, Feb 19, 2011 at 04:44:54PM -0800, DJA wrote:

I think Mr. McClellan was suggesting a bit more documentation on the website. Not everyone interested in CentOS is necessarily going to subscribe to this list. It was a reasonable suggestion in that context.

And I maintain that it *is* documented, this isn't the first time that this discussion has been had, only the most recent; and it's now archived for posterity. There is a community wiki at http://wiki.centos.org; I doubt that there would be any issue with requesting access to document this if you, or anyone else, feel the need.

That is a very condescending, specious, and frankly rude reply, and does nothing to further your argument. your work, or the recommendation of your distribution. In any case, I have no doubt that we would not get similar disdain from Redhat to what was a very civil customer comment.

Not "my" work, nor "my" distribution. I am not a member of the CentOS development team, I have no more or less standing in the community than anyone else. And I'm not sure I care if you believe it to be condescending or not. I say what I mean and in this instance if you want an alternative to CentOS go to the source and get it from Redhat after you pay them for a support entitlement. There is no other EL alternative that bears mentioning; SL is not true EL, neither is OL. So your choices are somewhat limited. And as far as disdain? Tell you what, you go ask Redhat for a release schedule or documentation on their buildroots or build-order or frankly anything else and see where it gets you. I just don't get this whole documentation issue. Why should CentOS be held to different standards than Redhat?

Smiley or not, that was very Eric Cartman of you. I can only hope that such unprofessionalism is not indicative of the quality of either CentOS itself, or of the mindset of its support staff-at-large.

I don't care if he stays or goes. If he wants to go, then go. Same for anyone else. No one has a gun to anyone else's head forcing them to use the distribution. And if you liken my comments to the "support staff-at-large" you *really* need to reconsider. I don't speak for the project in any way, shape or form nor do I represent the support staff-at-large in any way; I speak for myself only.

I have to also question whether deciding to choose to use CentOS is going to come with serious future regrets.

That's a decision only you can make for yourself and/or your organization. However you may wish to weigh it against the fact that CentOS has been around for many years and has *millions* of installed systems around the world; it's not going anywhere anytime soon. And as much as you may believe otherwise, there are a large number of volunteers that freely offer their time to assist others on the mailing lists, IRC and the forums. The temperaments run the range from those as gruff as I am to those that are willing to hold your hand as you walk across the street and wipe your nose after you sneeze. I've been in support and managed support departments in the past and have been involved with many projects throughout the years and I can honestly say that the volunteers for CentOS are, by and large, some of the best around.

But at the end of the day that's all we are, volunteers. And I, for one, don't promise to make your world smell like roses. I will, however, do whatever I can to assist you with whatever problems you may be having. What's more important? Getting your issues resolved or having a warm fuzzy in the pit of your stomach? The .sig at the end of this mail is time-tested and true.

John

On Sat, 2011-02-19 at 17:00 -0600, Johnny Hughes wrote:

Please research mock:

http://fedoraproject.org/wiki/Projects/Mock

I do not need to maybe others do?

I am sick and tired of people who don't have a clue telling me that I don't know how to rebuild the OS or that I am not tell you something. I have told you EXACTLY how to build CentOS extras ... the only difference for OS would be to not include the extra's repo or the fasttrack repo.

Funny cause I never told you that. I simply asked the rpm version what the hell is wrong with that?

If you can not figure out how to rebuild the OS after the things I just gave you, then you are an idiot. You are too stupid to be in this thread. Unplug your dang computer, put it back in the box and ship it back to where you bought it and give us a freaking break.

I think you calling me an Idoit & Stupid will greatly reflect on your status. Shows how you really are and the way certain "CentOS Project Members Treat People. Maybe this should reside on Linux-Mag?

You do *NOT* know me from Adams House Cat. You wanna finish this I have a very personal Inbox.

John

On 02/19/2011 06:00 PM, Lamar Owen wrote:

On Saturday, February 19, 2011 05:13:05 pm JohnS wrote:

...

maby "lzma" will attach to a few peoples built binaries then they want install.

I'm assuming you meant "won't install" so taking that assumption....

Echoing what has been said; read up on mock, and see how to go about bootstrapping from a set of source RPM's.

Then, download the buildsys-build from dev.centos.org, and run something like: rpm -qilp --provides --requires buildsys-build-0.5-6.el5.centos.7.noarch.rpm

Study the requires output, and note carefully that the RPM has no files in it.

Now, imagine you have a seed set of the basic binaries available to you (I don't know, from the RHEL6 public beta ISO's, maybe), and also imagine that the new C6 buildsys-build rpm has a requires for rpmlib(PayloadIsXz) <= 5.2-1 (that requires is from F14, but close enough).

You do need a version of mock that can unpack the seed binary packages and the source RPM's, and by extension all the built packages in the source package's buildreqs. And that means xz for C6.

However, it is true that the version of mock (and by extension the version of rpmbuild) used on the buildhost can impact the built package; see Karanbir's post on his blog on the subject: http://www.karan.org/blog/index.php/2010/07/16/rpms-built-on-el6beta2-might-...

And the kernel running on the buildhost is still the kernel running the chroot, and if a kernel interaction to the build process happens, well, that is a side-effect.

In a perfect world the buildhost environment outside the mock-constructed buildroot would be side-effect free; but is this true in practice? Karanbir's example seems to indicate that side-effects can happen inside the buildroot based on the buildsystem host's packages.....

There is a lot to understand when setting up a buildhost that's churning from SRPMS, and it's useful to read up, and then try it out and see what happens when you feed it a list of packages.....

I certainly have learned a few things during these recent threads that I wasn't aware of previously.

And JohnS, before you ask who Lamar is (he also does not have a centos.org e-mail address) ... he was the maintainer of the PostGreSQL RPMs that were distributed in Red Hat Linux for quite a few years before he turned those over, so he has also rebuilt a few SRPMS in his time.

On Saturday, February 19, 2011 07:14:09 pm Johnny Hughes wrote:

On 02/19/2011 06:00 PM, Lamar Owen wrote:

...

I certainly have learned a few things during these recent threads that I wasn't aware of previously.

And JohnS, before you ask who Lamar is (he also does not have a centos.org e-mail address) ... he was the maintainer of the PostGreSQL RPMs that were distributed in Red Hat Linux for quite a few years before he turned those over, so he has also rebuilt a few SRPMS in his time.

And I would have been in rpm building heaven had mock been available back then.....I had to do things the hard way, on multiple hand-tuned buildhosts on multiple distributions. That sort of environment is why mach and mock came into being in the first place, as I recall.

See ftp://ftp-archives.postgresql.org/pub/binary/v7.0.3/RPMS/ for the melange I worked with early on.... I don't remember the LinuxPPC-2000 builds, for some reason.... but most of the later stuff is gone, thanks to the long backport history for 7.2.x, 7.3.x, and 7.4.x. But it is a nostalgia trip to re-read README.rpm-dist from 7.1.3....

Devrim has done well since then.

That means, of course, I bring baggage into the current situation that I have to unlearn.... :-)

On Sat, 2011-02-19 at 18:40 -0600, Johnny Hughes wrote:

Just for the record, we have several build machines. They are currently all CentOS-5 machines. At any point in time, the rpm version on our current build machines is whatever the latest version is in CentOS 5 as we run nightly updates on all our build servers against our CentOS tree.

At this exact point in time, that would mean that the version of RPM on our current build machines is 4.4.2.3-20.el5_5.1 ...

On the inside of the mock build roots, it will be the latest version of RPM for the version of centos that the build is being done for ... if building a centos-4 package, it would currently be 4.3.3-33_nonptl.el4_8.1, for centos 5 it would be the one listed above (4.4.2.3-20.el5_5.1) and for centos 3 it would be rpm-4.2.3-32_nonptl.

If we are building on a STAGED repo that contains a built RPM in the repo (like building for 5.6, for example) then the inside the mock buildroot would be the NEW version of RPM that is in 5.6.

Thanks, non of the other antics were needed. Question answered. Close the thread.

John

On Sat, Feb 19, 2011 at 5:42 AM, Johnny Hughes johnny@centos.org wrote:

I hear crickets ... where are all the community people who want to help?

Am working on it and will report back as soon as possible; what is your count?

On Sat, Feb 19, 2011 at 10:23 AM, Greg Bailey gbailey@lxpro.com wrote:

OK, this morning's programming project is a python script to automatically generate your list.  I get:

Congratulations!

Now that you are at the head of the class, may we see your python script?

On Tue, Feb 22, 2011 at 2:41 PM, Thomas Bendler ml@bendler-net.de wrote:

You never attend a team lead course, did you? A simple, please share your Python script is much more conducive compared to that ridiculous answer you've wrote.

Sometimes, the sincerity of the reader needs to match the sincerity of the writer in order for the sincerity to get across.

I sincerely meant "Congratulations!"

I was impressed --- I would have had to go through Seth's and Jeff's and no telling how many other contributors' code to find out how to parse the rpm name.

This guy had the native skills to produce it in a timely fashion.

On 02/22/2011 07:23 PM, Leonard den Ottolander wrote:

Hi Greg,

On Sat, 2011-02-19 at 09:23 -0700, Greg Bailey wrote:

...

OK, this morning's programming project is a python script to automatically generate your list. I get:

I hadn't spotted that you already solved this in python. With some shell scripting I come to essentially the same result. (My hit on zsh is a last iteration bug :)

I have one addition: comps-4WS-0.20110202. Not sure what to make of anaconda-product-4-2WS.

...

initscripts-7.93.35-1.el4_8.src.rpm kdelibs-3.3.1-17.el4_8.1.src.rpm pidgin-2.6.6-5.el4_8.src.rpm seamonkey-1.0.9-66.el4_8.src.rpm squirrelmail-1.4.8-5.el4_8.8.src.rpm

I think these are false positives.

...

indexhtml-4.1-1.src.rpm

Rather distro dependent but it might need updating as well.

Everything else on our lists matches afaict.

Regards, Leonard.

Thanks guys.

The comps files are created at distro spin and will not be updated as we will not be re-spinning the distro or ISOs. comps is also used in a different way by RHN, which is why upstream rebuilt it.

The anaconda product RPM is also not one that we need to do as upstream has WS, ES, AS, etc versions that they charge different $$$ amount for. All of the others are subsets of AS, which is what our SRPM anaconda-product-4.0-2.centos4.src.rpm is based on. That contains all upstream el4 packages.

You guys are also correct that the .dist tag (.el4, .el4_x, etc.) is not necessarily critical. Sometimes within a release of a product, upstream will work on a new version of a package that will be part of the next "point release" and also will issue fixes to the package before the point release by using a different dist tag. So, abc-1.0.0-1.el4.i386.src.rpm will get an update to abc-1.0.0-2.el4.i386.src.rpm for a 4.9 release (as an example). If, while they are testing abc-1.0.0-2, they need to release a bug fix to abc-1.0.0-1 then they will change the dist tag to el4_8 and add a .1 after the tag. So it would become abc-1.0.0-1.el4_8.1.src.rpm ... this is because they already have a 1.0.0-2 somewhere in the release system. We try to be consistent with the dist tags, but sometimes they slip through with a different version. This in no way impacts the code or the binary compatibility of the RPM.

As far as the rest of the SRPMS are concerned, I need to look at both those lists one by one, but most (if not all) of those SRPMS are from arches other than i386 and x86_64, so will not be on my list of packages to build. I will post info about each one separately in another mail.

Thanks for taking the time to help me verify the 4.9 release.

Still missing according to Greg and my lists:

On Sat, 2011-02-19 at 09:23 -0700, Greg Bailey wrote:

autofs5-5.0.1-0.rc2.114.src.rpm devhelp-0.10-0.10.el4.src.rpm device-mapper-multipath-0.4.5-42.el4.src.rpm evolution28-gtk2-2.10.4-25.el4.1.src.rpm gnome-volume-manager-1.1.0-9.src.rpm iscsi-initiator-utils-4.0.3.0-10.src.rpm mpitests-3.1-5.el4.src.rpm pexpect-2.3-2.el4.src.rpm samba-3.0.33-0.29.el4.src.rpm sendmail-8.13.1-6.el4.src.rpm syslinux-2.11-2.src.rpm sysstat-5.0.5-27.el4.src.rpm system-config-lvm-1.1.4-4.el4.src.rpm systemtap-1.3-5.el4.src.rpm

All the above packages still need to be build for 4.

But

vnc-4.0-12.el4_7.1.src.rpm

is probably a false positive due to the "el4_7" part.

Hello Manuel,

On Mon, 2011-03-07 at 11:32 +0200, Manuel Wolfshant wrote:

On 03/07/2011 11:24 AM, Leonard den Ottolander wrote:

...

Still missing according to Greg and my lists:

I see all of the above in the mirrors I maintain. maybe you are looking at an out-of-sync mirror ?

Hadn't expected 4.9 already to have an update tree so I only checked "os". My bad. Every single one of these packages is indeed in the update tree. Sorry for the confusion and thanks team for the update to 4.9!

Regards, Leonard.

Hello Johnny,

On Tue, 2011-02-22 at 07:52 +0100, Leonard den Ottolander wrote:

On Fri, 2011-02-18 at 16:58 -0600, Johnny Hughes wrote:

...

It seems Red Hat is not releasing media for the 4.9 release, so this seems to be just a bunch of updates that is going into the tree.

Done some post filtering on that list and compared it with the list you came up with. Following packages seem to be missing from your list:

anaconda-product-4-2WS (?) devhelp-0.10-0.10.el4 dosfstools-2.8-20 evolution28-gtk2-2.10.4-25.el4.1 ftp-0.17-25.el4 indexhtml-4.1-1 (?) mpitests-3.1-5.el4 net-tools-1.60-40.el4 ntp-4.2.0.a.20040617-12.el4 pexpect-2.3-2.el4 (has been overlooked since 2009) syslinux-2.11-2 ypserv-2.13-19.el4_8.2

And the following packages seem to have never been built for CentOS-4: elilo-3.4-12.el4 ethereal-0.99.0-EL4.2 (now wireshark) gaim-1.5.0-12.el4 iprutils-2.2.8-6.el4 libehca-1.2-1.el4 libpfm-3.0-12_EL libunwind-0.98.2-3.el4 mcelog-0.4-1.13.EL modversions-1.0-4.el4_6.1 mozilla-1.7.13-1.4.1 (now firefox) openCryptoki-2.1.6-0.40.6 pfmon-3.0-12 ppc64-utils-0.8-2 s390utils-1.3.2-3.el4 salinfo-0.5-1.13 sysreport-1.3.15-8 udapl-1.2-0.4265.2.EL4 xenpv-0.1-10.el4 yaboot-1.3.12-7.6 zsh-4.2.0-3.EL.3

Regards, Leonard.