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.
On 10/21/2011 06:36 AM, Johnny Hughes wrote:> On 10/21/2011 06:16 AM, Ljubomir Ljubojevic wrote: >> Vreme: 10/21/2011 12:25 PM, Fajar Priyanto pi?e: >>> On Fri, Oct 21, 2011 at 6:22 PM, Steve Walsh<steve at 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. >> > > This is somewhat true ... there is some QA performed on the CR packages. > There is "MORE" QA performed on them as part of the release process > though. So, they are not "totally untested" ... just less tested than > the main release. > > Obviously that means there is an "increased chance" that the CR packages > are not totally correct, as compared to released packages, because there > is somewhat less QA at that (the CR) stage ... but they SHOULD be > correct and they SHOULD work. > > We added CR so that we can provide updates faster ... it is totally > optional, but does provide more user choice. What to use is up to you. > I personally "DO" use CR on the machines that I manage. > >>> >>> 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/ >> >> > > we don't have a CR repo for centosplus ... and I do not see us creating > one. We are building and testing the plus kernels too and they will be > there on release of 6.1 ... or you can use the ones from toracat's repo. >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20111021/745cc6ab/attachment-0003.sig>
Vreme: 10/21/2011 03:09 PM, Johnny Hughes pi?e:>> we don't have a CR repo for centosplus ... and I do not see us creating >> one. We are building and testing the plus kernels too and they will be >> there on release of 6.1 ... or you can use the ones from toracat's repo. >>OK, thanks. I already set up mrepo to pull them from toracat repo. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant
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 Friday, October 28, 2011 11:29:52 AM Les Mikesell wrote:> On Fri, Oct 28, 2011 at 10:20 AM, Lamar Owen <lowen at 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.
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
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.....
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.
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 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?