Hi gang - Love CentOS - you guys to a fabulous job.
It has been a while since I saw any update... I went to twitter.com/centos nothing there, twitter.com/centos6 nothing there, went to the qa calendar stuff nothing there.
Last I saw was something in September saying all RPM's are built and doing ISO's. Then nothing.
I know the whole story about its ready when its ready and I'm all for that... Its simply I went looking today and saw no status and was wondering what happened. Perhaps I am looking in the wrong place.
Thanks!
jerry
Jerry Geis wrote:
Hi gang - Love CentOS - you guys to a fabulous job.
It has been a while since I saw any update... I went to twitter.com/centos nothing there, twitter.com/centos6 nothing there, went to the qa calendar stuff nothing there.
Last I saw was something in September saying all RPM's are built and doing ISO's. Then nothing.
Oddly enough, my manager just walked in a couple hours ago, and asked me why I thought there hadn't been any updates to our 6.0 boxen.
Everything's being rolled into the CR repo, so there do not appear to be any "ordinary" 6.0 updates.
mark, annoyed, and having to install 300+ package updates to the 6.0 systems, and hope nothing breaks*
* On the other hand, maybe I'll see annoyance fixes, like Pidgen, that pops *under* other windows, the quirky screen handling in rxvt, and, oh yes, the "yes" buttons lack of attention after I click "logout" from the menu.
m.roth@5-cent.us wrote:
Everything's being rolled into the CR repo, so there do not appear to be any "ordinary" 6.0 updates.
well yes: upstream is at 6.1, so updates are happening for 6.1 and 6.0 won't receive any more "ordinary upates". The update path for 6.0 is through 6.1 . centos is offering CR which allows you to stay up-to-date even though C6.1 is not released yet. When it is released, if you have used CR you will just have very few packages to update.
On 10/21/2011 06:09 PM, Nicolas Thierry-Mieg wrote:
well yes: upstream is at 6.1, so updates are happening for 6.1 and 6.0 won't receive any more "ordinary upates". The update path for 6.0 is through 6.1 . centos is offering CR which allows you to stay up-to-date even though C6.1 is not released yet. When it is released, if you have used CR you will just have very few packages to update. _______________________________________________
Except.
If you have a 6.0 machine, and enable the cr/ repo, then you don't just get the 6.0 updates. You get most of the post-6.0 updates, plus what's been built for 6.1 (effectively still in QA), plus some post 6.1 updates (Again, still in QA). As far as I'm aware, there's now way to say "Just give me the 6.0 updates you have" when using the cr/ repo.
I am more than happy to be corrected on this operation of the cr repo tho, as I've held off on updating boxes with the cr/ repo so as not to get "untested" updates.
Regards
On Fri, Oct 21, 2011 at 6:22 PM, Steve Walsh steve@nerdvana.net.au wrote:
Except.
If you have a 6.0 machine, and enable the cr/ repo, then you don't just get the 6.0 updates. You get most of the post-6.0 updates, plus what's been built for 6.1 (effectively still in QA), plus some post 6.1 updates (Again, still in QA). As far as I'm aware, there's now way to say "Just give me the 6.0 updates you have" when using the cr/ repo.
I am more than happy to be corrected on this operation of the cr repo tho, as I've held off on updating boxes with the cr/ repo so as not to get "untested" updates.
The best policy is to stay with 5.7. Why would anyone want to use 6.x with the issue? All my boxes are still 5.7.
Newer version doesn't mean better software.
Vreme: 10/21/2011 12:25 PM, Fajar Priyanto piše:
On Fri, Oct 21, 2011 at 6:22 PM, Steve Walshsteve@nerdvana.net.au wrote:
Except.
If you have a 6.0 machine, and enable the cr/ repo, then you don't just get the 6.0 updates. You get most of the post-6.0 updates, plus what's been built for 6.1 (effectively still in QA), plus some post 6.1 updates (Again, still in QA). As far as I'm aware, there's now way to say "Just give me the 6.0 updates you have" when using the cr/ repo.
I am more than happy to be corrected on this operation of the cr repo tho, as I've held off on updating boxes with the cr/ repo so as not to get "untested" updates.
As far as I am aware, how I understood official explanation, packages that are introduced in CR repo already PASSED QA testing, but are in limbo because there are issues with building ISO.
The best policy is to stay with 5.7. Why would anyone want to use 6.x with the issue? All my boxes are still 5.7.
Newer version doesn't mean better software.
6.x is FAR too advanced for me to stay with 5.x. I am in no hurry, but I have my goal in replacing my systems one-by-one as time permits.
What interests me is where are centosplus kernels for 6.1/CR? I only see them in Toracats testing repo: http://centos.toracat.org/kernel/centos6/centosplus-testing/
On 10/21/2011 10:16 PM, Ljubomir Ljubojevic wrote:
Vreme: 10/21/2011 12:25 PM, Fajar Priyanto pis(e: As far as I am aware, how I understood official explanation, packages that are introduced in CR repo already PASSED QA testing, but are in limbo because there are issues with building ISO
Nope.
http://wiki.centos.org/AdditionalResources/Repositories/CR
"The continuous release ( CR ) repository makes generally available packages that will appear in the next point release of CentOS, on a testing and *hotfix* basis until formally released. "
"System administrators who choose to opt-in to this process can access the newly built packages, as soon as they are exported from the build system. They are less comprehensively reviewed in the QA validation stage. "
On 10/21/2011 06:25 AM, Steve Walsh wrote:
On 10/21/2011 10:16 PM, Ljubomir Ljubojevic wrote:
Vreme: 10/21/2011 12:25 PM, Fajar Priyanto pis(e: As far as I am aware, how I understood official explanation, packages that are introduced in CR repo already PASSED QA testing, but are in limbo because there are issues with building ISO
Nope.
http://wiki.centos.org/AdditionalResources/Repositories/CR
"The continuous release ( CR ) repository makes generally available packages that will appear in the next point release of CentOS, on a testing and *hotfix* basis until formally released. "
"System administrators who choose to opt-in to this process can access the newly built packages, as soon as they are exported from the build system. They are less comprehensively reviewed in the QA validation stage. "
There is SOME QA ... just not all the QA that they get as part of the main release.
They are not right off the build and into the server ... we do our functionality test suite prior to pushing CR (and other tests, and look for repo closure). They are fairly well vetted.
We are trying to serve two masters here ... fast release and fully tested release. CR is the middle of that and a compromise that should work and not break things AND still allow us to do the testing we want for the main release too.
So, you should expect more issues from CR than the main tree ... but the risk should be minimal for any kind of major breakage.
For what its worth, I use CR on the machines I manage in production.
On Fri, October 21, 2011 15:23, Johnny Hughes wrote:
There is SOME QA ... just not all the QA that they get as part of the main release.
They are not right off the build and into the server ... we do our functionality test suite prior to pushing CR (and other tests, and look for repo closure). They are fairly well vetted.
We are trying to serve two masters here ... fast release and fully tested release. CR is the middle of that and a compromise that should work and not break things AND still allow us to do the testing we want for the main release too.
So, you should expect more issues from CR than the main tree ... but the risk should be minimal for any kind of major breakage.
For what its worth, I use CR on the machines I manage in production.
OK. So my question is. I have Centos 6.0 installed on a couple of systems.
I have not modified any repos or installed any repos etc...
Am I receiving security updates via 'yum update', which as far as I can tell hasn't installed any updates for quite a few months??
If not, what do I need to do to get security updates?
These are not production systems, but I don't want to break anything unless it's broken already (i.e. security vulnerabilities and bug fixes).
On 10/21/2011 9:33 AM, Giles Coochey wrote:
OK. So my question is. I have Centos 6.0 installed on a couple of systems.
I have not modified any repos or installed any repos etc...
Am I receiving security updates via 'yum update', which as far as I can tell hasn't installed any updates for quite a few months??
If not, what do I need to do to get security updates?
These are not production systems, but I don't want to break anything unless it's broken already (i.e. security vulnerabilities and bug fixes).
You have two choices.
1) Enable the CR repo. This will let you update to packages that have been built for 6.1 as they become available. It is possible that there might be a few minor issues with these packages as they have been built for 6.1, but they should be fine for the most part.
2) Leave things as they are and when 6.1 becomes available, your normal 'yum update' will update you to 6.1 all at once. The downside here is that you have to wait until 6.1 is done before you get any more updates.
On Fri, October 21, 2011 15:39, Bowie Bailey wrote:
On 10/21/2011 9:33 AM, Giles Coochey wrote:
OK. So my question is. I have Centos 6.0 installed on a couple of systems.
I have not modified any repos or installed any repos etc...
Am I receiving security updates via 'yum update', which as far as I can tell hasn't installed any updates for quite a few months??
If not, what do I need to do to get security updates?
These are not production systems, but I don't want to break anything unless it's broken already (i.e. security vulnerabilities and bug fixes).
You have two choices.
- Enable the CR repo. This will let you update to packages that have
been built for 6.1 as they become available. It is possible that there might be a few minor issues with these packages as they have been built for 6.1, but they should be fine for the most part.
- Leave things as they are and when 6.1 becomes available, your normal
'yum update' will update you to 6.1 all at once. The downside here is that you have to wait until 6.1 is done before you get any more updates.
So Centos 6.0 is EOL?
On 10/21/2011 08:43 AM, Giles Coochey wrote:
On Fri, October 21, 2011 15:39, Bowie Bailey wrote:
On 10/21/2011 9:33 AM, Giles Coochey wrote:
OK. So my question is. I have Centos 6.0 installed on a couple of systems.
I have not modified any repos or installed any repos etc...
Am I receiving security updates via 'yum update', which as far as I can tell hasn't installed any updates for quite a few months??
If not, what do I need to do to get security updates?
These are not production systems, but I don't want to break anything unless it's broken already (i.e. security vulnerabilities and bug fixes).
You have two choices.
- Enable the CR repo. This will let you update to packages that have
been built for 6.1 as they become available. It is possible that there might be a few minor issues with these packages as they have been built for 6.1, but they should be fine for the most part.
- Leave things as they are and when 6.1 becomes available, your normal
'yum update' will update you to 6.1 all at once. The downside here is that you have to wait until 6.1 is done before you get any more updates.
So Centos 6.0 is EOL?
No ... CentOS-6.0 is a point in time release of CentOS-6. Point releases only exist while they are the main release. Once the next point release is done, they are moved to vault.
CentOS-6.1 is the next point in time release ... after it is out, there are no releases for 6.0.
There is NO MECHANISM to remain on anything except CentOS-6. Point releases are just service packs ... so you can get updated ISO media for installs that contain updated packages. It is like the difference between Windows 7 and Windows 7 Service Pack 1 ... they are the SAME, one just has more security updates and fixes that the other.
This is exactly the same behavior as upstream. If you install any EL6 stream release from any "point release" ISO set, then run any update, you will be at their latest EL6 package set (so if you install 6.0 ISOs and run yum update, and if the latest is 6.2, you would be updated to 6.2).
On 10/21/2011 9:43 AM, Giles Coochey wrote:
On Fri, October 21, 2011 15:39, Bowie Bailey wrote:
On 10/21/2011 9:33 AM, Giles Coochey wrote:
OK. So my question is. I have Centos 6.0 installed on a couple of systems.
I have not modified any repos or installed any repos etc...
Am I receiving security updates via 'yum update', which as far as I can tell hasn't installed any updates for quite a few months??
If not, what do I need to do to get security updates?
These are not production systems, but I don't want to break anything unless it's broken already (i.e. security vulnerabilities and bug fixes).
You have two choices.
- Enable the CR repo. This will let you update to packages that have
been built for 6.1 as they become available. It is possible that there might be a few minor issues with these packages as they have been built for 6.1, but they should be fine for the most part.
- Leave things as they are and when 6.1 becomes available, your normal
'yum update' will update you to 6.1 all at once. The downside here is that you have to wait until 6.1 is done before you get any more updates.
So Centos 6.0 is EOL?
Keep in mind that CentOS 6.0 is just a point-in-time view of CentOS 6. Unless you have very specific (and unusual) requirements, you should continue to upgrade to all of the CentOS 6.x releases.
RHEL 6 (and thus CentOS 6) should be supported through Nov 2017.
On 10/21/2011 08:43 AM, Giles Coochey wrote:
On Fri, October 21, 2011 15:39, Bowie Bailey wrote:
On 10/21/2011 9:33 AM, Giles Coochey wrote:
OK. So my question is. I have Centos 6.0 installed on a couple of systems.
I have not modified any repos or installed any repos etc...
Am I receiving security updates via 'yum update', which as far as I can tell hasn't installed any updates for quite a few months??
If not, what do I need to do to get security updates?
These are not production systems, but I don't want to break anything unless it's broken already (i.e. security vulnerabilities and bug fixes).
You have two choices.
- Enable the CR repo. This will let you update to packages that have
been built for 6.1 as they become available. It is possible that there might be a few minor issues with these packages as they have been built for 6.1, but they should be fine for the most part.
- Leave things as they are and when 6.1 becomes available, your normal
'yum update' will update you to 6.1 all at once. The downside here is that you have to wait until 6.1 is done before you get any more updates.
So Centos 6.0 is EOL?
No ... CentOS-6.0 is a point in time release of CentOS-6. Point releases only exist while they are the main release. Once the next point release is done, they are moved to vault.
CentOS-6.1 is the next point in time release ... after it is out, there are no releases for 6.0.
There is NO MECHANISM to remain on anything except CentOS-6. Point releases are just service packs ... so you can get updated ISO media for installs that contain updated packages. It is like the difference between Windows 7 and Windows 7 Service Pack 1 ... they are the SAME, one just has more security updates and fixes that the other.
This is exactly the same behavior as upstream. If you install any EL6 stream release from any "point release" ISO set, then run any update, you will be at their latest EL6 package set (so if you install 6.0 ISOs and run yum update, and if the latest is 6.2, you would be updated to 6.2).
Giles Coochey wrote:
So Centos 6.0 is EOL?
not familiar with the rhel life cycle are you? Read this: https://access.redhat.com/support/policy/updates/errata/
On Fri, October 21, 2011 16:02, Nicolas Thierry-Mieg wrote:
Giles Coochey wrote:
So Centos 6.0 is EOL?
not familiar with the rhel life cycle are you? Read this: https://access.redhat.com/support/policy/updates/errata/ _______________________________________________
Thanks. I see that.
However, if I install whatever latest version of an operating system distribution. I expect to be able to run something that will give me stable security-updates for that distribution.
It appears that this is not the case, and my only option is to take my servers down the beta route to Centos 6.1 Release Candidates.
Other than that - the only advice given so far is: remain vulnerable to attack.
On 10/21/2011 09:17 AM, Giles Coochey wrote:
On Fri, October 21, 2011 16:02, Nicolas Thierry-Mieg wrote:
Giles Coochey wrote:
So Centos 6.0 is EOL?
not familiar with the rhel life cycle are you? Read this: https://access.redhat.com/support/policy/updates/errata/ _______________________________________________
Thanks. I see that.
However, if I install whatever latest version of an operating system distribution. I expect to be able to run something that will give me stable security-updates for that distribution.
It appears that this is not the case, and my only option is to take my servers down the beta route to Centos 6.1 Release Candidates.
Other than that - the only advice given so far is: remain vulnerable to attack.
Do you see anything that says Beta or Release Candidate?
You could always PAY for the original and get the updates as they are released ... OR ... you can build them yourself. We are doing this as fast as we can.
If you need SLA type support, then CentOS is likely NOT the distro for you as it does not have SLAs. It is a distribution built and released by volunteers for you to use or not use as you see fit. If you need the updates faster than we can deliver them, you must either learn to build them yourself or find another way.
There is nothing BETA about the CR repo ... it is the CR repo.
On Fri, October 21, 2011 16:24, Johnny Hughes wrote:
On 10/21/2011 09:17 AM, Giles Coochey wrote:
However, if I install whatever latest version of an operating system distribution. I expect to be able to run something that will give me stable security-updates for that distribution.
It appears that this is not the case, and my only option is to take my servers down the beta route to Centos 6.1 Release Candidates.
Other than that - the only advice given so far is: remain vulnerable to attack.
Do you see anything that says Beta or Release Candidate?
Well, earlier in the discussion, we heard that these updates have not passed through the full QA process, so it seems QA is being performed by the userbase, so yes - to me, that sounds like Beta.
You could always PAY for the original and get the updates as they are released ... OR ... you can build them yourself. We are doing this as fast as we can.
Your work is appreciated, look - this isn't an attack on the distribution. I'm not having a go at the volunteers. Sorry if it came out that way.
If you need SLA type support, then CentOS is likely NOT the distro for you as it does not have SLAs. It is a distribution built and released by volunteers for you to use or not use as you see fit. If you need the updates faster than we can deliver them, you must either learn to build them yourself or find another way.
At work I use Redhat, at home I use CentOS, but that doesn't mean it shouldn't have a sane release process.
There is nothing BETA about the CR repo ... it is the CR repo.
See my comments above, and review earlier posts in this thread.
Johnny Hughes wrote:
On 10/21/2011 09:17 AM, Giles Coochey wrote:
On Fri, October 21, 2011 16:02, Nicolas Thierry-Mieg wrote:
Giles Coochey wrote:
So Centos 6.0 is EOL?
<snip>
However, if I install whatever latest version of an operating system distribution. I expect to be able to run something that will give me stable security-updates for that distribution.
It appears that this is not the case, and my only option is to take my servers down the beta route to Centos 6.1 Release Candidates.
<snip>
Do you see anything that says Beta or Release Candidate?
You could always PAY for the original and get the updates as they are released ... OR ... you can build them yourself. We are doing this as fast as we can.
<snip>
There is nothing BETA about the CR repo ... it is the CR repo.
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history. My manager, only yesterday, figured that for any updates at all to 6.0, we had to use the CR repo, and we're just starting that, cautiously.
And remember, this is the community *Enterprise* (level) o/s. There are reasons that we run CentOS, and not (*bleah*) fedora.
mark
m.roth@5-cent.us wrote:
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
this is the way it has always been: once upstream releases x.y+1 , there are no more updates to x.y (in upstream and therefore also in centos), until centos releases x.y+1 . the difference now is: if you want the updates which will become available once centos x.y+1 is released, you can get them through the CR repo. The price you pay is that the packages may not be as thoroughly tested as they will be when x.y+1 is released.
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
this is the way it has always been: once upstream releases x.y+1 , there are no more updates to x.y (in upstream and therefore also in centos), until centos releases x.y+1 .
Yes, but that used to be transparent, because the centos x.y+1 release happened quickly so it didn't matter that the update repo was held back until an iso build was done.
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
this is the way it has always been: once upstream releases x.y+1 , there are no more updates to x.y (in upstream and therefore also in centos), until centos releases x.y+1 .
Yes, but that used to be transparent, because the centos x.y+1 release happened quickly so it didn't matter that the update repo was held back until an iso build was done.
Yes, and NOW the release process is MUCH harder.
Red Hat used to have an AS release that contained everything ... we build that and we get everything. Nice and simple. Build all the packages, look at it against the AS iso set ... done. Two weeks was about as long as it took.
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6) Red Hat Enterprise Linux Workstation (v. 6) Red Hat Enterprise Linux Desktop (v. 6) Red Hat Enterprise Linux HPC Node (v. 6) Red Hat Enterprise Linux Workstation FasTrack (v. 6) Red Hat Enterprise Linux Server FasTrack (v. 6) Red Hat Enterprise Linux Desktop FasTrack (v. 6) Red Hat Enterprise Linux Scalable File System (v. 6) Red Hat Enterprise Linux Resilient Storage (v. 6) Red Hat Enterprise Linux Load Balancer (v. 6) Red Hat Enterprise Linux HPC Node FasTrack (v. 6) Red Hat Enterprise Linux High Performance Network (v. 6) Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.
Now we have to engineer a compilation of all those groupings, we have to figure out what parts of the optional channels go at the point release and which ones do not (the ones that are upgrades). Sometimes the only way to tell is when something does not build correctly and you have reverse an optional package to a previous version for the build, etc.
We have to use anaconda to build our ISOs and upstream is using "something else" to build theirs .. so anaconda NEVER works anymore out of the box. We get ISOs (or usb images) that do not work and have to basically redesign anaconda.
We can't look at upstream build logs, we can't get all the binary RPMs for testing and be within the Terms of Service.
And with the new release, it seems that they have purposely broken the rpmmacros, and do not care to fix it:
https://bugzilla.redhat.com/show_bug.cgi?id=743229
So, trust me, it is MUCH more complicated now than it was with previous releases to build.
With the 5.7 release, there were several SRPMS that did not make it to the public FTP server without much prompting from us. And with the Authorized Use Policy, I can not just go to RHN and grab that SRPM and use it. If it is not public, we can no longer release it.
So, the short answer is, it now takes longer.
Thanks, Johnny Hughes
On Fri, Oct 21, 2011 at 12:54 PM, Johnny Hughes johnny@centos.org wrote:
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
this is the way it has always been: once upstream releases x.y+1 , there are no more updates to x.y (in upstream and therefore also in centos), until centos releases x.y+1 .
Yes, but that used to be transparent, because the centos x.y+1 release happened quickly so it didn't matter that the update repo was held back until an iso build was done.
Yes, and NOW the release process is MUCH harder.
Red Hat used to have an AS release that contained everything ... we build that and we get everything. Nice and simple. Build all the packages, look at it against the AS iso set ... done. Two weeks was about as long as it took.
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6) Red Hat Enterprise Linux Workstation (v. 6) Red Hat Enterprise Linux Desktop (v. 6) Red Hat Enterprise Linux HPC Node (v. 6) Red Hat Enterprise Linux Workstation FasTrack (v. 6) Red Hat Enterprise Linux Server FasTrack (v. 6) Red Hat Enterprise Linux Desktop FasTrack (v. 6) Red Hat Enterprise Linux Scalable File System (v. 6) Red Hat Enterprise Linux Resilient Storage (v. 6) Red Hat Enterprise Linux Load Balancer (v. 6) Red Hat Enterprise Linux HPC Node FasTrack (v. 6) Red Hat Enterprise Linux High Performance Network (v. 6) Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.
Now we have to engineer a compilation of all those groupings, we have to figure out what parts of the optional channels go at the point release and which ones do not (the ones that are upgrades). Sometimes the only way to tell is when something does not build correctly and you have reverse an optional package to a previous version for the build, etc.
We have to use anaconda to build our ISOs and upstream is using "something else" to build theirs .. so anaconda NEVER works anymore out of the box. We get ISOs (or usb images) that do not work and have to basically redesign anaconda.
We can't look at upstream build logs, we can't get all the binary RPMs for testing and be within the Terms of Service.
And with the new release, it seems that they have purposely broken the rpmmacros, and do not care to fix it:
https://bugzilla.redhat.com/show_bug.cgi?id=743229
So, trust me, it is MUCH more complicated now than it was with previous releases to build.
With the 5.7 release, there were several SRPMS that did not make it to the public FTP server without much prompting from us. And with the Authorized Use Policy, I can not just go to RHN and grab that SRPM and use it. If it is not public, we can no longer release it.
So, the short answer is, it now takes longer.
Thanks, Johnny Hughes
As someone who was part of the previous "6.0" discussions, I have to say thank you for finally laying out some details about what the issues are. More information like this would really go a long way towards preventing future flame-fests.
Thanks for your hard work.
-☙ Brian Mathis ❧-
On Fri, 21 Oct 2011, Johnny Hughes wrote:
Yes, and NOW the release process is MUCH harder. [....]
Thanks for that explanation. I knew that Red Hat's internal development process was throwing wrenches in the CentOS build system, but I hadn't realized how systemic and legally complicated the difficulties actually are.
On Fri, Oct 21, 2011 at 11:54 AM, Johnny Hughes johnny@centos.org wrote:
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
On 10/21/2011 12:20 PM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 11:54 AM, Johnny Hughes johnny@centos.org wrote:
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
Trust me ... the Linux Foundation thinks it is OK, so we are SOL.
On 10/21/11 10:25 AM, "Johnny Hughes" johnny@centos.org wrote:
On 10/21/2011 12:20 PM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 11:54 AM, Johnny Hughes johnny@centos.org wrote:
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
Trust me ... the Linux Foundation thinks it is OK, so we are SOL.
I'd rather get the opinion of the FSF (those whom wrote the license) instead of LF, as they don't matter as much, really.
On Fri, Oct 21, 2011 at 12:28 PM, Gary Greene ggreene@minervanetworks.com wrote:
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
Trust me ... the Linux Foundation thinks it is OK, so we are SOL.
I'd rather get the opinion of the FSF (those whom wrote the license) instead of LF, as they don't matter as much, really.
You'd need a copyright owner to initiate legal action. And the FSF generally is more concerned about source availability although binaries are clearly derived from source and covered by the same copyright, and I can't see any exception at least in GPLv2 about being able to put additional redistribution/use restrictions on covered binaries.
On 10/21/2011 12:37 PM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 12:28 PM, Gary Greene ggreene@minervanetworks.com wrote:
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
Trust me ... the Linux Foundation thinks it is OK, so we are SOL.
I'd rather get the opinion of the FSF (those whom wrote the license) instead of LF, as they don't matter as much, really.
You'd need a copyright owner to initiate legal action. And the FSF generally is more concerned about source availability although binaries are clearly derived from source and covered by the same copyright, and I can't see any exception at least in GPLv2 about being able to put additional redistribution/use restrictions on covered binaries.
They are not restricting your right to distribute, they are restricting your access to RHN if you choose to distribute.
On Fri, Oct 21, 2011 at 1:05 PM, Johnny Hughes johnny@centos.org wrote:
You'd need a copyright owner to initiate legal action. And the FSF generally is more concerned about source availability although binaries are clearly derived from source and covered by the same copyright, and I can't see any exception at least in GPLv2 about being able to put additional redistribution/use restrictions on covered binaries.
They are not restricting your right to distribute, they are restricting your access to RHN if you choose to distribute.
Which is explicitly imposing additional restrictions. Which is explicitly prohibited in section 6. I don't see any exceptions relating to what the consequences of those restrictions might be.
On Friday, October 21, 2011 02:22:26 PM Les Mikesell wrote:
Which is explicitly imposing additional restrictions. Which is explicitly prohibited in section 6. I don't see any exceptions relating to what the consequences of those restrictions might be.
The RHN AUP simply says that if you redistribute information from RHN you lose access to RHN. It does not restrict your right to redistribute anything; it restricts access to future information distributions from RHN. I know that's splitting hairs, but it does seem to meet the letter of the license. After all, RHN access is not required except for updates; if I really wanted to do so I could redistribute everything I have from RHN at this point in time and upstream has no legal recourse against that distribution that I know of (but I am neither a lawyer nor a paralegal; Russ on the other hand knows of what he speaks....).
They can, however, choose to not distribute anything else to me in the future, and nothing in the GPL or any other license used by upstream forces them to distribute anything new to me. And that's the gestalt of the RHN AUP; it states under what conditions RHN will distribute the compiled binary code (treated specially by GPL and not as a derived work) to you, its customer. Once you have received the binary of a particular version you have the right, under GPL and only for GPL-covered packages, to receive the source code for that particular version of that package.
Upstream is very gracious (in my opinion, at least) and distributes all of its source, not just GPL source and not just to customers but to the public at large (I say all; I haven't personally verified that all source in any given RHN channel is indeed available publicly on ftp.redhat.com, primarily because I don't have access to all channels). They could distribute only the source that they legally have to under those licenses that require it, but not for the source covered under other licenses that do not require redistribution of source plus modifications.
But just because I have version 1.2.3 of a package does not give me a guaranteed right under GPL to get 1.2.4 from them. And just because I can get the source to the 1.2.4 package they distribute does not give me an automatic right to the corresponding binary as the GPL does treat the compiled code specially. If you get the binary, you have the right to the source; if you have the source it is assumed you can generate the binary yourself (as is proven by the various EL rebuilds).
The level of difficulty required to generate the binary is not specified or even addressed by the GPL, nor does the GPL guarantee your ability to generate the exact same binary as someone else distributes..... nor is the distributor of the binary restricted at all in how difficult generating their exact binary, or a 100% compatible binary, can be. This seems to be the current holdup with C6.1, in my opinion; you can build *a* binary but will it work just like *the* binary? Upstream can make it even more difficult than they already have (and I know it's currently very frustrating to the CentOS team just from reading this thread!).
Russ, is that summary even close to accurate in your opinion?
These are the facts of life for an EL rebuild distribution user. If you want a primary access distribution (rather than a secondary rebuild) you need to find one that meets your needs, either by paying up for upstream or by going to something else (and there are really only two suitable enterprise choices for 'something else' in this case (and in my opinion): OpenSuSE or Debian Stable).
I'm evaluating Debian Stable on IA64 myself, as Debian Stable is the only actively maintained enterprise-grade distribution (again, in my opinion) freely available for IA64 (yes, upstream's EL5 is still available and is still maintained, but it costs six arms and eight legs to purchase for the machines I have; SLES likewise).
And I don't really currently have the time to rebuild C6 for IA64 myself. I'd love to, and I've had conversations with like-minded people, and I don't really want to go to Debian on it since I really want the IA64 boxes to work like all the other servers here which are running upstream EL rebuilds. But I have more important and necessary things to do with my time at the moment than to get into the game of maintaining a private rebuild for IA64 (I say private; even if I had time to maintain the build I don't have time to deal with the 'issues' of a public build!).
On Fri, 21 Oct 2011, Gary Greene wrote:
Trust me ... the Linux Foundation thinks it is OK, so we are SOL.
I'd rather get the opinion of the FSF (those whom wrote the license) instead of LF, as they don't matter as much, really.
Feel free to approach whoever you wish on your own account ... but it is really a settled issue from a CentOS point of view
-- Russ herrold
On Fri, 21 Oct 2011, Johnny Hughes wrote:
On 10/21/2011 12:20 PM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 11:54 AM, Johnny Hughes johnny@centos.org wrote:
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
The GPL, v2, only requires access to sources where one is providing binaries ... As Johnny noted, this subset of the binary content are not freely to 'all comers' from the upstream
As a general rule, CentOS is happy to rebuild freely available sources from the upstream ... and the upstream is a 'good egg' in making stuff available. Anyone wanting more just has to cause the upstream to expose relevant sources in their enterprise portion of their public FTP tree
What part of 'not providing access to binary content' is unclear?
Trust me ... the Linux Foundation thinks it is OK, so we are SOL.
And indeed, I sat in Eben Moglin's office and discussed this very topic, some years ago ... straight from the horse's mouth, so to speak
-- Russ herrold
On Fri, Oct 21, 2011 at 1:04 PM, R P Herrold herrold@centos.org wrote:
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
The GPL, v2, only requires access to sources where one is providing binaries
Where do you see an exception that says binaries are different from sources? They are pretty clearly a covered derived work.
... As Johnny noted, this subset of the binary content are not freely to 'all comers' from the upstream
Yes, you don't have to give access to binaries. But you also can't restrict subsequent redistribution by anyone who gets them. Unless I've missed something and the GPLv2 isn't that big.
What part of 'not providing access to binary content' is unclear?
You'd need the help of someone with a paid subscription.
Trust me ... the Linux Foundation thinks it is OK, so we are SOL.
And indeed, I sat in Eben Moglin's office and discussed this very topic, some years ago ... straight from the horse's mouth, so to speak
I suppose that would have to be considered an expert interpretation, but it's not what the thing says.
On 10/21/11 10:20 AM, "Les Mikesell" lesmikesell@gmail.com wrote:
On Fri, Oct 21, 2011 at 11:54 AM, Johnny Hughes johnny@centos.org wrote:
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.
I've never quite understood how anything containing any GPL-covered code could have any redistribution/use restrictions added.
Agreed. Being that the GPL is more a distribution license than a use license, the legality of what RH is saying here is a little questionable. I'd honestly bring this up to the FSF for a clarification point.
Thanks, that is the part I was looking for also...I wish thee was someway that Redhat would work with folks to not make it so difficult, I realize that the original intent was to make it harder for Oracle and the likes but the end up hurting the community more than they hurt the big guys...bummer :(
On Fri, Oct 21, 2011 at 11:54 AM, Johnny Hughes johnny@centos.org wrote:
Snip.... So, the short answer is, it now takes longer.
Thanks, Johnny Hughes
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Johnny Hughes wrote:
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
this is the way it has always been: once upstream releases x.y+1 , there are no more updates to x.y (in upstream and therefore also in centos), until centos releases x.y+1 .
Yes, but that used to be transparent, because the centos x.y+1 release happened quickly so it didn't matter that the update repo was held back until an iso build was done.
<snip>
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6) Red Hat Enterprise Linux Workstation (v. 6) Red Hat Enterprise Linux Desktop (v. 6) Red Hat Enterprise Linux HPC Node (v. 6) Red Hat Enterprise Linux Workstation FasTrack (v. 6) Red Hat Enterprise Linux Server FasTrack (v. 6) Red Hat Enterprise Linux Desktop FasTrack (v. 6) Red Hat Enterprise Linux Scalable File System (v. 6) Red Hat Enterprise Linux Resilient Storage (v. 6) Red Hat Enterprise Linux Load Balancer (v. 6) Red Hat Enterprise Linux HPC Node FasTrack (v. 6) Red Hat Enterprise Linux High Performance Network (v. 6) Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.
Wait, are you saying that a given install group name installs different packages, depending on the release name? I mean, if I were working on the team, I'd build an Everything release group, and just have subsets, based on which release group was chosen.
And what's the FasTrack, as opposed to the non-FasTrack?
mark
On 10/21/2011 12:39 PM, m.roth@5-cent.us wrote:
Johnny Hughes wrote:
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
this is the way it has always been: once upstream releases x.y+1 , there are no more updates to x.y (in upstream and therefore also in centos), until centos releases x.y+1 .
Yes, but that used to be transparent, because the centos x.y+1 release happened quickly so it didn't matter that the update repo was held back until an iso build was done.
<snip> > Now, for version 6, they have: > > Red Hat Enterprise Linux Server (v. 6) > Red Hat Enterprise Linux Workstation (v. 6) > Red Hat Enterprise Linux Desktop (v. 6) > Red Hat Enterprise Linux HPC Node (v. 6) > Red Hat Enterprise Linux Workstation FasTrack (v. 6) > Red Hat Enterprise Linux Server FasTrack (v. 6) > Red Hat Enterprise Linux Desktop FasTrack (v. 6) > Red Hat Enterprise Linux Scalable File System (v. 6) > Red Hat Enterprise Linux Resilient Storage (v. 6) > Red Hat Enterprise Linux Load Balancer (v. 6) > Red Hat Enterprise Linux HPC Node FasTrack (v. 6) > Red Hat Enterprise Linux High Performance Network (v. 6) > Red Hat Enterprise Virtualization > > They have the same install groups with different packages based on the > above groupings, so we have to do some kind of custom generation of the > comps files to things work.
Wait, are you saying that a given install group name installs different packages, depending on the release name? I mean, if I were working on the team, I'd build an Everything release group, and just have subsets, based on which release group was chosen.
And what's the FasTrack, as opposed to the non-FasTrack?
No what I mean is, there is an "install group" named "ha" (with a High Availability description) whose definition might contain 20 packages on the Server media set, 15 packages on Workstation media set, 8 packages on the Desktop Media set, and 50 packages on Resilient Storage media set.
CentOS only has one product ... so we need a compilation of the install information from all of the different media groups ... what you would have found in the AS type product of EL3. Only now we have to build this compilation from all the component parts, or else we can not allow group type installations from within the installer.
ha was one example, but "office programs" or "graphical internet" are other examples.
FasTrack is an upstream program defined here: http://www.redhat.com/rhn/rhndetails/fastrack/
Johnny Hughes wrote:
On 10/21/2011 12:39 PM, m.roth@5-cent.us wrote:
Johnny Hughes wrote:
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
<snip>
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6) Red Hat Enterprise Linux Workstation (v. 6) Red Hat Enterprise Linux Desktop (v. 6) Red Hat Enterprise Linux HPC Node (v. 6) Red Hat Enterprise Linux Workstation FasTrack (v. 6) Red Hat Enterprise Linux Server FasTrack (v. 6) Red Hat Enterprise Linux Desktop FasTrack (v. 6) Red Hat Enterprise Linux Scalable File System (v. 6) Red Hat Enterprise Linux Resilient Storage (v. 6) Red Hat Enterprise Linux Load Balancer (v. 6) Red Hat Enterprise Linux HPC Node FasTrack (v. 6) Red Hat Enterprise Linux High Performance Network (v. 6) Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.
Wait, are you saying that a given install group name installs different packages, depending on the release name? I mean, if I were working on the team, I'd build an Everything release group, and just have subsets, based on which release group was chosen.
<snip>
No what I mean is, there is an "install group" named "ha" (with a High Availability description) whose definition might contain 20 packages on the Server media set, 15 packages on Workstation media set, 8 packages on the Desktop Media set, and 50 packages on Resilient Storage media set.
Oy! And are those on different media? I mean, how many DVD's is RH producing these days, and do you have to buy one or the other?
CentOS only has one product ... so we need a compilation of the install information from all of the different media groups ... what you would have found in the AS type product of EL3. Only now we have to build this compilation from all the component parts, or else we can not allow group type installations from within the installer.
Which is very appreciated. "Productization", making trying to build a system harder.
ha was one example, but "office programs" or "graphical internet" are other examples.
Right - I had to edit our perl ks.cgi, because they changed the name or spelling of things like office, or gnome, or KDE....
Johnny Hughes wrote:
On 10/21/2011 12:39 PM, m.roth@5-cent.us wrote:
Johnny Hughes wrote:
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
<snip>
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6) Red Hat Enterprise Linux Workstation (v. 6) Red Hat Enterprise Linux Desktop (v. 6) Red Hat Enterprise Linux HPC Node (v. 6) Red Hat Enterprise Linux Workstation FasTrack (v. 6) Red Hat Enterprise Linux Server FasTrack (v. 6) Red Hat Enterprise Linux Desktop FasTrack (v. 6) Red Hat Enterprise Linux Scalable File System (v. 6) Red Hat Enterprise Linux Resilient Storage (v. 6) Red Hat Enterprise Linux Load Balancer (v. 6) Red Hat Enterprise Linux HPC Node FasTrack (v. 6) Red Hat Enterprise Linux High Performance Network (v. 6) Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.
Wait, are you saying that a given install group name installs different packages, depending on the release name? I mean, if I were working on the team, I'd build an Everything release group, and just have subsets, based on which release group was chosen.
<snip>
No what I mean is, there is an "install group" named "ha" (with a High Availability description) whose definition might contain 20 packages on the Server media set, 15 packages on Workstation media set, 8 packages on the Desktop Media set, and 50 packages on Resilient Storage media set.
Oy! And are those on different media? I mean, how many DVD's is RH producing these days, and do you have to buy one or the other?
CentOS only has one product ... so we need a compilation of the install information from all of the different media groups ... what you would have found in the AS type product of EL3. Only now we have to build this compilation from all the component parts, or else we can not allow group type installations from within the installer.
Which is very appreciated. "Productization", making trying to build a system harder.
ha was one example, but "office programs" or "graphical internet" are other examples.
Right - I had to edit our perl ks.cgi, because they changed the name or spelling of things like office, or gnome, or KDE....
mark
On 10/21/2011 12:54 PM, Johnny Hughes wrote:
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
this is the way it has always been: once upstream releases x.y+1 , there are no more updates to x.y (in upstream and therefore also in centos), until centos releases x.y+1 .
Yes, but that used to be transparent, because the centos x.y+1 release happened quickly so it didn't matter that the update repo was held back until an iso build was done.
Yes, and NOW the release process is MUCH harder.
Red Hat used to have an AS release that contained everything ... we build that and we get everything. Nice and simple. Build all the packages, look at it against the AS iso set ... done. Two weeks was about as long as it took.
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6) Red Hat Enterprise Linux Workstation (v. 6) Red Hat Enterprise Linux Desktop (v. 6) Red Hat Enterprise Linux HPC Node (v. 6) Red Hat Enterprise Linux Workstation FasTrack (v. 6) Red Hat Enterprise Linux Server FasTrack (v. 6) Red Hat Enterprise Linux Desktop FasTrack (v. 6) Red Hat Enterprise Linux Scalable File System (v. 6) Red Hat Enterprise Linux Resilient Storage (v. 6) Red Hat Enterprise Linux Load Balancer (v. 6) Red Hat Enterprise Linux HPC Node FasTrack (v. 6) Red Hat Enterprise Linux High Performance Network (v. 6) Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.
They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.
Now we have to engineer a compilation of all those groupings, we have to figure out what parts of the optional channels go at the point release and which ones do not (the ones that are upgrades). Sometimes the only way to tell is when something does not build correctly and you have reverse an optional package to a previous version for the build, etc.
We have to use anaconda to build our ISOs and upstream is using "something else" to build theirs .. so anaconda NEVER works anymore out of the box. We get ISOs (or usb images) that do not work and have to basically redesign anaconda.
We can't look at upstream build logs, we can't get all the binary RPMs for testing and be within the Terms of Service.
And with the new release, it seems that they have purposely broken the rpmmacros, and do not care to fix it:
https://bugzilla.redhat.com/show_bug.cgi?id=743229
So, trust me, it is MUCH more complicated now than it was with previous releases to build.
With the 5.7 release, there were several SRPMS that did not make it to the public FTP server without much prompting from us. And with the Authorized Use Policy, I can not just go to RHN and grab that SRPM and use it. If it is not public, we can no longer release it.
So, the short answer is, it now takes longer.
Thanks, Johnny Hughes
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
And that Johnny has been the answer we have been requesting for a looooong time now. I figured the upstream packaging changes broke your systems even when lance said that wasn't the case. The results speak for themselves. Nothing against the Centos folks you are now being actively worked against by Redhat itself. This is going to slowly choke off community builds of RHEL...and force them to fedora. Due to this decicion byt he upstream is why I'm moving to Ubuntu LTS for my new servers. It is unfortunate that the abuse by Orcale of the exact procedure you use that prompted Red Hat to take these packaging measures.
Vreme: 10/30/2011 01:44 PM, William Warren piše:
And that Johnny has been the answer we have been requesting for a looooong time now. I figured the upstream packaging changes broke your systems even when lance said that wasn't the case. The results speak for themselves. Nothing against the Centos folks you are now being actively worked against by Redhat itself. This is going to slowly choke off community builds of RHEL...and force them to fedora. Due to this decicion byt he upstream is why I'm moving to Ubuntu LTS for my new servers. It is unfortunate that the abuse by Orcale of the exact procedure you use that prompted Red Hat to take these packaging measures.
I do not think there is much to be worried for now. Most/all security patches will come out fairly fast now that CR repo is in place.
If need be, there can always be another repo that will be reserved for fast fixes that are not compatible with RHEL, like package with important fix that is not exactly compatible, but does the job same as upstream package. This would be only for unresolved packages with important fix, and only as long as complete fix is not completed.
On 10/30/2011 02:14 PM, Ljubomir Ljubojevic wrote:
Vreme: 10/30/2011 01:44 PM, William Warren piše:
And that Johnny has been the answer we have been requesting for a looooong time now. I figured the upstream packaging changes broke your systems even when lance said that wasn't the case. The results speak for themselves. Nothing against the Centos folks you are now being actively worked against by Redhat itself. This is going to slowly choke off community builds of RHEL...and force them to fedora. Due to this decicion byt he upstream is why I'm moving to Ubuntu LTS for my new servers. It is unfortunate that the abuse by Orcale of the exact procedure you use that prompted Red Hat to take these packaging measures.
I do not think there is much to be worried for now. Most/all security patches will come out fairly fast now that CR repo is in place.
If need be, there can always be another repo that will be reserved for fast fixes that are not compatible with RHEL, like package with important fix that is not exactly compatible, but does the job same as upstream package. This would be only for unresolved packages with important fix, and only as long as complete fix is not completed.
But this approach has been rejected in the past with the argument that all builds need to be binary compatible with upstream. This begs the question if the centos project still considers itself viable? It's one thing to lag behind because of technical difficulties but another if the upstream provider essentially wants to prevent you from doing what you are doing. In that case the project probably doesn't have much of a future because even if it gets back on track with reasonably timely releases then upstream will probably just react by making it even harder to build a clone.
Regards, Dennis
Vreme: 10/30/2011 03:46 PM, Dennis Jacobfeuerborn piše:
On 10/30/2011 02:14 PM, Ljubomir Ljubojevic wrote:
I do not think there is much to be worried for now. Most/all security patches will come out fairly fast now that CR repo is in place.
If need be, there can always be another repo that will be reserved for fast fixes that are not compatible with RHEL, like package with important fix that is not exactly compatible, but does the job same as upstream package. This would be only for unresolved packages with important fix, and only as long as complete fix is not completed.
But this approach has been rejected in the past with the argument that all builds need to be binary compatible with upstream. This begs the question if the centos project still considers itself viable? It's one thing to lag behind because of technical difficulties but another if the upstream provider essentially wants to prevent you from doing what you are doing. In that case the project probably doesn't have much of a future because even if it gets back on track with reasonably timely releases then upstream will probably just react by making it even harder to build a clone.
First off, I do NOT speak for dev team.
Next, what I said was if there is a problem with, for example missing src rpm for a security fix, and centos team knows what patch was applied (looking at the source and bug tracker), then I would be fine with alternative package with same patch that would bridge the time until upstream provides that src and it is possible to rebuild exact package.
Further, what is exactly difference between going to totally new distro and having not-100% compatible distro? Are small and rare differences enough to warrant switch of entire distro? I do not think so.
And what is with all that "I will switch to Ubuntu", "I am switching to Ubuntu and all of you better do the same"? Why is there need for sensationalism? If you want to go, then go. There is no need to alarm other users with doom prophecies. With CR repo (created only month or two ago) there is viable way to receive important updates.
If things complicate more on security front, CR can become enabled by default or update repo for current minor version will be populated with appropriate security fixes (my view, can not say for devs).
I would sincerely like to see number of security updates that are not in CR, and number released to CR repo, so we can deal with facts rather then "I haven't seen any updates for a while and I am convinced that every distro *must* have large number of security updates" mentality.
On Monday, October 31, 2011 12:11 AM, Ljubomir Ljubojevic wrote:
Vreme: 10/30/2011 03:46 PM, Dennis Jacobfeuerborn piše:
On 10/30/2011 02:14 PM, Ljubomir Ljubojevic wrote:
I do not think there is much to be worried for now. Most/all security patches will come out fairly fast now that CR repo is in place.
If need be, there can always be another repo that will be reserved for fast fixes that are not compatible with RHEL, like package with important fix that is not exactly compatible, but does the job same as upstream package. This would be only for unresolved packages with important fix, and only as long as complete fix is not completed.
But this approach has been rejected in the past with the argument that all builds need to be binary compatible with upstream. This begs the question if the centos project still considers itself viable? It's one thing to lag behind because of technical difficulties but another if the upstream provider essentially wants to prevent you from doing what you are doing. In that case the project probably doesn't have much of a future because even if it gets back on track with reasonably timely releases then upstream will probably just react by making it even harder to build a clone.
First off, I do NOT speak for dev team.
Next, what I said was if there is a problem with, for example missing src rpm for a security fix, and centos team knows what patch was applied (looking at the source and bug tracker), then I would be fine with alternative package with same patch that would bridge the time until upstream provides that src and it is possible to rebuild exact package.
It is not just what patches were applied. It is also what version of the toolchains and libraries were used in building the package. That is where the main problem is base on what the devs say besides the Redhat problem of packages that should not be distributed to others if you want to keep your RHN access...
Further, what is exactly difference between going to totally new distro and having not-100% compatible distro? Are small and rare differences enough to warrant switch of entire distro? I do not think so.
The Centos team wants to do 100% binary compatibility. Then any problem is upstream's fault. They are not like Oracle who can afford to leech off Redhat and hire their own engineers to do some tinkering on the side too.
And what is with all that "I will switch to Ubuntu", "I am switching to Ubuntu and all of you better do the same"? Why is there need for sensationalism? If you want to go, then go. There is no need to alarm other users with doom prophecies. With CR repo (created only month or two ago) there is viable way to receive important updates.
+1
If things complicate more on security front, CR can become enabled by default or update repo for current minor version will be populated with appropriate security fixes (my view, can not say for devs).
I would sincerely like to see number of security updates that are not in CR, and number released to CR repo, so we can deal with facts rather then "I haven't seen any updates for a while and I am convinced that every distro *must* have large number of security updates" mentality.
Every distro DOES have a large number of security updates. The real biggie is how many of them are remote root exploits and for those who provide shell access, how many of those are local root/privilege exploits. That's a HEALTHY mentality if you have Internet facing boxes or you have secrets/confidential stuff that you want to keep from other departments/colleagues.
On Fri, Oct 21, 2011 at 9:33 AM, m.roth@5-cent.us wrote:
There is nothing BETA about the CR repo ... it is the CR repo.
Johnny, chill. I don't blame him for being confused. Up until right now, you updated to a point release, then, over the weeks and months, there were updates. All of a sudden, there are *no* updates for the 6.0 point release, which is a major change in what everyone expected, based on history.
And if _you_ didn't understand this after all the discussion on the mail list, imagine all the people who don't subscribe or read daily.
On Friday, October 21, 2011 10:17:18 AM Giles Coochey wrote:
It appears that this is not the case, and my only option is to take my servers down the beta route to Centos 6.1 Release Candidates.
This is one area in which CentOS and Scientific Linux are different (and it's interesting, reading the SL lists, how that some of the folks that went SL a few months ago are confused about SL's direction, even to the point of calling it a waste of resources....). This is just one area, by the way.
So on Scientific Linux you can indeed 'stay with SL 6.0' and still get security updates only (as best as can be provided without other package updates) for the full length of the support period. There are and have been exceptions, but that was and is one of the primary goals, it appears, of SL.
However, the speed at which SL has put out 6.1 seems to imply that they aren't quite as picky about binary compatibility (library linked versions, and all of the other things that 'binary compatibility' means) as CentOS seems to be. (I say 'seems' in both cases because I do not have inside knowledge of either projects' binary compatibility tests).
And it appears that the 'binary compatibility' piece coupled with upstream's new acceptable use policy (which, since it has changed, might be something to ask FSF about anew) is the primary reason for the slowdown of CentOS, along with the secondary reason that there are packages in upstream's EL6 that aren't distributed on any media at all. I haven't looked closely enough to check if there are source packages in an RHN channel that don't exist on the public FTP.
But GPL does not cover the entire distribution; PostgreSQL, just to pull one of many packages out of thin air, is not GPL and thus source redistribution is not required, even to customers. Even GPL only requires redistribution by upstream to its customers.
On Fri, Oct 28, 2011 at 10:20 AM, Lamar Owen lowen@pari.edu wrote:
Even GPL only requires redistribution by upstream to its customers.
With _no additional restrictions_ on subsequent redistribution.
On 10/28/11 8:29 AM, Les Mikesell wrote:
On Fri, Oct 28, 2011 at 10:20 AM, Lamar Owenlowen@pari.edu wrote:
Even GPL only requires redistribution by upstream to its customers.
With_no additional restrictions_ on subsequent redistribution.
redhat's threat of disabling RHN access for redistributing RHN GPL sources seems to be in direct violation of this...
On Friday, October 28, 2011 11:29:52 AM Les Mikesell wrote:
On Fri, Oct 28, 2011 at 10:20 AM, Lamar Owen lowen@pari.edu wrote:
Even GPL only requires redistribution by upstream to its customers.
With _no additional restrictions_ on subsequent redistribution.
Losing access to RHN does not in any way restrict my redistribution of source I already have in my possession.
'Restricting distribution' is popping a DMCA takedown notice to the operator of a site redistributing the source and getting it removed; they can't do that (I'm neither going to comment on nor am I going to speculate about binaries).
But they can (and will) choose to not distribute anything to you in the future should you redistribute what you've received through RHN. I could (hypothetically) give you everything I've gotten from RHN; I won't (and the GPL doesn't make me) because I want future access to RHN, but if that access were to be removed for whatever reason I have complete freedom to distribute any and all source I've gotten up to that point.
And, really, it now makes absolutely perfect business sense why they give public access to their sources: they can cut off RHN to a user who hasn't downloaded the source from RHN and point to the public ftp and say, in effect, 'now get your source there, but no more RHN for you.' And that meets the letter of the GPL, which is all about source code access to those who have binaries. At least in my opinion, and assuming that all GPL-covered source is actually available on the public site.
But none of that helps when you need access to binaries to verify binary compatibility, and the AUP for the place you get your binaries interferes, even if you're paying for access to those binaries. And arguing about GPL won't help, since the GPL does not in any way cover all of the distribution.
What will help is figuring out how someone with access to RHN AUP covered information can 'clean room' only the information required to confirm binary compatibility to the 'binary compatibility verifier' without violating the AUP.
On Fri, Oct 28, 2011 at 11:13 AM, Lamar Owen lowen@pari.edu wrote:
Even GPL only requires redistribution by upstream to its customers.
With _no additional restrictions_ on subsequent redistribution.
Losing access to RHN does not in any way restrict my redistribution of source I already have in my possession.
Errr, what? What _is_ a restriction if not a penalty applied as a consequence of doing the restricted thing? How is, say, being required to pay a license fee as a consequence different from losing something you have already contracted and paid for?
But none of that helps when you need access to binaries to verify binary compatibility, and the AUP for the place you get your binaries interferes, even if you're paying for access to those binaries. And arguing about GPL won't help, since the GPL does not in any way cover all of the distribution.
That's true, but at least in the past, RH apparently thought GPL compliance and openness would win customers. If those customers leave, it might make a difference.
On 10/28/2011 06:53 PM, Les Mikesell wrote:
On Fri, Oct 28, 2011 at 11:13 AM, Lamar Owenlowen@pari.edu wrote:
Even GPL only requires redistribution by upstream to its customers.
With _no additional restrictions_ on subsequent redistribution.
Losing access to RHN does not in any way restrict my redistribution of source I already have in my possession.
Errr, what? What _is_ a restriction if not a penalty applied as a consequence of doing the restricted thing?
Disclaimer: IANAL
It seems the GPL requirements are met so then there is no GPL related restriction. If you exercise your GPL induced rights and redistribute the RHN src then there is nothing wrong with Red Hat deciding to no longer want you as a customer. You still got to exercise your rights. But once you are no longer a customer and thus no longer receiving RHN binaries from Red Hat then Red Hat is under no obligation to share with you anything from RHN anymore.
How is, say, being
required to pay a license fee as a consequence different from losing something you have already contracted and paid for?
It would surprise me if Red Hat would not refund the customer or let them ride out the term of what they have already paid for. And didn't the customer agree to Red Hat's terms (AUP) when they signed the contract?
Regards, Patrick
On Fri, Oct 28, 2011 at 12:17 PM, Patrick Lists centos-list@puzzled.xs4all.nl wrote:
How is, say, being required to pay a license fee as a consequence different from losing something you have already contracted and paid for?
It would surprise me if Red Hat would not refund the customer or let them ride out the term of what they have already paid for. And didn't the customer agree to Red Hat's terms (AUP) when they signed the contract?
The question is, how can a contract containing restrictions on what you can do with GPL covered content not invalidate your own right to redistribute, given that the GPL prohibits additional restrictions?
On 28/10/11 18:31, Les Mikesell wrote:
On Fri, Oct 28, 2011 at 12:17 PM, Patrick Lists centos-list@puzzled.xs4all.nl wrote:
How is, say, being required to pay a license fee as a consequence different from losing something you have already contracted and paid for?
It would surprise me if Red Hat would not refund the customer or let them ride out the term of what they have already paid for. And didn't the customer agree to Red Hat's terms (AUP) when they signed the contract?
The question is, how can a contract containing restrictions on what you can do with GPL covered content not invalidate your own right to redistribute, given that the GPL prohibits additional restrictions?
As I understand, Red Hat's AUP is more about protecting content other than sources and binaries that resides on RHN (yes, RHN is far more than just a distribution channel for SRPMs/RPMs). Such content and material is vital in supporting it's customers, and I believe the likes of Oracle and Suse were leveraging such content to try to sell support to existing RHEL customers. This is what Red Hat presumably seeks to stop.
On Fri, Oct 28, 2011 at 12:47 PM, Ned Slider ned@unixmail.co.uk wrote:
The question is, how can a contract containing restrictions on what you can do with GPL covered content not invalidate your own right to redistribute, given that the GPL prohibits additional restrictions?
As I understand, Red Hat's AUP is more about protecting content other than sources and binaries that resides on RHN (yes, RHN is far more than just a distribution channel for SRPMs/RPMs). Such content and material is vital in supporting it's customers, and I believe the likes of Oracle and Suse were leveraging such content to try to sell support to existing RHEL customers. This is what Red Hat presumably seeks to stop.
OK, but then it should have specific exceptions for GPL content already 'protected' from such proprietary behavior and restrictions. What is the point of the GPL existing if companies are allowed to add restrictions when they redistribute?
On Friday 28 October 2011 18:54:25 Les Mikesell wrote:
On Fri, Oct 28, 2011 at 12:47 PM, Ned Slider ned@unixmail.co.uk wrote:
The question is, how can a contract containing restrictions on what you can do with GPL covered content not invalidate your own right to redistribute, given that the GPL prohibits additional restrictions?
As I understand, Red Hat's AUP is more about protecting content other than sources and binaries that resides on RHN (yes, RHN is far more than just a distribution channel for SRPMs/RPMs). Such content and material is vital in supporting it's customers, and I believe the likes of Oracle and Suse were leveraging such content to try to sell support to existing RHEL customers. This is what Red Hat presumably seeks to stop.
OK, but then it should have specific exceptions for GPL content already 'protected' from such proprietary behavior and restrictions. What is the point of the GPL existing if companies are allowed to add restrictions when they redistribute?
But RH did not add restrictions. Whatever you get from them, you are free to redistribute, in accord with GPL. There can be *no* *legal* *action* against you if you do so. OTOH, it is their choice whether or not to give you anything else in the future. GPL is not broken by the choice they make.
Of course it is a form of a blackmail --- "don't redistribute or we'll cut off future support" --- but that is not in contradiction with the GPL, due to the word "future". Rather, it seems to be a loophole in the GPL itself, and a pretty nifty one, if you ask me. :-) Also, the essential idea of the GPL (that source should be free) is preserved --- you can always take whatever has been given to you through RHN and fork a project, without legal worry.
In addition, it appears that the business strategy of RH is essentially based on this loophole, and now they are just pushing it to the extreme, thanks to the challange from Oracle. It's a good business strategy, and personally I agree with it --- RH has found a way to fight other companies from stealing their work and customers, while upholding the GPL and giving a lot back to the community through upstream patches and support of Fedora. Of course, there are some collateral damage side-effects for the clones like CentOS and SL, but then that's life, nobody is perfect... ;-)
Best, :-) Marko
On Fri, Oct 28, 2011 at 2:37 PM, Marko Vojinovic vvmarko@gmail.com wrote:
But RH did not add restrictions. Whatever you get from them, you are free to redistribute, in accord with GPL. There can be *no* *legal* *action* against you if you do so. OTOH, it is their choice whether or not to give you anything else in the future. GPL is not broken by the choice they make.
That logic depends on a very strange interpretation of the term "restriction". The GPL doesn't narrowly define it narrowly as legal actions, it says you may not impost any further restrictions.
On Friday 28 October 2011 20:45:16 Les Mikesell wrote:
On Fri, Oct 28, 2011 at 2:37 PM, Marko Vojinovic vvmarko@gmail.com wrote:
But RH did not add restrictions. Whatever you get from them, you are free to redistribute, in accord with GPL. There can be *no* *legal* *action* against you if you do so. OTOH, it is their choice whether or not to give you anything else in the future. GPL is not broken by the choice they make.
That logic depends on a very strange interpretation of the term "restriction". The GPL doesn't narrowly define it narrowly as legal actions, it says you may not impost any further restrictions.
True, and that is why it is a loophole. You can interpret the word "restriction" in more than one way. IIUC, RH's interpretation is that "restriction" is something that is "against the law" if violated, in the sense that you can get sued by someone if you redistribute RH's code. There are no restrictions by RH, in that sense.
Whether or not this interpretation was meant when GPL was designed is an entirely different matter. IMHO, the FSF should have been more specific about what "restriction" means in the text of the GPL. But they weren't, and now RH has used this room to manouver around.
But I don't see it as a bad thing, all in all. If you want support from RH, pay for it. If not, use CentOS or some other clone. If they fall behind in providing updates, that amounts to the price that you didn't pay for RH's support. I think that's fair, given that RH developers are the ones doing the most of the heavyweight work.
Best, :-) Marko
On Fri, Oct 28, 2011 at 3:22 PM, Marko Vojinovic vvmarko@gmail.com wrote:
That logic depends on a very strange interpretation of the term "restriction". The GPL doesn't narrowly define it narrowly as legal actions, it says you may not impost any further restrictions.
True, and that is why it is a loophole. You can interpret the word "restriction" in more than one way. IIUC, RH's interpretation is that "restriction" is something that is "against the law" if violated, in the sense that you can get sued by someone if you redistribute RH's code. There are no restrictions by RH, in that sense.
Whether or not this interpretation was meant when GPL was designed is an entirely different matter. IMHO, the FSF should have been more specific about what "restriction" means in the text of the GPL. But they weren't, and now RH has used this room to manouver around.
Whether something is legal or not is always open to interpretation. But it would take a valid copyright holder to challenge their right to redistribute under those terms. My name might still be mentioned somewhere in comments in the distribution but I can't claim ownership of any particular line of code, so that leaves me out.
But I don't see it as a bad thing, all in all. If you want support from RH, pay for it. If not, use CentOS or some other clone.
It's a bad thing if you think clones should exist at all. Realistically, we would all probably be better off jumping ship the day of the fedora/EL split, but I've just been too lazy to learn to spell "apt-get".
On Saturday, October 29, 2011 04:36 AM, Les Mikesell wrote:
It's a bad thing if you think clones should exist at all. Realistically, we would all probably be better off jumping ship the day of the fedora/EL split, but I've just been too lazy to learn to spell "apt-get".
/me is puzzled. You spelt it correctly. Maybe not so keen on learning the intricacies of Debian and the 'Debian way'.
On Sat, Oct 29, 2011 at 7:56 AM, Christopher Chan christopher.chan@bradbury.edu.hk wrote:
On Saturday, October 29, 2011 04:36 AM, Les Mikesell wrote:
It's a bad thing if you think clones should exist at all. Realistically, we would all probably be better off jumping ship the day of the fedora/EL split, but I've just been too lazy to learn to spell "apt-get".
/me is puzzled. You spelt it correctly. Maybe not so keen on learning the intricacies of Debian and the 'Debian way'.
Yes, exactly. While there is not much difference in using the applications on an installed system of some other distribution, the installation and maintenance tools are all very specific and quirky and I have years invested in dealing with RedHat style quirks. Plus we have a team of hands-on operators that mostly deal with windows and aren't too happy about needing to know any linux commands, much less several very unrelated types. But that's the option that will happen before paid RHEL everywhere - or just more windows servers...
On Sat, 2011-10-29 at 20:56 +0800, Christopher Chan wrote:
On Saturday, October 29, 2011 04:36 AM, Les Mikesell wrote:
It's a bad thing if you think clones should exist at all. Realistically, we would all probably be better off jumping ship the day of the fedora/EL split, but I've just been too lazy to learn to spell "apt-get".
/me is puzzled. You spelt it correctly. Maybe not so keen on learning the intricacies of Debian and the 'Debian way'.
---- Linux is still Linux and while there is some learning curve, it does tend to broaden one's knowledge base.
Besides... apt has super cow powers...
# apt-get moo (__) (oo) /------/ / | || * /---/\ ~~ ~~ ...."Have you mooed today?"...
Craig
On Sat, Oct 29, 2011 at 3:03 PM, Craig White craigwhite@azapple.com wrote:
/me is puzzled. You spelt it correctly. Maybe not so keen on learning the intricacies of Debian and the 'Debian way'.
Linux is still Linux and while there is some learning curve, it does tend to broaden one's knowledge base.
I gave up on learning everything there is to know a long time ago and try to be more selective now. Learning a different way to accomplish the same thing just isn't that appealing. Especially when there are whole large books of obscure details involved, and all of that stuff that only anaconda and whatever equivalent debian/ubuntu use really understands but you have to deal with afterwards...
On Sunday, October 30, 2011 04:31 AM, Les Mikesell wrote:
On Sat, Oct 29, 2011 at 3:03 PM, Craig Whitecraigwhite@azapple.com wrote:
/me is puzzled. You spelt it correctly. Maybe not so keen on learning the intricacies of Debian and the 'Debian way'.
Linux is still Linux and while there is some learning curve, it does tend to broaden one's knowledge base.
I gave up on learning everything there is to know a long time ago and try to be more selective now. Learning a different way to accomplish the same thing just isn't that appealing. Especially when there are whole large books of obscure details involved, and all of that stuff that only anaconda and whatever equivalent debian/ubuntu use really understands but you have to deal with afterwards...
Yeah, never got my head around preseed and its DEFICIENCIES. Like no lvm over mdraid support. Although that might have been solved now in debian-installer.
Oh, and they only recently got multi-arch support i think or are they still working on it?
Speaking of Ubuntu, yeah, Ubuntu has nice big repositories but not all the packages are Canonical supported and so you can get stuff that are raw deals.
Yup, real good reasons to move to Ubuntu "LTS"
On 10/28/2011 12:47 PM, Ned Slider wrote:
On 28/10/11 18:31, Les Mikesell wrote:
On Fri, Oct 28, 2011 at 12:17 PM, Patrick Lists centos-list@puzzled.xs4all.nl wrote:
How is, say, being required to pay a license fee as a consequence different from losing something you have already contracted and paid for?
It would surprise me if Red Hat would not refund the customer or let them ride out the term of what they have already paid for. And didn't the customer agree to Red Hat's terms (AUP) when they signed the contract?
The question is, how can a contract containing restrictions on what you can do with GPL covered content not invalidate your own right to redistribute, given that the GPL prohibits additional restrictions?
As I understand, Red Hat's AUP is more about protecting content other than sources and binaries that resides on RHN (yes, RHN is far more than just a distribution channel for SRPMs/RPMs). Such content and material is vital in supporting it's customers, and I believe the likes of Oracle and Suse were leveraging such content to try to sell support to existing RHEL customers. This is what Red Hat presumably seeks to stop.
I can tell you that we have been contacted by upstream to make sure we **UNDERSTAND** the new AUP restrictions on distribution. I can also tell you that we (CentOS) are doing everything in our power to meet the restrictions as they were explained to us.
The restrictions do include the distribution of items downloaded directly from RHN.
On Sat, Oct 29, 2011 at 8:45 AM, Johnny Hughes johnny@centos.org wrote:
I can tell you that we have been contacted by upstream to make sure we **UNDERSTAND** the new AUP restrictions on distribution. I can also tell you that we (CentOS) are doing everything in our power to meet the restrictions as they were explained to us.
The restrictions do include the distribution of items downloaded directly from RHN.
Did they actually call it a "restriction" in a way that is prohibited in the GPL?
Also, there is probably room for a public, if not legal, complaint about gpl compliance if the source and binary components they distribute don't match in a way that you can rebuild a binary that works the same. Of course there is a lot of non-gpl content, so even strictly observing the GPL rules won't solve the whole problem.
Vreme: 10/29/2011 05:36 PM, Les Mikesell piše:
Also, there is probably room for a public, if not legal, complaint about gpl compliance if the source and binary components they distribute don't match in a way that you can rebuild a binary that works the same. Of course there is a lot of non-gpl content, so even strictly observing the GPL rules won't solve the whole problem.
Less, please do not steer-up trouble.
If you want to fight Red Hat create your own RHEL clone and then try to enact those rights you are asking about.
Better option is to have CentOS as it is, and they create forks with specific enhancements by adding GPL versions from Fedora or other places, or by using third party repositories consisting of best developers (to ensure stable systems).
Fighting windmills was done by Don Quixote and many small countries against certain political and military powers. And nothing good came out of it. As one of the my folks sayings go: Bull without horns can not fight with bull with horns... Not successfully at least.
On 10/21/2011 10:17 AM, Giles Coochey wrote:
On Fri, October 21, 2011 16:02, Nicolas Thierry-Mieg wrote:
Giles Coochey wrote:
So Centos 6.0 is EOL?
not familiar with the rhel life cycle are you? Read this: https://access.redhat.com/support/policy/updates/errata/ _______________________________________________
Thanks. I see that.
However, if I install whatever latest version of an operating system distribution. I expect to be able to run something that will give me stable security-updates for that distribution.
It appears that this is not the case, and my only option is to take my servers down the beta route to Centos 6.1 Release Candidates.
Other than that - the only advice given so far is: remain vulnerable to attack.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Or move to another distro that has timely security updates and long term support like Centos.
On 10/30/2011 8:33 PM, Christopher Chan wrote:
On Sunday, October 30, 2011 08:38 PM, William Warren wrote:
Or move to another distro that has timely security updates and long term support like Centos.
What...Ubuntu "LTS"? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
yeppers. I have 1 cent 5 machine left. Like I said before It it too bad RH is doing what they are doing. It is going to mean the death of RHEL rebuilds...look at what is happening to Centos. Per Johnny's statement they can't truly maintain 100% binary compatibility. It is not the Centos team's fault although they are going to be the biggest casualty.
On Monday, October 31, 2011 07:46:59 AM William Warren wrote:
Like I said before It it too bad RH is doing what they are doing. It is going to mean the death of RHEL rebuilds...look at what is happening to Centos. Per Johnny's statement they can't truly maintain 100% binary compatibility. It is not the Centos team's fault although they are going to be the biggest casualty.
If absolute 100% binary compatibility is not required, but admin-level compatibility and source-level compatibility with upstream EL is, Scientific Linux is covering that niche, and has their 6.1 out.
And that's not a criticism of CentOS, either, as the binary compatibility testing CentOS is doing has its purposes. Again, glad there is CR out there.
The rebuilding per se isn't the issue; testing against the upstream binaries for compatibility without running afoul of the upstream AUP seems to be the problem.
I have a couple of servers on Ubuntu LTS; after experiencing a few issues I'd say go Debian stable rather than Ubuntu LTS, from experience, if you're going to go that route.
Hi,
On Tue, Nov 1, 2011 at 10:13 AM, Mathieu Baudier mbaudier@argeo.org wrote:
If absolute 100% binary compatibility is not required, but admin-level compatibility and source-level compatibility with upstream EL is, Scientific Linux is covering that niche, and has their 6.1 out.
In which concrete use cases is 100% binary compatibility important?
I am no expert in compiling RPMs, but just recently I experienced the following:
After installing a previous version of 3rd party SOGo RPM and reporting to the developers that the service wouldn't start after installation, I was informed that the RPM had been compiled on Scientific Linux 6.1 and because of binary incompatibility the RPM did not work under RHEL/CentOS. They recompiled on CentOS and the updated RPM installed/worked fine on my system.
So if CentOS wouldn't be 100% compatible with RHEL, I guess we would start seeing more cases where programs compiled on RHEL might not run on CentOS. If you use just the base RPMs provided by the distro, this is no problem. But if you rely on some commercial / 3rd party RPMs, you might start facing problems.
At least this is how I understood it, please correct me if I've got it wrong :)
Best, Peter
Vreme: 11/01/2011 11:02 AM, Peter Peltonen piše:
Hi,
On Tue, Nov 1, 2011 at 10:13 AM, Mathieu Baudiermbaudier@argeo.org wrote:
If absolute 100% binary compatibility is not required, but admin-level compatibility and source-level compatibility with upstream EL is, Scientific Linux is covering that niche, and has their 6.1 out.
In which concrete use cases is 100% binary compatibility important?
I am no expert in compiling RPMs, but just recently I experienced the following:
After installing a previous version of 3rd party SOGo RPM and reporting to the developers that the service wouldn't start after installation, I was informed that the RPM had been compiled on Scientific Linux 6.1 and because of binary incompatibility the RPM did not work under RHEL/CentOS. They recompiled on CentOS and the updated RPM installed/worked fine on my system.
So if CentOS wouldn't be 100% compatible with RHEL, I guess we would start seeing more cases where programs compiled on RHEL might not run on CentOS. If you use just the base RPMs provided by the distro, this is no problem. But if you rely on some commercial / 3rd party RPMs, you might start facing problems.
At least this is how I understood it, please correct me if I've got it wrong :)
The whole point in creating binary compatible clone distro, in this case CentOS is so you can use paid RHEL and CentOS in same maintenance environment, or at first use CentOS and easily switch to RHEl if you start needing paid support (like when your company starts making real money, admin stops being available all the time, etc...).
In that case, you can Install CentOS and some paid (or OSS) application and set everything up. System will receive updates for next 7 years before EOL. If you expand your business in next 2-3 years, and your online business becomes critical, you can buy support from Red Hat and easily switch to RHEL (you would change several packages and system would slowly become full RHEL). If packets are not binary compatible, then your application could stop working in expected manner.
Another use case is when you buy RHEL certified Application. Since CentOS is (still) binary compatible, many Software developers will accept CentOS as RHEL compatible system and provide you same support as to RHEL customer. If you would install on some other systems, they could deny you full support since your system is not certified for their Application.
On Tue, Nov 1, 2011 at 3:02 AM, Peter Peltonen peter.peltonen@gmail.com wrote:
Hi,
On Tue, Nov 1, 2011 at 10:13 AM, Mathieu Baudier mbaudier@argeo.org wrote:
If absolute 100% binary compatibility is not required, but admin-level compatibility and source-level compatibility with upstream EL is, Scientific Linux is covering that niche, and has their 6.1 out.
But then, CentOS does not give you "absolute 100% binary compatibility" either. No clone distros would (see below).
After installing a previous version of 3rd party SOGo RPM and reporting to the developers that the service wouldn't start after installation, I was informed that the RPM had been compiled on Scientific Linux 6.1 and because of binary incompatibility the RPM did not work under RHEL/CentOS. They recompiled on CentOS and the updated RPM installed/worked fine on my system.
This does not seem like a case of "binary incompatibility" as it is referred to in this thread. For example, if a package is built against a _specific_ version of another package in EL6.1 (let's say, a version of kernel in 6.1), that package will have a compatibility issue with EL6.0 (in this example, kernel in 6.0).
Binary compatibility is indeed a major thing for any clone distros and is nearly impossible to achieve. This is because the build environment is not disclosed by upstream (understandably) and rebuilders must do some guessing or 'trial & error' work. Often times certain versions of packages that were never released are required for the building.
Not all "binary incompatibility" will lead to real world consequences. If, for example, upstream builds a package that links to bogus libraries (that are never used by that package) and the rebuilt package does not have those links, there should not be any problem running it. But in rather rare cases, packages that were not built correctly can result in failure in applications. For example:
http://bugs.centos.org/view.php?id=4964
As you can see, there is yet another item that makes rebuilding not easy: build order. Package A-1.2.3 requires package B-4.5.6. So, package B-4.5.6 must be built _before_ package A. We certainly cannot blame the CentOS devs (nor the QA team!) for this particular instance. It is simply extremely difficult to check every single case like that.
No clone distros, including CentOS and Scientific Linux, are perfect. If someone asks which of the two has a better binary compatibility, I would answer, "they are equally good".
Akemi
On Tue, Nov 1, 2011 at 10:12 AM, Akemi Yagi amyagi@gmail.com wrote:
No clone distros, including CentOS and Scientific Linux, are perfect. If someone asks which of the two has a better binary compatibility, I would answer, "they are equally good".
One of the 'selling points' as a big reason to use open source is that you can fix problems or add features on your own by rebuilding from source. If, in fact, you cannot rebuild a src rpm and get a working copy then in that respect you might as well be using closed, proprietary software.
On Tuesday, November 01, 2011 11:24:24 AM Les Mikesell wrote:
If, in fact, you cannot rebuild a src rpm and get a working copy then in that respect you might as well be using closed, proprietary software.
"Working" and "binary compatible" are two different things, and typically the 100% binary compatibility is most important for precompiled things and for closed source things.
In the SOgo case, a recompile on the target box fixed the issue and resulted in a 'working' binary. But it very possibly would not be 100% compatible with the same exact binary built from the same source code on a slightly different base.
Preventing 100% binary compatible builds and testing is a shot clean across the bow of upstream's two biggest Enterprise Linux competitors, but the CentOS boat got caught in the crossfire.
Nothing in the GPL requires building any particular binary (in terms of compatibility), it just requires access tot he source and the build tools. Well, the build tools are completely free (Koji), it's just the exact set of binaries (for that matter, metadata about those binaries) that is not available for each package.
SL is in fact using the same buildsystem as upstream (Koji) and spent quite a bit of time upfront ramping it up. SL likely doesn't have any better access to upstream's metadata that is critical for binary compatibility testing either.
On Wed, Nov 2, 2011 at 10:35 AM, Lamar Owen lowen@pari.edu wrote:
On Tuesday, November 01, 2011 11:24:24 AM Les Mikesell wrote:
If, in fact, you cannot rebuild a src rpm and get a working copy then in that respect you might as well be using closed, proprietary software.
"Working" and "binary compatible" are two different things, and typically the 100% binary compatibility is most important for precompiled things and for closed source things.
But we are talking about working here.
In the SOgo case, a recompile on the target box fixed the issue and resulted in a 'working' binary. But it very possibly would not be 100% compatible with the same exact binary built from the same source code on a slightly different base.
Try the other way around: build RHEL from their src rpms, try to run the 3rd party binary... I thought you said that didn't work. If you can't rebuild that source so it works, you might as well not use open source.
On Wednesday, November 02, 2011 12:53:29 PM Les Mikesell wrote:
Try the other way around: build RHEL from their src rpms, try to run the 3rd party binary... I thought you said that didn't work. If you can't rebuild that source so it works, you might as well not use open source.
Ok, let me get this straight: you want open source on your OS but don't care about it for third party apps? If you have the third party source, you can rebuild it too. If you're using a closed source third party apps then doing the same thing with the OS shouldn't be a problem.
Nothing in the GPL requires source to be rebuildable so that closed source binary only apps can run unmodified on rebuilt binaries; kindof goes against the spirit of the GPL, no?
On Wed, Nov 2, 2011 at 12:02 PM, Lamar Owen lowen@pari.edu wrote:
On Wednesday, November 02, 2011 12:53:29 PM Les Mikesell wrote:
Try the other way around: build RHEL from their src rpms, try to run the 3rd party binary... I thought you said that didn't work. If you can't rebuild that source so it works, you might as well not use open source.
Ok, let me get this straight: you want open source on your OS but don't care about it for third party apps? If you have the third party source, you can rebuild it too. If you're using a closed source third party apps then doing the same thing with the OS shouldn't be a problem.
I don't care in general, but dislike hypocrisy. If you are going to claim to be open source, it should work to rebuild.
Nothing in the GPL requires source to be rebuildable so that closed source binary only apps can run unmodified on rebuilt binaries; kindof goes against the spirit of the GPL, no?
Errr, what? Working is a yes/no choice. If you can't rebuild so it works, it doesn't work.
On Fri, Oct 21, 2011 at 8:33 AM, Giles Coochey giles@coochey.net wrote:
If not, what do I need to do to get security updates?
These are not production systems, but I don't want to break anything unless it's broken already (i.e. security vulnerabilities and bug fixes).
I think it is best to assume that all software is broken as shipped and the best you can hope for is that it becomes less broken as you update it. If you disagree, look back though the changelogs of a few random packages.
On 10/21/2011 9:23 AM, Johnny Hughes wrote:
On 10/21/2011 06:25 AM, Steve Walsh wrote:
On 10/21/2011 10:16 PM, Ljubomir Ljubojevic wrote:
Vreme: 10/21/2011 12:25 PM, Fajar Priyanto pis(e: As far as I am aware, how I understood official explanation, packages that are introduced in CR repo already PASSED QA testing, but are in limbo because there are issues with building ISO
Nope.
http://wiki.centos.org/AdditionalResources/Repositories/CR
"The continuous release ( CR ) repository makes generally available packages that will appear in the next point release of CentOS, on a testing and *hotfix* basis until formally released. "
"System administrators who choose to opt-in to this process can access the newly built packages, as soon as they are exported from the build system. They are less comprehensively reviewed in the QA validation stage. "
There is SOME QA ... just not all the QA that they get as part of the main release.
They are not right off the build and into the server ... we do our functionality test suite prior to pushing CR (and other tests, and look for repo closure). They are fairly well vetted.
We are trying to serve two masters here ... fast release and fully tested release. CR is the middle of that and a compromise that should work and not break things AND still allow us to do the testing we want for the main release too.
So, you should expect more issues from CR than the main tree ... but the risk should be minimal for any kind of major breakage.
For what its worth, I use CR on the machines I manage in production.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I think many of us would like to see releases in a timely manner. Centos is now months behind in nearly every version with the onset of cent6. I've started moving boxes to ubuntu due to this increasing delay. The security of many machines is now at stake with these continued delays.
Vreme: 10/30/2011 01:36 PM, William Warren piše:
I think many of us would like to see releases in a timely manner. Centos is now months behind in nearly every version with the onset of cent6. I've started moving boxes to ubuntu due to this increasing delay. The security of many machines is now at stake with these continued delays.
What packages EXACTLY have unresolved security fixes??
CentOS team, I think there should be a page with listing of all packages now completed, and the little info like nature of the upstream's fix and/or reason for the delay. This would set the record straight, and ease some of the tension.
On Sun, Oct 30, 2011 at 7:36 AM, William Warren
I think many of us would like to see releases in a timely manner. Centos is now months behind in nearly every version with the onset of cent6. I've started moving boxes to ubuntu due to this increasing delay. The security of many machines is now at stake with these continued delays.
But isn't that the purpose of the CR-repo, to insure that CentOS 6.0 users get the latest security updates in a timely manner?
On Oct 31, 2011, at 1:50 PM, Ron Blizzard wrote:
On Sun, Oct 30, 2011 at 7:36 AM, William Warren
I think many of us would like to see releases in a timely manner. Centos is now months behind in nearly every version with the onset of cent6. I've started moving boxes to ubuntu due to this increasing delay. The security of many machines is now at stake with these continued delays.
But isn't that the purpose of the CR-repo, to insure that CentOS 6.0 users get the latest security updates in a timely manner?
---- No - I think the purpose was to provide updates that fall between releases but given that the 6.1 release hasn't happened, it has assumed the role you suggest, at least at some level.
I too moved on to Ubuntu some 6 or so months ago because I could see that CentOS 6 was going to be a problem.
While I can appreciate that the CentOS are doing what they can do given the parameters they have to work from, I can only see Red Hat killing off their base in order to protect their base.
I'm all for a successful CentOS as I see it just helps the Linux & Red Hat ecosystem to have them successfully re-spin the upstream product.
Craig
On 10/21/2011 6:22 AM, Steve Walsh wrote:
Except.
If you have a 6.0 machine, and enable the cr/ repo, then you don't just get the 6.0 updates. You get most of the post-6.0 updates, plus what's been built for 6.1 (effectively still in QA), plus some post 6.1 updates (Again, still in QA). As far as I'm aware, there's now way to say "Just give me the 6.0 updates you have" when using the cr/ repo.
I am more than happy to be corrected on this operation of the cr repo tho, as I've held off on updating boxes with the cr/ repo so as not to get "untested" updates.
If you just want the 6.0 updates, then don't use the CR repo. The CR repo is explicitly for early access to packages that have been built for 6.1. There are no more 6.0 updates.
On 10/20/2011 01:47 PM, m.roth@5-cent.us wrote:
Jerry Geis wrote:
Hi gang - Love CentOS - you guys to a fabulous job.
It has been a while since I saw any update... I went to twitter.com/centos nothing there, twitter.com/centos6 nothing there, went to the qa calendar stuff nothing there.
Last I saw was something in September saying all RPM's are built and doing ISO's. Then nothing.
Oddly enough, my manager just walked in a couple hours ago, and asked me why I thought there hadn't been any updates to our 6.0 boxen.
Everything's being rolled into the CR repo, so there do not appear to be any "ordinary" 6.0 updates.
mark, annoyed, and having to install 300+ package updates to the 6.0 systems, and hope nothing breaks*
- On the other hand, maybe I'll see annoyance fixes, like Pidgen, that
pops *under* other windows, the quirky screen handling in rxvt, and, oh yes, the "yes" buttons lack of attention after I click "logout" from the menu.
Is there a package for the cr repo? I don't see anything like that when I do a yum repolist all.
Thanks,
On 21.10.2011 13:00, Steve Clark wrote:
On 10/20/2011 01:47 PM, m.roth@5-cent.us wrote:
Jerry Geis wrote:
Hi gang - Love CentOS - you guys to a fabulous job.
It has been a while since I saw any update... I went to twitter.com/centos nothing there, twitter.com/centos6 nothing there, went to the qa calendar stuff nothing there.
Last I saw was something in September saying all RPM's are built and doing ISO's. Then nothing.
Oddly enough, my manager just walked in a couple hours ago, and asked me why I thought there hadn't been any updates to our 6.0 boxen.
Everything's being rolled into the CR repo, so there do not appear to be any "ordinary" 6.0 updates.
mark, annoyed, and having to install 300+ package updates to the 6.0 systems, and hope nothing breaks*
- On the other hand, maybe I'll see annoyance fixes, like Pidgen, that
pops *under* other windows, the quirky screen handling in rxvt, and, oh yes, the "yes" buttons lack of attention after I click "logout" from the menu.
Is there a package for the cr repo? I don't see anything like that when I do a yum repolist all.
Thanks,
Hi,
yes. It is in the extras repo: centos-release-cr
Best Regards Patrick
----- "Steve Clark" sclark@netwolves.com escreveu:
De: "Steve Clark" sclark@netwolves.com Para: "CentOS mailing list" centos@centos.org Enviadas: Sexta-feira, 21 de Outubro de 2011 9:00:00 (GMT-0300) Auto-Detected Assunto: Re: [CentOS] What happened to 6.1
Is there a package for the cr repo? I don't see anything like that when I do a yum repolist all.
Yep, there is a package... but it is on the CR repo:
ftp://(some.centos.mirror)/CentOS/6/cr/x86_64/RPMS/centos-release-cr-6-0.el6.centos.x86_64.rpm
Install it :D
Vreme: 10/21/2011 01:07 PM, Antonio da Silva Martins Junior piše:
----- "Steve Clark"sclark@netwolves.com escreveu:
De: "Steve Clark"sclark@netwolves.com Para: "CentOS mailing list"centos@centos.org Enviadas: Sexta-feira, 21 de Outubro de 2011 9:00:00 (GMT-0300) Auto-Detected Assunto: Re: [CentOS] What happened to 6.1
Is there a package for the cr repo? I don't see anything like that when I do a yum repolist all.
Yep, there is a package... but it is on the CR repo:
ftp://(some.centos.mirror)/CentOS/6/cr/x86_64/RPMS/centos-release-cr-6-0.el6.centos.x86_64.rpm Install it :D
Same package is also i Extras repo contained in main yum repo file (CentOS-Base.repo). It should be turned ON by default, so simple
"yum install centos-release-cr -y"
should be enough.
I did not mean to "stir" up anything.
I was simply asking if I was looking in the wrong place for an update to 6.1 or where are the ISO's?
I cannot find anything out there as far as an update.
Thanks
Jerry
Vreme: 10/30/2011 12:31 AM, Jerry Geis piše:
I did not mean to "stir" up anything.
I was simply asking if I was looking in the wrong place for an update to 6.1 or where are the ISO's?
I cannot find anything out there as far as an update.
Thanks
Jerry
Sorry to be blunt, but you are not Less (Mikesell), you are Jerry, so it was not directed at you at all.
All packages are not ready yet, ergo nor are the ISO's. But there is CR repository and most of us use it to get as close to 6.1 as possible. Many problems with 6.0 are already solved with CR repo, so I am happy.
On Saturday, October 29, 2011 06:31:46 PM Jerry Geis wrote:
I cannot find anything out there as far as an update.
This has been a useful discourse since the new difficulties that the team is facing are now more widely known. Sometimes the pot needs a good stirring, and this time we got what is to me a useful update.
As to getting updated packages, I'm finding CR is working quite well, but I think that's not the kind of update you were referring to, you were referring to more of a 'status' report (you said as much in your thread starter).
As to status, if you can spare a VM or a physical box with C6 on it you can enable the CR repository by installing the CR release package, and then you can cron a yum update and see packages updating (or mirror the repo and see the changes). When the contents of CR *goes away* after being active for a while, the next point release is out and CR's function is done for that point release cycle. You can leave it enabled or mirroring, and when you start seeing packages go into CR you'll know the next point release is being built. Lather, rinse, and repeat as necessary.
I've come to the conclusion that the packages themselves are going to have to suffice for me for a status report, and just assume the team is working on it. If nothing shows up for a long time, then there are alternatives. A status report won't change that. And it may be that my centos-announce subscriptions need to be modified to add more options.....
-
Akemi Yagi -
Antonio da Silva Martins Junior -
Bowie Bailey -
Brian Mathis -
Christopher Chan -
Craig White -
Craig White -
Dennis Jacobfeuerborn -
Fajar Priyanto -
Gary Greene -
Giles Coochey -
Jerry Geis -
John R Pierce -
Johnny Hughes -
Johnny Hughes -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Marko Vojinovic -
Mathieu Baudier -
Ned Slider -
Nicolas Thierry-Mieg -
Patrick Hurrelmann -
Patrick Lists -
Paul Heinlein -
Peter Peltonen -
R P Herrold -
Ron Blizzard -
Steve Clark -
Steve Walsh -
Tom Bishop -
William Warren