Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

Hi, Dag!!

Haven't seen you since that London Linux conference, I'm back in the USA now.

On Fri, Jun 20, 2014 at 5:14 PM, Dag Wieers  wrote:

> Self-criticism (and yes, I feel part of Red Hat's community) is essential.
> And a decision that makes Red Hat weaker, weakens my case as well.

It's also contributing to skepticism from companies and users looking
at RHEL 7 or the clone rebuilds. If we're all stuck rebuilding from
CentOS, not from RHEL signed packages that are verifiably consistent
with what our favorite upstream vendor actually packages and tests,
that's a logical source of security and support concern.

What makes it worse is that HTTPS is not sufficiently secure to verify
the authenticity of original source code, and the git repo itself
could be hijacked by any subtle attacker using any of the unrevoked,
stolen SSL wildcard keys in the wild. That could be a fascinating
security hole for 3rd party vendors who rely on RHEL or CentOS SRPM's
for their source code for or open source based projects. These include
Centrify, that rebundles OpenSSH with various features, and apparently
Cisco for their ASA firewall products.

> With al due respect, but your response to one point of criticism is probably
> why someone at Red Hat (unless maybe high up in the organization) may not
> speak up. It clearly is a management/legal decision and yes, I do believe if
> you are on the payroll, that is exactly what you are not supposed to
> question. Red Hat becoming less Open Source may harm the company's public
> image.

Dag, I beg to differ with you here. My experience with Red Hat
technical personnel on an individual basis is that they will
*question* policies, but that they are quite aware that their voice is
not authoritative and are cautious about saying "this is the way it
is, because I work for Red Hat and that's the policy". They're leave
it to the legal and management personnel, who may also be aware of
things they're not privy to (such as software licensing agreeements
with Sun, back in the day.)

> And since the CentOS board is on Red Hat's payroll as well, I think they are
> in the same boat, unfortunately.

Yeah, I've been urging my clients to switch to Scientific Linux where
possible for a stack of reasons. If we, or our friends on the SL build
team, can work around this, it'll be another reason to switch. The
decision  to switch to pure git based distribution is, currently, rife
with security and implementation issues. That it was done effectively
unannounced, without testing it with the RHEL 7 beta components is a
sign of a problem.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Dag Wieers]

On Fri, 20 Jun 2014, Jamie Duncan wrote:


I'm not worried at all if you have a license or not. I'm not your sales
rep. :)

The way the comment read didn't sit with me well. It sounded dismissive to
a lot of work that Red Hatters do for upstream communities all over that
allow RHEL, RHEL derivitaves and all other forms of Linux to happen. Not
just the kernel, but the un-sexy bits in the middle that make an OS usable.


So if I don't agree, or am critical about something Red Hat did, I am 
dismissive to Red Hat's contributions ? Sorry, but that is not true at 
all. In this complex world, I think one is allowed to criticize one action 
without implying everything else...


Self-criticism (and yes, I feel part of Red Hat's community) is essential. 
And a decision that makes Red Hat weaker, weakens my case as well.




I also can't agree with the the thought that Red Hatters won't dissent
against company decisions that they don't agree with. I'm not going to dig
through the world archives this late on a Friday but I just don't accept
that assumption. Of course I'm a fanboy and an employee. But I'm those
things because I believe in how we try to do things. We don't always get it
right (see RHEV 1.0 and other debacles). But we try to.


With al due respect, but your response to one point of criticism is 
probably why someone at Red Hat (unless maybe high up in the organization) 
may not speak up. It clearly is a management/legal decision and yes, I do 
believe if you are on the payroll, that is exactly what you are not 
supposed to question. Red Hat becoming less Open Source may harm the 
company's public image.


And since the CentOS board is on Red Hat's payroll as well, I think they 
are in the same boat, unfortunately.


--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Jamie Duncan]

I'm not worried at all if you have a license or not. I'm not your sales
rep. :)

The way the comment read didn't sit with me well. It sounded dismissive to
a lot of work that Red Hatters do for upstream communities all over that
allow RHEL, RHEL derivitaves and all other forms of Linux to happen. Not
just the kernel, but the un-sexy bits in the middle that make an OS usable.

I also can't agree with the the thought that Red Hatters won't dissent
against company decisions that they don't agree with. I'm not going to dig
through the world archives this late on a Friday but I just don't accept
that assumption. Of course I'm a fanboy and an employee. But I'm those
things because I believe in how we try to do things. We don't always get it
right (see RHEV 1.0 and other debacles). But we try to.

Have a good weekend.

-jduncan


On Fri, Jun 20, 2014 at 3:07 PM, Dag Wieers  wrote:

> On Fri, 20 Jun 2014, Mark Stodola wrote:
>
>  On 06/20/2014 08:55 AM, Dag Wieers wrote:
>>
>>>  On Fri, 20 Jun 2014, Lamar Owen wrote:
>>>
>>> >  On 06/20/2014 03:55 AM, Dag Wieers wrote:
>>> > > > >   It may have become a legal question now that the SRPMs are no
>>> longer
>>> > >   available from ftp.redhat.com. That in itself is an unwelcome
>>> change.
>>> > >  It is an unfortunate change, yes, but I prefer to give Red Hat the
>>> >  benefit of the doubt as far as motivations go, since they could close
>>> >  it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's
>>> >  Fedora, so it doesn't count).  And SuSE is completely within its
>>> >  rights under GPL to do how they are doing; this is not a jab against
>>> >  SuSE, since SuSE has also done and is doing a lot of great work for
>>> >  open source.  (Of course, since I haven't looked for publicly posted
>>> >  source for SLES in a while, they may have posted it since I last
>>> >  looked and I just don't know about it.)
>>>
>>>  I am glad you agree that Red Hat now moving closer to what SuSE is doing
>>>  is unfortunate and not welcomed by the community(*).
>>>
>>>  (*) Where community in my definition excludes people on Red Hat's
>>>  payroll ;-)
>>>
>>
>> Although this discussion seems interesting, I see the same points being
>> reiterated.  I don't see how any of this is going to change anything
>> though. RedHat and CentOS are moving forward whether we like it or not and
>> the SL development team are doing what they can within those constraints.
>>  If one needs all that integrity and vetting of the source, go fork over
>> the money for a license.
>>
>
> I have a license, don't worry. I am a Red Hat customer. But of course, one
> license will not do. You need a bunch of entitlements to get access to all
> channels. And on a yearly basis too. HA, RHSCL, ...
>
> For only accessing the SRPMs and rebuilding it adds up quickly.
>
>
> --
> -- dag wieers, d...@wieers.com, http://dag.wieers.com/
> -- dagit linux solutions, cont...@dagit.net, http://dagit.net/
>
> [Any errors in spelling, tact or fact are transmission errors]
>



-- 
Thanks,

Jamie Duncan
@jamieeduncan

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Dag Wieers]

On Fri, 20 Jun 2014, Mark Stodola wrote:


On 06/20/2014 08:55 AM, Dag Wieers wrote:

 On Fri, 20 Jun 2014, Lamar Owen wrote:

>  On 06/20/2014 03:55 AM, Dag Wieers wrote:
> > 
> >   It may have become a legal question now that the SRPMs are no longer

> >   available from ftp.redhat.com. That in itself is an unwelcome change.
> 
>  It is an unfortunate change, yes, but I prefer to give Red Hat the

>  benefit of the doubt as far as motivations go, since they could close
>  it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's
>  Fedora, so it doesn't count).  And SuSE is completely within its
>  rights under GPL to do how they are doing; this is not a jab against
>  SuSE, since SuSE has also done and is doing a lot of great work for
>  open source.  (Of course, since I haven't looked for publicly posted
>  source for SLES in a while, they may have posted it since I last
>  looked and I just don't know about it.)

 I am glad you agree that Red Hat now moving closer to what SuSE is doing
 is unfortunate and not welcomed by the community(*).

 (*) Where community in my definition excludes people on Red Hat's
 payroll ;-)


Although this discussion seems interesting, I see the same points being 
reiterated.  I don't see how any of this is going to change anything though. 
RedHat and CentOS are moving forward whether we like it or not and the SL 
development team are doing what they can within those constraints.  If one 
needs all that integrity and vetting of the source, go fork over the money 
for a license.


I have a license, don't worry. I am a Red Hat customer. But of course, one 
license will not do. You need a bunch of entitlements to get access to all 
channels. And on a yearly basis too. HA, RHSCL, ...


For only accessing the SRPMs and rebuilding it adds up quickly.

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/20/2014 09:45 AM, Andras Horvath wrote:

Regarding the license: I am more than certain that if I happen to buy 
supscription to RHEL then I am allowed to do with the GPL'd sources 
whatever I want while it is between the boundaries of the GPL. 


And Red Hat has reserved the right to not distribute updates to you if 
you breach the terms of their subscription agreement (it's in their 
agreement; if you don't like it, don't agree to it or take them to court 
over it).  It's a matter of interpretation and opinion as to whether the 
act of cutting off updates constitutes 'restrictions on source code 
redistribution,' since that has not been tested in court as yet.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Mark Stodola]

On 06/20/2014 08:55 AM, Dag Wieers wrote:

On Fri, 20 Jun 2014, Lamar Owen wrote:


On 06/20/2014 03:55 AM, Dag Wieers wrote:


 It may have become a legal question now that the SRPMs are no longer
 available from ftp.redhat.com. That in itself is an unwelcome change.


It is an unfortunate change, yes, but I prefer to give Red Hat the
benefit of the doubt as far as motivations go, since they could close
it up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's
Fedora, so it doesn't count).  And SuSE is completely within its
rights under GPL to do how they are doing; this is not a jab against
SuSE, since SuSE has also done and is doing a lot of great work for
open source.  (Of course, since I haven't looked for publicly posted
source for SLES in a while, they may have posted it since I last
looked and I just don't know about it.)


I am glad you agree that Red Hat now moving closer to what SuSE is doing
is unfortunate and not welcomed by the community(*).

(*) Where community in my definition excludes people on Red Hat's
payroll ;-)



Although this discussion seems interesting, I see the same points being 
reiterated.  I don't see how any of this is going to change anything 
though.  RedHat and CentOS are moving forward whether we like it or not 
and the SL development team are doing what they can within those 
constraints.  If one needs all that integrity and vetting of the source, 
go fork over the money for a license.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Dag Wieers]

On Fri, 20 Jun 2014, Lamar Owen wrote:


On 06/20/2014 03:55 AM, Dag Wieers wrote:


 It may have become a legal question now that the SRPMs are no longer
 available from ftp.redhat.com. That in itself is an unwelcome change.


It is an unfortunate change, yes, but I prefer to give Red Hat the benefit of 
the doubt as far as motivations go, since they could close it up completely 
like SuSE has with SLES and SLED (OpenSuSE is SuSE's Fedora, so it doesn't 
count).  And SuSE is completely within its rights under GPL to do how they 
are doing; this is not a jab against SuSE, since SuSE has also done and is 
doing a lot of great work for open source.  (Of course, since I haven't 
looked for publicly posted source for SLES in a while, they may have posted 
it since I last looked and I just don't know about it.)


I am glad you agree that Red Hat now moving closer to what SuSE is doing 
is unfortunate and not welcomed by the community(*).


(*) Where community in my definition excludes people on Red Hat's payroll ;-)

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Andras Horvath]

On Fri, 20 Jun 2014 09:16:14 -0400
Lamar Owen  wrote:

> On 06/20/2014 03:55 AM, Dag Wieers wrote:
> >
> > It may have become a legal question now that the SRPMs are no longer 
> > available from ftp.redhat.com. That in itself is an unwelcome change.
> >
> 
> GPL does not require sources to be released to the public; the 
> requirement is to release sources to the same people to whom you 
> distributed the binaries (and of the same version).  The GPL FAQ covers 
> this pretty well.  I'm well aware of both sides to this issue, and I 
> sympathize both with the enterprise linux distributors wanting to stay 
> in business in a competitive climate as well as the larger community 
> wanting to have open rebuilds of those enterprise distributions.
> 
> It is an unfortunate change, yes, but I prefer to give Red Hat the 
> benefit of the doubt as far as motivations go, since they could close it 
> up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's 
> Fedora, so it doesn't count).  And SuSE is completely within its rights 
> under GPL to do how they are doing; this is not a jab against SuSE, 
> since SuSE has also done and is doing a lot of great work for open 
> source.  (Of course, since I haven't looked for publicly posted source 
> for SLES in a while, they may have posted it since I last looked and I 
> just don't know about it.)


Simply I cannot see the point you're making here. Excuse me but as I see, 
you're not coming up with any solution but only saying that this is more than 
alright. But without pointing out its advantage over the former method. You 
yourself is saying too that there is a gap between RH's release of the sources 
and their import to the git tree.

Regarding the license: I am more than certain that if I happen to buy 
supscription to RHEL then I am allowed to do with the GPL'd sources whatever I 
want while it is between the boundaries of the GPL. It may easily be because 
I'm not an expert in licence matter, but I cannot come up with an idea how the 
license could be changed by any lawyers, for example, forbidding the 
redistribution of the sources. Is that really possible? If so, then could you 
provide background info or facts on the matter how that is done?

Thank you.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/20/2014 03:55 AM, Dag Wieers wrote:


It may have become a legal question now that the SRPMs are no longer 
available from ftp.redhat.com. That in itself is an unwelcome change.




GPL does not require sources to be released to the public; the 
requirement is to release sources to the same people to whom you 
distributed the binaries (and of the same version).  The GPL FAQ covers 
this pretty well.  I'm well aware of both sides to this issue, and I 
sympathize both with the enterprise linux distributors wanting to stay 
in business in a competitive climate as well as the larger community 
wanting to have open rebuilds of those enterprise distributions.


It is an unfortunate change, yes, but I prefer to give Red Hat the 
benefit of the doubt as far as motivations go, since they could close it 
up completely like SuSE has with SLES and SLED (OpenSuSE is SuSE's 
Fedora, so it doesn't count).  And SuSE is completely within its rights 
under GPL to do how they are doing; this is not a jab against SuSE, 
since SuSE has also done and is doing a lot of great work for open 
source.  (Of course, since I haven't looked for publicly posted source 
for SLES in a while, they may have posted it since I last looked and I 
just don't know about it.)

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

[A very well-reasoned reply, and I thank you.  Comments in-line.]

On 06/20/2014 08:20 AM, Nico Kadel-Garcia wrote:
There are a stack of ways to do this, some less reliable than others. 
They're not clearly making "git clones" of the upstream RHEL git 
repository. there is some kind of "import" of the files happening. If 
they're simply unpacking the SRPM's and importing those, cool. 


I too would like a bit more info from Red Hat on this mechanism. They 
don't actually have to provide that info, but it certainly would be nice 
to have.  It would seem easiest to automate either a depackaging of each 
SRPM and import, or a direct importing from the to-be-packaged contents 
of the SRPM prior to writing it out (and signing).  But that is an 
assumption that may or may not be accurate.


But import/export procedures with git are prone to fascinating 
discrepancies, some from user error, It creates fascinating risks, and 
without a carefully comparison toolkit that compares either RHEL 
SRPM's to git.centos.org's unstated and thus unpredictable layout, or 
someone with git access to both running "git diff" between the repos, 
it's a small but very real risk of fascinating discrepancies. I'm 
afraid that the only way to get a valid, reliable, and *signed* set of 
source code is going to be to buy subscriptions. 


GPL doesn't require distributed source to be signed, but your final line 
is probably a correct statement.  Although with your fascinating use of 
fascinating in that paragraph, I have to wonder if you've recently 
watched a Star Trek marathon or something. :-)


And I'm curious as to those cases, specifically some documentation of 
some of the issues involved.  Lots of large projects, including the 
linux kernel, use git, and those artifacts should be (and probably are) 
well documented.  I am not a git guru, by any stretch, but I am curious.


I'm fairly shocked: it puts all git clones of git.centos.org material 
at risk of unauthorized modification and pollution of the source code 
for people trying to build from them. 


This is where the git design should help; no modification can go 
unnoticed, thanks to the manner in which the commit ID's are 
calculated.  The gap is between Red Hat's build process and the import 
of the sources for that process into git.  Once in git, all changes will 
be tracked.


There's no way, as things stand, to tell which is the "vendor" version 
nor which is the "centos build" version of the code in git.centos.org. 


While I may be misunderstanding the script, SL devs are contributing 
scripts that look to be able to do this discernment.


There's not even a tag or branch to indicate it, just a "master" on 
which changes are accumulating. 


There is no content in master.  The EL7 content is in the c7 branch.

And it's already gotten polluted. Is the new "centos-git-common" 
repository part of the official RHEL releases? I think not, but it's 
in the same environment that formerly contained purely RHEL code. How 
can we tell future such packages apart?


Commit IDs and the committer name seem to be the only way at present.

SL did this very well, with the separate "sl6" and "vendors" 
directories for SRPM's from Scientific Linux, and tools from upstream 
vendors like Red Hat. A similar separation would have been very 
welcome at www.centos.org, but somehow, I don't see them resetting the 
URL's in all their working git clones. 
Yes, it would be welcome to have more traditional separation, but it 
appears that will not happen.  I do reserve the right to be wrong, of 
course.


And I again thank you for a well-reasoned and level response.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

On Thu, Jun 19, 2014 at 9:47 AM, Lamar Owen  wrote:
> On 06/19/2014 09:16 AM, Nico Kadel-Garcia wrote:
>>
>> Take a look at even a simple SPEC file, such as "ntp.spec" to see how much
>> interpretation it's doing.
>
>
> Oh, I'm well aware of that.
>
>> Relying on the upstream authors to always do the .spec files *last* with
>> new builds is not necessarily fair, and precludes certain type of code
>> merges.
>
>
> While I have no knowledge of the actual workflow at Red Hat, I would think
> that the population into git.centos.org would happen as an automated part of
> the upstream build process, and that what is going in to git.centos.org is
> what rpmbuild is seeing as it builds the 'canonical' upstream package (or
> it's being generated by depackaging the built SRPM).  This would just about
> have to be true in order for the git.centos.org source to be the actual
> upstream source.  Anyone with a valid subscription should be able to verify
> this for themselves by comparing the git committed source bundle with the
> subscription access SRPM.

There are a stack of ways to do this, some less reliable than others.
They're not clearly making "git clones" of the upstream RHEL git
repository. there is some kind of "import" of the files happening. If
they're simply unpacking the SRPM's and importing those, cool. But
import/export procedures with git are prone to fascinating
discrepancies, some from user error, It creates fascinating risks, and
without a carefully comparison toolkit that compares either RHEL
SRPM's to git.centos.org's unstated and thus unpredictable layout, or
someone with git access to both running "git diff" between the repos,
it's a small but very real risk of fascinating discrepancies.

I'm afraid that the only way to get a valid, reliable, and *signed*
set of source code is going to be to buy subscriptions.

> This allows excellent change tracking with git (which many many people have
> asked for from CentOS in the past) while still getting the upstream source.

See above. The careful tracking of upstream is happening out of view.

> Of course, it is a bit of a leap of faith to trust Red Hat to do it this
> way; but, then again, unless you have (or had) a valid subscription you
> couldn't verify that the source RPMs going into ftp.redhat.com were the same
> as what subscribers were getting (in terms of package metadata, and even
> perhaps a different signing key.etc).  IMHO, if you don't trust Red Hat

But at least they had a GPG signature, from Red Hat, saying "we
published this". That signature is still present when I hand you a
copy of the SRPM or put it in a local mirror or get it from Scientific
Linux's vendor mirror. git.centos.org has no GPG tags, not even on
their initial imports. I'm fairly shocked: it puts all git clones of
git.centos.org material at risk of unauthorized modification and
pollution of the source code for people trying to build from them.

> to put the correct source into git.centos.org then why trust their source at
> all?  The git commit ID's will take care of detecting side-channel
> modifications after Red Hat's populating of the source. (Side note: Linus'
> choice of the way commit ID's were to work is absolutely brilliant.  IMHO).
>
> But I'm curious as to what kind of merge would work with a depackaged source
> RPM but not with the files available through git.centos.org.

There's no way, as things stand, to tell which is the "vendor" version
nor which is the "centos build" version of the code in git.centos.org.
There's not even a tag or branch to indicate it, just a "master" on
which changes are accumulating. And it's already gotten polluted. Is
the new "centos-git-common" repository part of the official RHEL
releases? I think not, but it's in the same environment that formerly
contained purely RHEL code. How can we tell future such packages
apart?

SL did this very well, with the separate "sl6" and "vendors"
directories for SRPM's from Scientific Linux, and tools from upstream
vendors like Red Hat. A similar separation would have been very
welcome at www.centos.org, but somehow, I don't see them resetting the
URL's in all their working git clones.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Dag Wieers]

On Thu, 19 Jun 2014, Lamar Owen wrote:


On 06/19/2014 11:47 AM, Patrick J. LoPresti wrote:

 I do not care what any lawyer has to say on this topic, because this is
 not a legal question. 


Sure it is.


It may have become a legal question now that the SRPMs are no longer 
available from ftp.redhat.com. That in itself is an unwelcome change.


--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/19/2014 02:05 PM, Yasha Karant wrote:

The bottom line to this issue seems to have two parts:


Pretty good distillation.  Comments in-line.



1.  Is it feasible with the same personnel resources and hardware 
computational resources to acquire and build current, maintained SL 7 
from the current, maintained RHEL 7 production source? 


If you can accept that the incoming commits to git.centos.org, per Red 
Hat's statement in bugzilla.r.c, are the 'RHEL 7 production sources,' 
then yes, it is possible, and the work is progressing.  If you're 
talking about the source RPMs that are currently only available to 
subscribers, then, no, it's not possible at this time.


Note this query also means to keep SL 7 production (sl7x) as current 
as RHEL 7 production, except for the (hopefully short) delay from the 
time RH releases production source updates/enhancements to the time SL 
can release the same as installable RPMs.


Looking at the many repositories in git.centos.org, it appears that they 
are being updated; as I don't have a production RHEL7 system with which 
to compare, I have insufficient data with which to comment on how timely 
those commits are or are not.  Time will tell.




2.  Is it verifiable, not just on a claim of trust, that the 
production source from which SL 7 (and 8 and ... ) is built is the 
same production source used for the commercial for-profit RH supported 
RHEL 7 RPM distribution? 


If you have an RHEL subscription you can verify this for yourself by 
comparing the source RPMs from the subscription to the sources committed 
to git.centos.org.


This latter statement is the basis for the validity of open source -- 
the source can be inspected (audited, if necessary), and the two 
sources compared. If this cannot be verified, then we do not know how 
CentOS, SL, etc., differ from RHEL (other than trivial logos and the 
like), and what software defects exist that are not present in RHEL.


This is the sticky wicket, isn't it?  The fact of the matter is that 
RHEL source only has to be directly distributed to subscribers who have 
been distributed a copy of the binaries.  We've trusted Red Hat to 
populate ftp.redhat.com with the correct sources (without independent 
verification against subscription source RPMs) in the past; this is a 
change of delivery method, for sure, and will require some adjustments 
on our part.  However, I would like to point out something, using the 
output of a whois:


[lowen@dhcp-pool107 ~]$ whois centos.org
[Querying whois.publicinterestregistry.net]
[whois.publicinterestregistry.net]
Domain Name:CENTOS.ORG
Domain ID: D103409469-LROR
Creation Date: 2003-12-04T12:28:30Z
Updated Date: 2014-06-18T07:43:39Z
Registry Expiry Date: 2015-12-04T12:28:30Z
Sponsoring Registrar:Nom-iq Ltd. dba COM LAUDE (R1772-LROR)
Sponsoring Registrar IANA ID: 470
WHOIS Server:
Referral URL:
Domain Status: clientDeleteProhibited
Domain Status: clientUpdateProhibited
Domain Status: serverTransferProhibited
Domain Status: transferPeriod
Registrant ID:COMLDE-011441
Registrant Name:Red Hat, Inc.
Registrant Organization:Red Hat, Inc.
Registrant Street: 100 East Davie Street
Registrant City:Raleigh
Registrant State/Province:NC
Registrant Postal Code:27601
Registrant Country:US
Registrant Phone:+1.9197543700
Registrant Phone Ext:
Registrant Fax: +1.9197543704
Registrant Fax Ext:
Registrant Email:domainad...@redhat.com
.

If anyone was uncomfortable about a centos.org domain machine holding 
Red Hat sources, well, Red Hat is the registrant of the centos.org domain.


Hope that helps.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Yasha Karant]

The bottom line to this issue seems to have two parts:

1.  Is it feasible with the same personnel resources and hardware 
computational resources to acquire and build current, maintained SL 7 
from the current, maintained RHEL 7 production source?  Note this query 
also means to keep SL 7 production (sl7x) as current as RHEL 7 
production, except for the (hopefully short) delay from the time RH 
releases production source updates/enhancements to the time SL can 
release the same as installable RPMs.


2.  Is it verifiable, not just on a claim of trust, that the production 
source from which SL 7 (and 8 and ... ) is built is the same production 
source used for the commercial for-profit RH supported RHEL 7 RPM 
distribution?  This latter statement is the basis for the validity of 
open source -- the source can be inspected (audited, if necessary), and 
the two sources compared. If this cannot be verified, then we do not 
know how CentOS, SL, etc., differ from RHEL (other than trivial logos 
and the like), and what software defects exist that are not present in RHEL.


Yasha Karant

On 06/19/2014 10:27 AM, Lamar Owen wrote:

On 06/19/2014 11:47 AM, Patrick J. LoPresti wrote:
I do not care what any lawyer has to say on this topic, because this 
is not a legal question. 


Sure it is.

Absolutely everyone reading this, including you, knows full well that 
the intent of the GPL -- indeed, its entire purpose -- is to enable 
precisely the kind of effort performed by the Scientific Linux 
maintainers _without undue burden_. 


The release of source code the way Red Hat is currently releasing that 
source code is fully within the spirit of the GPL, at least in my 
opinion.


Building packages out of git isn't really that much harder than 
setting up mock to build from a directory full of source RPMS (I've 
done this for EL5 on IA64, by they way, and it's not exactly easy to 
do, either); it's just different, and there is and will be a learning 
curve.  The CentOS team has a publicly accessible QA tree out there 
already for testing-only purposes.  The issue with the lack of 
signatures is not a GPL compliance problem; GPL requires modified 
sources to be released, but it has never required that release to be 
signed.


Would I like things to be the way they were when Red Hat Linux 7 was 
still named after a city (not RHEL 7; RHL 7, back before the turn of 
the century)?  In some ways yes; in other ways no.


On the bright side, the flurry of effort and collaboration is 
downright refreshing.  It almost makes me want to jump in and maintain 
something again almost.  I did that for five years, ten years ago, 
and still get e-mails demanding that I fix something for free


If some shyster finds some nuanced loophole that allows his employer 
to thwart this purpose, that says a lot more about the shyster and 
the employer than it does about the GPL. - Pat 


Again I ask you to point me to a publicly accessible download repo of 
current SLES source RPMs.  Now ask yourself why SLES source is hard to 
find relative to RHEL source.


Now, the Red Hat model is really pretty simple: you could, if you want 
to and have a current RHEL subscription, download all the current 
GPL-covered source RPMs of EL7 and post them to a public server and be 
within your rights granted by the GPL.  But Red Hat can remove your 
access to updates if you do so (GPL doesn't give you the automatic 
right to receive future versions of source from your current version 
of the binary;  you only have the guarantee to the version of the 
source that matches the version of the binary that you received).  
Nothing in the GPL requires the one who distributes the binary to 
provide public access to the sources, either; only the person(s) to 
whom the binaries are distributed have the right to demand source from 
the distributor (and only for the version of those binaries that they 
possess).


But namecalling isn't really necessary, is it?

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/19/2014 11:47 AM, Patrick J. LoPresti wrote:
I do not care what any lawyer has to say on this topic, because this 
is not a legal question. 


Sure it is.

Absolutely everyone reading this, including you, knows full well that 
the intent of the GPL -- indeed, its entire purpose -- is to enable 
precisely the kind of effort performed by the Scientific Linux 
maintainers _without undue burden_. 


The release of source code the way Red Hat is currently releasing that 
source code is fully within the spirit of the GPL, at least in my opinion.


Building packages out of git isn't really that much harder than setting 
up mock to build from a directory full of source RPMS (I've done this 
for EL5 on IA64, by they way, and it's not exactly easy to do, either); 
it's just different, and there is and will be a learning curve.  The 
CentOS team has a publicly accessible QA tree out there already for 
testing-only purposes.  The issue with the lack of signatures is not a 
GPL compliance problem; GPL requires modified sources to be released, 
but it has never required that release to be signed.


Would I like things to be the way they were when Red Hat Linux 7 was 
still named after a city (not RHEL 7; RHL 7, back before the turn of the 
century)?  In some ways yes; in other ways no.


On the bright side, the flurry of effort and collaboration is downright 
refreshing.  It almost makes me want to jump in and maintain something 
again almost.  I did that for five years, ten years ago, and still 
get e-mails demanding that I fix something for free


If some shyster finds some nuanced loophole that allows his employer 
to thwart this purpose, that says a lot more about the shyster and the 
employer than it does about the GPL. - Pat 


Again I ask you to point me to a publicly accessible download repo of 
current SLES source RPMs.  Now ask yourself why SLES source is hard to 
find relative to RHEL source.


Now, the Red Hat model is really pretty simple: you could, if you want 
to and have a current RHEL subscription, download all the current 
GPL-covered source RPMs of EL7 and post them to a public server and be 
within your rights granted by the GPL.  But Red Hat can remove your 
access to updates if you do so (GPL doesn't give you the automatic right 
to receive future versions of source from your current version of the 
binary;  you only have the guarantee to the version of the source that 
matches the version of the binary that you received).  Nothing in the 
GPL requires the one who distributes the binary to provide public access 
to the sources, either; only the person(s) to whom the binaries are 
distributed have the right to demand source from the distributor (and 
only for the version of those binaries that they possess).


But namecalling isn't really necessary, is it?

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/19/2014 10:37 AM, Dag Wieers wrote:

On Wed, 18 Jun 2014, Lamar Owen wrote:

So, somewhat paradoxically, I would have a greater confidence in 
source from git than source from a signed source RPM, again due to 
git's design.  ...


It depends of course who signs it.


First, Dag, it's good to hear from you again.  Glad to see you're still 
around, and glad to see some update activity of late.  You have a great 
perspective on all of this, having run a major third-party repo for 
years, and I appreciate your input in the discussion.


Secondly, I'll qualify your statement by doing a s/who/which signing 
key/g on it.  Any given entity may have multiple signing keys, and 
unless one has a subscription one cannot know that the public sources 
are signed with the same key that has signed the sources available with 
the subscription (to the best of my knowledge the public source RPM's 
are the same, but I have not personally checksummed all of the EL6 
source RPMS available publicly and compared against what's available by 
subscription).


If the SRPM is signed by Red Hat, and the git commits are signed by 
CentOS, you cannot really say that it is the same thing. One may claim 
that it is the same thing, but only Red Hat can prove it for every 
commit/SRPM.


Red Hat has confirmed in a public bugzilla comment ( 
https://bugzilla.redhat.com/show_bug.cgi?id=1109401#c13 ) that they are 
populating the git repos.  Yes, I would prefer it show as 'Red Hat 
Buildsys' and be signed as being from Red Hat, too.




And that is a problem.


I agree that there is a problem, at least from one point of view. My 
take on it is that if you need the chain of trust to be that tight you 
need to pony up a subscription and get RHEL, because even with a good 
chain of trust for the source there are other problems. I won't speak 
for other points of view.  To date, the level of trust I have in both SL 
and in CentOS is pretty high and I use both; but if I had to pass a cert 
of some sort (PCI or similar), or I were to need to handle sensitive 
information (HIPAA or similar), I would budget for RHEL for that 
application.




Your chain of trust becomes one piece longer, and we don't know what 
that piece exactly entails.


No, we don't.  So I'm watching the process to see how things are going, 
and make my own decisions accordingly.  But I remember when rebuilding a 
Red Hat Linux from source required a really heavily modified system 
running something similar to beehive; we've come a long way.


It's always good to hear your perspective, Dag, and I hope you have a 
great day.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/19/2014 11:38 AM, Patrick J. LoPresti wrote:

On Thu, Jun 19, 2014 at 6:00 AM, Lamar Owen  wrote:

for a particular package, you can grab the updated spec file (using the
commit feeds), pull the NEVRA info out of it

As Nico points out, this is assuming regularity and meaning in the
NEVRA values that are tenuous at best. Has Red Hat made any commitment
to provide such regularity and meaning? If not, why would you assume
them?


I would assume that the src.rpm package name and the NEVRA values from 
which the package file name derives would be consistent between 
themselves (and I don't know of a package for which this is not true, 
but I reserve the right to be wrong).  That is, if you have 
foo.1-2el7.src.rpm you will have a spec that says the name is foo, the 
version is 1, and the release is 2el7.  Architecture is only relevant 
for binary, not source rpms, and epoch is hidden from the filename.  But 
this is basic stuff.  You are getting exactly the same information in a 
de-packaged tree with spec, sources, and patches as you would with the 
packaged src.rpm except for build-generated metadata such as build host 
and build time, and the package signature.  If those build-generated 
values are important to you then this way is a setback; if those values 
aren't meaningful, then you are getting exactly the same information.  
After all, Red Hat doesn't have the EL6 SRPMs tagged by update number 
either; there is just a single directory containing all of the src.rpms 
released for that particular variant.


Yes, I have been following the CentOS lists. It sounds like a huge 
pain in the butt and extremely fragile besides. 


It does sound like a learning curve, but it's pretty obvious that 
progress is being made.


Red Hat could make it trivial and completely robust, with zero effort, 
simply by tagging the repositories. Why don't they do that, I wonder? 
- Pat 
I don't wonder.  I have a pretty good idea why they might not do that, 
and it could be simply to make it harder for Red Hat's commercial 
competitors.  This was hashed over back when EL6 was released with all 
the uproar about the way the kernel source was packaged, so I won't go 
over old ground with it.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

On Thu, Jun 19, 2014 at 6:52 AM, Lamar Owen  wrote:
>
> Have you read the RHEL subscription terms of service?  There have been
> numerous articles, written by attorneys, on this issue.

I do not care what any lawyer has to say on this topic, because this
is not a legal question.

Absolutely everyone reading this, including you, knows full well that
the intent of the GPL -- indeed, its entire purpose -- is to enable
precisely the kind of effort performed by the Scientific Linux
maintainers _without undue burden_.

If some shyster finds some nuanced loophole that allows his employer
to thwart this purpose, that says a lot more about the shyster and the
employer than it does about the GPL.

 - Pat

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

On Thu, Jun 19, 2014 at 6:00 AM, Lamar Owen  wrote:
>
> If the spec, patches, and sources are all committed with the same commit ID

Has Red Hat made any commitment to operate in this fashion?

If not, why would you assume this?

> for a particular package, you can grab the updated spec file (using the
> commit feeds), pull the NEVRA info out of it

As Nico points out, this is assuming regularity and meaning in the
NEVRA values that are tenuous at best. Has Red Hat made any commitment
to provide such regularity and meaning? If not, why would you assume
them?

> Those procedures are being written even as we speak, and patches are being
> applied to the CentOS git repo.  SL developers are involved in the process.

Yes, I have been following the CentOS lists. It sounds like a huge
pain in the butt and extremely fragile besides.

Red Hat could make it trivial and completely robust, with zero effort,
simply by tagging the repositories. Why don't they do that, I wonder?

 - Pat

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Dag Wieers]

On Wed, 18 Jun 2014, Lamar Owen wrote:

So, somewhat paradoxically, I would have a greater confidence in source from 
git than source from a signed source RPM, again due to git's design.  Yeah, I 
know, it's not what we're used to, and there is a bit of information that a 
package.src.rpm has that the git repo won't have, but it's possible to 
produce binary compatibility without that bit of info.  It may seem to be 
more work, but time will tell.


It depends of course who signs it. If the SRPM is signed by Red Hat, and 
the git commits are signed by CentOS, you cannot really say that it is the 
same thing. One may claim that it is the same thing, but only Red Hat can 
prove it for every commit/SRPM.


And that is a problem.

Your chain of trust becomes one piece longer, and we don't know what that 
piece exactly entails.


--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/18/2014 07:25 PM, Patrick J. LoPresti wrote:
So if someone redistributes Red Hat's source in accordance with the 
specific rights granted to them, Red Hat will terminate their update 
subscription? Fascinating. 
Have you read the RHEL subscription terms of service?  There have been 
numerous articles, written by attorneys, on this issue.  I would 
encourage you to do a bit of research and reading on the subject.  (I 
had a fairly long paragraph in compose, but decided to cut it, since 
others have already described it far better than I, in different venues, 
in the past.)

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/19/2014 09:44 AM, Akemi Yagi wrote:
Bonnie. :-) Akemi 
Ah, yes, I've seen alot from Bonnie; just didn't make the connection.  
Good to see ELrepo represented, too.  Thanks to you all.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/19/2014 09:16 AM, Nico Kadel-Garcia wrote:
Take a look at even a simple SPEC file, such as "ntp.spec" to see how 
much interpretation it's doing. 


Oh, I'm well aware of that.

Relying on the upstream authors to always do the .spec files *last* 
with new builds is not necessarily fair, and precludes certain type of 
code merges. 


While I have no knowledge of the actual workflow at Red Hat, I would 
think that the population into git.centos.org would happen as an 
automated part of the upstream build process, and that what is going in 
to git.centos.org is what rpmbuild is seeing as it builds the 
'canonical' upstream package (or it's being generated by depackaging the 
built SRPM).  This would just about have to be true in order for the 
git.centos.org source to be the actual upstream source.  Anyone with a 
valid subscription should be able to verify this for themselves by 
comparing the git committed source bundle with the subscription access 
SRPM.


This allows excellent change tracking with git (which many many people 
have asked for from CentOS in the past) while still getting the upstream 
source.  Of course, it is a bit of a leap of faith to trust Red Hat to 
do it this way; but, then again, unless you have (or had) a valid 
subscription you couldn't verify that the source RPMs going into 
ftp.redhat.com were the same as what subscribers were getting (in terms 
of package metadata, and even perhaps a different signing key.etc).  
IMHO, if you don't trust Red Hat to put the correct source into 
git.centos.org then why trust their source at all?  The git commit ID's 
will take care of detecting side-channel modifications after Red Hat's 
populating of the source. (Side note: Linus' choice of the way commit 
ID's were to work is absolutely brilliant.  IMHO).


But I'm curious as to what kind of merge would work with a depackaged 
source RPM but not with the files available through git.centos.org.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Akemi Yagi]

On Thu, Jun 19, 2014 at 6:00 AM, Lamar Owen  wrote:

> Note that I'm very pleased with the openness over at CentOS these days; and
> I'm very pleased to see SL devs involved.  Kudos to Pat and Connie (and any
> other SL dev that is involved that I'm forgetting) for being involved.

Bonnie. :-)

Akemi

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

On Thu, Jun 19, 2014 at 9:00 AM, Lamar Owen  wrote:
> On 06/18/2014 08:22 PM, Patrick J. LoPresti wrote:
>>
>> (different topic, different reply)
>>
>> On Wed, Jun 18, 2014 at 1:16 PM, Lamar Owen  wrote:
>>>
>>> The various spec files include the release numbers, and you can track
>>> the spec files with their commit IDs.
>>
>> Could you be more specific?
>
>
> If the spec, patches, and sources are all committed with the same commit ID
> for a particular package, you can grab the updated spec file (using the
> commit feeds), pull the NEVRA info out of it, and grab the patches and
> source (using the commit ID) corresponding to that package's NEVRA.  You'll
> have to write the tools yourself, or use the tools being written by the
> CentOS (and SL) projects.

Pulling the release number" out of the .spec file is actually a matter
of RPM configuration interpretation, with aspects like the ".el6" dist
value or possibly pre-release source versioning numbers embedded by
various means in the actual release number by various optional flags,
which may be conditionally set in the .spec file. Take a look at even
a simple SPEC file, such as "ntp.spec" ti see how much interpretation
it's doing.

Relying on the upstream authors to always do the .spec files *last*
with new builds is not necessarily fair, and precludes certain type of
code merges.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/18/2014 08:22 PM, Patrick J. LoPresti wrote:

(different topic, different reply)

On Wed, Jun 18, 2014 at 1:16 PM, Lamar Owen  wrote:

The various spec files include the release numbers, and you can track
the spec files with their commit IDs.

Could you be more specific?


If the spec, patches, and sources are all committed with the same commit 
ID for a particular package, you can grab the updated spec file (using 
the commit feeds), pull the NEVRA info out of it, and grab the patches 
and source (using the commit ID) corresponding to that package's NEVRA.  
You'll have to write the tools yourself, or use the tools being written 
by the CentOS (and SL) projects.



In particular, is there a reliable,
automated procedure to obtain a git checkout of the exact source code
for a particular complete RHEL release, and also for each subsequent
update?


Those procedures are being written even as we speak, and patches are 
being applied to the CentOS git repo.  SL developers are involved in the 
process.



I am not concerned about anybody tampering with the git repo. I am
concerned about how hard it is for third parties to create derivatives
of Red Hat. (Note "derivatives of Red Hat", not "derivatives of
CentOS".)


I'm surprised people didn't see this coming.  Seriously.  Red Hat has 
made it crystal clear that they want EL rebuilds to go through CentOS 
(or at least a centos.org git repo) to get EL upstream source (way back 
in January).  And it doesn't take a rocket scientist to figure out why 
they've taken this step.  Go back and look at the reasoning for the EL 6 
kernel source packaging changes. They telephoned this one in, guys, back 
in January.


Note that I'm very pleased with the openness over at CentOS these days; 
and I'm very pleased to see SL devs involved.  Kudos to Pat and Connie 
(and any other SL dev that is involved that I'm forgetting) for being 
involved.  It is a learning curve for everyone involved at this point, 
that's for sure (I've been following the CentOS-devel list for a long 
time.).

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

On Wed, Jun 18, 2014 at 4:16 PM, Lamar Owen  wrote:

> So, somewhat paradoxically, I would have a greater confidence in source from
> git than source from a signed source RPM, again due to git's design.  Yeah,
> I know, it's not what we're used to, and there is a bit of information that
> a package.src.rpm has that the git repo won't have, but it's possible to
> produce binary compatibility without that bit of info.  It may seem to be
> more work, but time will tell.

The difficulty is one I encounter daily. What is checked out from a
git repo today, and build with, need have no resemblance to what is in
the git repo tomorrow, or yesterday, especially if you are pulling
from the "master" branch. And relying on the ".spec file" or the last
change in the .spec file need not reflect the other changes that were
done after the .spec file, but merged after the fact or from another
code branch.

This is what GPG signed "tags", with version numbers, are very useful for.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

(different topic, different reply)

On Wed, Jun 18, 2014 at 1:16 PM, Lamar Owen  wrote:
> The various spec files include the release numbers, and you can track
> the spec files with their commit IDs.

Could you be more specific? In particular, is there a reliable,
automated procedure to obtain a git checkout of the exact source code
for a particular complete RHEL release, and also for each subsequent
update?

I am not concerned about anybody tampering with the git repo. I am
concerned about how hard it is for third parties to create derivatives
of Red Hat. (Note "derivatives of Red Hat", not "derivatives of
CentOS".)

 - Pat

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

On Wed, Jun 18, 2014 at 1:16 PM, Lamar Owen  wrote:
> On 06/14/2014 12:58 AM, Patrick J. LoPresti wrote:
>>
>> The reason to release them at all is to comply with the GPL. Such
>> encumbrances would thwart that compliance.
>
>
> Red Hat only has to directly distribute source

Not just the source, but particular rights associated with the source,
including the rights to modify and to redistribute. Indeed this is the
entire point of the GPL.

> to the people to whom they
> have distributed binaries to meet the letter of the GPL, and they don't have
> to distribute sources for packages whose license does not require such

I kind of figured mentioning the GPL would have made it clear I am
talking about the GPL and not proprietary or other software.

> (such
> as PostgreSQL, which is BSD-licensed); of course, they don't have to
> distribute the next version of the binary to you if you break their
> subscription agreement, either.

So if someone redistributes Red Hat's source in accordance with the
specific rights granted to them, Red Hat will terminate their update
subscription?

Fascinating.

 - Pat

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/14/2014 12:58 AM, Patrick J. LoPresti wrote:
The reason to release them at all is to comply with the GPL. Such 
encumbrances would thwart that compliance.

[Separate reply, since this is a different branch of thought.]

Point me to publicly available, no login-required, source RPMs for the 
current set of updates for the current version of SuSE Enterprise Linux 
Server, please.  I'd like to do an IA64 SLES rebuild, and I have had 
difficulty locating source RPMs, that aren't behind a login, for the 
purpose (although it has been a few months since I last looked). (no, 
OpenSuSE is not the same thing and is not what I'm after.)

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/14/2014 12:58 AM, Patrick J. LoPresti wrote:
The reason to release them at all is to comply with the GPL. Such 
encumbrances would thwart that compliance.


Red Hat only has to directly distribute source to the people to whom 
they have distributed binaries to meet the letter of the GPL, and they 
don't have to distribute sources for packages whose license does not 
require such (such as PostgreSQL, which is BSD-licensed); of course, 
they don't have to distribute the next version of the binary to you if 
you break their subscription agreement, either. But all of that has been 
hashed to death over the years, no?


Of course, Red Hat could make everything simple just by tagging the 
git repository for each release and update. I estimate the probability 
of that event as zero. - Pat 


The source is coming through git, which is very good (even as it is 
different).


The git commit ID is a crypto signature in effect, and prevents 
side-channel modification in-repo without it being instantly noticed.  
The various spec files include the release numbers, and you can track 
the spec files with their commit IDs.  The bugzilla entry Akemi 
references ends with a statement from Red Hat that they are the ones 
populating the incoming sources, and so seeing a git commit with a 
particular ID coming from Red Hat, due to the nature of git itself, you 
can rest that that is the source from Red Hat and that any side-channel 
modification will be instantly noticed by anyone with a clone of the 
repo.  This is what git was designed to do from the ground up, after all.


This gives a great history as well, and it's more secure than an ftp 
site, since someone compromising the package-signing key could modify an 
arbitrary package and resign without being noticed, but this is not 
possible with git.  (See news from August 22, 2008 for a bit of a 
reminder of history.)  See the recent goings-on with TrueCrypt and the 
change of signing key, etc, for a bit of context.


So, somewhat paradoxically, I would have a greater confidence in source 
from git than source from a signed source RPM, again due to git's 
design.  Yeah, I know, it's not what we're used to, and there is a bit 
of information that a package.src.rpm has that the git repo won't have, 
but it's possible to produce binary compatibility without that bit of 
info.  It may seem to be more work, but time will tell.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

On Fri, Jun 13, 2014 at 7:46 PM, Jamie Duncan  wrote:
>
> If they're not released to the public, they are almost guaranteed to be 
> encumbered in a manner similar to the binary RPMs, which would make that 
> illegal.
> I haven't looked for changes to the EULA with RHEL7 yet, but I would imagine 
> they took care of it.

The reason to release them at all is to comply with the GPL. Such
encumbrances would thwart that compliance.

The only problem with my suggestion, I think, is the one John Lauro
has identified: the latency for obtaining updates. Just how long can
one take responding to a request for source before being in violation
of the GPL, I wonder?

Of course, Red Hat could make everything simple just by tagging the
git repository for each release and update. I estimate the probability
of that event as zero.

- Pat

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[John Lauro]

The GPL should keep it (at least the majority if not all packages) from being 
significantly encumbered. The more significant issue would be getting timely 
security updates... It would be fine as a "starting point", but not really 
usable long term... that is why the git stuff has to be bothered with... 

- Original Message -

> From: "Jamie Duncan" 
> To: "Patrick J. LoPresti" 
> Cc: "Akemi Yagi" , "Nico Kadel-Garcia"
> , "Yasha Karant" ,
> ""
> ,
> SCIENTIFIC-LINUX-USERS@listserv.fnal.gov
> Sent: Friday, June 13, 2014 10:46:24 PM
> Subject: Re: RHEL 7 just hit the market place, I'm looking forward to
> when we can start testing SL 7

> """ In that case, why should Scientific Linux bother with any of this
> git
> stuff? All the SL maintainers need is one (1) Red Hat customer,
> anywhere on the planet, to obtain the source DVDs and give them a
> copy. Then they can build just like they always have...

> """

> If they're not released to the public, they are almost guaranteed to
> be encumbered in a manner similar to the binary RPMs, which would
> make that illegal.

> I haven't looked for changes to the EULA with RHEL7 yet, but I would
> imagine they took care of it.

> On Fri, Jun 13, 2014 at 9:38 PM, Patrick J. LoPresti <
> lopre...@gmail.com > wrote:

> > On Fri, Jun 13, 2014 at 6:31 PM, Akemi Yagi < amy...@gmail.com >
> > wrote:
> 
> > >
> 
> > > Just wanted to make a short note to say that source DVDs are
> > > available
> 
> > > to RH customers.
> 
> > >
> 

> > In that case, why should Scientific Linux bother with any of this
> > git
> 
> > stuff? All the SL maintainers need is one (1) Red Hat customer,
> 
> > anywhere on the planet, to obtain the source DVDs and give them a
> 
> > copy. Then they can build just like they always have...
> 

> --

> Thanks,

> Jamie Duncan
> @jamieeduncan

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Jamie Duncan]

"""
In that case, why should Scientific Linux bother with any of this git
stuff? All the SL maintainers need is one (1) Red Hat customer,
anywhere on the planet, to obtain the source DVDs and give them a
copy. Then they can build just like they always have...
"""

If they're not released to the public, they are almost guaranteed to be
encumbered in a manner similar to the binary RPMs, which would make that
illegal.
I haven't looked for changes to the EULA with RHEL7 yet, but I would
imagine they took care of it.


On Fri, Jun 13, 2014 at 9:38 PM, Patrick J. LoPresti 
wrote:

> On Fri, Jun 13, 2014 at 6:31 PM, Akemi Yagi  wrote:
> >
> > Just wanted to make a short note to say that source DVDs are available
> > to RH customers.
> >
>
> In that case, why should Scientific Linux bother with any of this git
> stuff? All the SL maintainers need is one (1) Red Hat customer,
> anywhere on the planet, to obtain the source DVDs and give them a
> copy. Then they can build just like they always have...
>



-- 
Thanks,

Jamie Duncan
@jamieeduncan

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

On Fri, Jun 13, 2014 at 6:31 PM, Akemi Yagi  wrote:
>
> Just wanted to make a short note to say that source DVDs are available
> to RH customers.
>

In that case, why should Scientific Linux bother with any of this git
stuff? All the SL maintainers need is one (1) Red Hat customer,
anywhere on the planet, to obtain the source DVDs and give them a
copy. Then they can build just like they always have...

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Akemi Yagi]

On Fri, Jun 13, 2014 at 6:19 PM, Patrick J. LoPresti  wrote:

> Actually, come to think of it, doesn't the GPL require the source for
> the product to be available on *physical* media for no more than the
> cost of reproduction? So what would happen now if a customer asked Red
> Hat for a source DVD?

Just wanted to make a short note to say that source DVDs are available
to RH customers.

Akemi

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

On Fri, Jun 13, 2014 at 6:00 PM, Nico Kadel-Garcia  wrote:
>
> Nope. They're entirely distinct repositories with straight imports
> applied as step one, no cloning of the upstream RHEL git repos.

Not exactly what I meant; see below.

>> This seems a minimal requirement for sanity. Are you saying this is
>> not what they are doing?
>
> There is nothing in the GPL or open source licenses that require
> publishing your revision history.

I did say "sanity", not "legality". But, again, not exactly what I meant.

> And exposing that history can expose internal comments,
> internal employee names, and personal development history of
> proprietary projects that were later factored out of open source or
> GPL code.

The CentOS side does not need the entire revision history in order to
keep their modifications on a separate branch. Even if the imports are
big blobs of changes with no identifiable author or commit message,
they should be on a branch separate from the CentOS modifications. If
not even this much is true, that would obviously be insane.

Next, some way to identify the actual source revisions that go into
each upstream release (and update) is pretty important, too... Unless
SL wants to become just a CentOS derivative rather than a Red Hat
derivative. That seems to be what the RedHat/CentOS folks would like
to see.

If there is no way at all to identify the actual source that went into
the 7.0 release, that is a blatant GPL violation, in my view.
"Somewhere in this haystack of git commits is the source for the
product you bought; good luck finding it" is a clear violation of both
the spirit and (in my opinion) the letter of the GPL.

Actually, come to think of it, doesn't the GPL require the source for
the product to be available on *physical* media for no more than the
cost of reproduction? So what would happen now if a customer asked Red
Hat for a source DVD?

 - Pat

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

On Fri, Jun 13, 2014 at 11:53 AM, Patrick J. LoPresti
 wrote:
> On Thu, Jun 12, 2014 at 9:11 PM, Nico Kadel-Garcia  wrote:
>>
>> git repositories *can* be as easy to use as SRPM's, *if* they are
>> tagged, and *if* there is a way to obtain an index of the relevant
>> tags of a particular point release. So the risk isn't in using git:
>> it's in the lack, so far, of relevant tags to distinguish RHEL source
>> code from whatever CentOS may choose to modify, and the potential for
>> unknown changes between the RHEL internal git repositories and
>> whatever CentOS may choose to integrate and publish.
>
> I would expect TUV (Red Hat) sources to be on one branch and all
> CentOS modifications on a different branch.

Nope. They're entirely distinct repositories with straight imports
applied as step one, no cloning of the upstream RHEL git repos.

> This seems a minimal requirement for sanity. Are you saying this is
> not what they are doing?

Look for yourself at http://git.centos.org/. I spent several long
chats with someone about security practices this week, where they
could not believe other people were not following their assumed
security practices: this is a similar situation. There is nothing in
the GPL or open source licenses that require publishing your revision
history. And exposing that history  can expose internal comments,
internal employee names, and personal development history of
proprietary projects that were later factored out of open source or
GPL code.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Patrick J. LoPresti]

On Thu, Jun 12, 2014 at 9:11 PM, Nico Kadel-Garcia  wrote:
>
> git repositories *can* be as easy to use as SRPM's, *if* they are
> tagged, and *if* there is a way to obtain an index of the relevant
> tags of a particular point release. So the risk isn't in using git:
> it's in the lack, so far, of relevant tags to distinguish RHEL source
> code from whatever CentOS may choose to modify, and the potential for
> unknown changes between the RHEL internal git repositories and
> whatever CentOS may choose to integrate and publish.

I would expect TUV (Red Hat) sources to be on one branch and all
CentOS modifications on a different branch.

This seems a minimal requirement for sanity. Are you saying this is
not what they are doing?

 - Pat

Re: [SCIENTIFIC-LINUX-USERS] RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Pat Riehecky]

On 06/12/2014 11:11 PM, Nico Kadel-Garcia wrote:

That's actually a good question, though a separate one. Are the
details of the the Scinetific Linux build system publicly available?


Hello,

For SL 5, we utilize mock with a set of home grown scripts.  I'm happy 
to discuss them, but I doubt there is much interest there.


For SL6, we utilize koji.

For more information on our koji setup:
http://indico.cern.ch/event/247864/session/9/contribution/2
http://indico.cern.ch/event/92498/session/6/contribution/50

If you've any specific enquiries on our Koji setup, let me know.

Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Lamar Owen]

On 06/13/2014 12:11 AM, Nico Kadel-Garcia wrote:
The core CentOS deverlopers have, in my personal experience, never 
been willing to discuss or expose the details of their internal build 
environment. 

Times, they are a-changin'.

I'm afraid I tried to find out details a few times, such as whether 
they use 'mach' or 'mock', and did not get very far. 


They use mock, and they published their mock configs a really long time 
ago.  I was able to get some details for my C5 IA64 rebuild project last 
year, and the CentOS core devs were very helpful when I asked them 
nicely for the info.  I've let the IA64 stuff languish for a few months, 
though; I may wait on 5.11 to rebuild those updates.  Doing the rebuild 
myself was an eye-opener, as many comments made by CentOS core devs in 
the 6.0 timeframe are made very clear indeed when you find out just 
exactly what was required to get 5.6 out of the door.  Rebuilding 
manually with mock and getting the dependencies just right was not easy 
with 5.6, in my experience.


I don't recall exactly which packages that were affected by this, but 
there was a particular library uprev from 5.5 to 5.6 that happened to 
impact another package, which wouldn't build correctly with the new 
version of that library, and thus was built against the older version 
(but there was another package that wouldn't build correctly with the 
older version).  If there is enough interest I might be able to dig that 
information up, but finding the particular build order for the 5.6 
update set (not all of the packages for which were issued in-order as 
separate updates, again IIRC) took iterative time, most of which was 
spent waiting on the machine to do the builds.  And there really wasn't 
any way to parallelize what I saw with 5.6, but I reserve the right to 
be wrong, too.  Nor did I know what order would work until a build 
completed and passed tests, at which point it was done anyway.  It was a 
lot like solving a Rubik's Cube; I can give you some basic sequences and 
algorithms, but each solution is going to require a different order of 
sequences of moves and I won't know what that order is going to be until 
it's solved.


Although I had an epiphany of sorts afterwards, but I haven't spent the 
cycles to try that idea out on the 5.5->5.6 upgrade.  (Short version of 
the epiphany: rpm -qp --queryformat "%{BUILDTIME}\n" $source-package 
).   When the update is issued (or populated to the upstream ftp source 
directory) is totally meaningless and unimportant; build time though 
does give you at least a possibility of finding out the contents of the 
buildroots (barring unpublished packages being used by the builds, which 
is always a possibility, and might very well have occurred for the 5.6 
package set, and barring hand-built packages with ad-hoc mock configs) 
at a given time.
I've not tried to dig into Scientific Linux's build environment. 
That's actually a good question, though a separate one. Are the 
details of the the Scinetific Linux build system publicly available? 
I've not personally gone digging. 
IIRC SL6 uses koji (see 
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1011&L=SCIENTIFIC-LINUX-DEVEL&P=R531&I=-3 
).


Now, for 7, much of the details of those conversations are found on the 
CentOS-devel mailing list right now, with patches being accepted from 
the community, and two CERN devs being accepted into the CentOS Core 
group (to do work on koji, again IIRC; but you can read the thread in 
the -devel list yourself).  The change to git.centos.org as being the 
place where RH is dropping source is a real game-changer, and may make a 
koji-driven rebuild much more friendly (koji can rebuild from source 
RPM, but it prefers to build out of a repository, not a directory full 
of src.rpm's).


These are certainly interesting times.

And, of course, Russ has all sorts of good stuff online for clefos. You 
should check it out.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

On Thu, Jun 12, 2014 at 6:28 PM, Yasha Karant  wrote:
> I have the following, possibly silly, question to post.  As I understand it,
> access to the git repositories meets TUV linux/GPL requirements for release
> of the source.  Nonetheless, the realities are that it is easier to build
> from the actual SRPMs that TUV uses.  These are not to be released by TUV.

This is where you're following a flawed path, I'm afraid. From
experience with Fedora, and personal experience building RPM's from
source, if you generate "tags" in git, it's as trivial to build from
the git tags as it is from SRPM's. If the tags are signed, you have
similar checksums in the total source bundle as you would with an
SRPM, and you can have similar confidence in the provenance of the
source code you're working from.

git repositories *can* be as easy to use as SRPM's, *if* they are
tagged, and *if* there is a way to obtain an index of the relevant
tags of a particular point release. So the risk isn't in using git:
it's in the lack, so far, of relevant tags to distinguish RHEL source
code from whatever CentOS may choose to modify, and the potential for
unknown changes between the RHEL internal git repositories and
whatever CentOS may choose to integrate and publish.

> Presumably, CentOS, as what amounts to an owned subsidiary of Red Hat, uses
> SRPMs and the like to build CentOS internally -- or has a very extensive
> tool set for the git repositories.  My guess is that both TUV and CentOS

Similar to what RHEL uses and Fedora uses, Take a look at the "mock"
software and the relevant koji tools to see how a small set of RPM's,
built on an older OS, can be bootstrapped into a full set of RPM's for
a production environment. It's like building gcc: First you have to
build or cross-compile a toolkit capable of building your component
building toolchain in the environment you want, then build the new
toolkit with the new toolkit to make sure things are consistent: then
you test it thoroughly, if you're wise, and only *then* do you use it
to build other components.

> construct SRPMs from the git repositories to build the respective
> distributions.  Hence, there most likely are (must be) tools/utilities that
> create from the git repositories a compatible coherent set of SRPMs.  Can
> the SL groups either get those tools from CentOS or can these tools be
> recreated?  For a system as complex as EL, any modern version of a build
> environment uses automation -- tools.

The core CentOS deverlopers have, in my personal experience, never
been willing to discuss or expose the details of their internal build
environment. I'm afraid I tried to find out details a few times, such
as whether they use 'mach' or 'mock', and did not get very far. I've
not tried to dig into Scientific Linux's build environment.

That's actually a good question, though a separate one. Are the
details of the the Scinetific Linux build system publicly available?
I've not personally gone digging.

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[R P Herrold]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 12 Jun 2014, Yasha Karant wrote:

> Hence, there most likely are (must be) tools/utilities 
> that create from the git repositories a compatible coherent 
> set of SRPMs.  Can the SL groups either get those tools from 
> CentOS or can these tools be recreated?

A person interested in experimenting may be interested in 
this content:
https://github.com/herrold/tool-tips/tree/master/clefos

Any discussion of them would occur at the: e7-devel-list at:
http://lists.clefos.org/mailman/listinfo

It is quite helpful to have the RC or beta binaries as well

- -- Russ herrold

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlOaNPQACgkQMRh1QZtklkTZXQCghM+6yiNThyHlqOORd67beLcL
yegAn0e4jm4+0ckkllbzuzsiXWjKW4lC
=kM1I
-END PGP SIGNATURE-

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Yasha Karant]

I have the following, possibly silly, question to post.  As I understand 
it, access to the git repositories meets TUV linux/GPL requirements for 
release of the source.  Nonetheless, the realities are that it is easier 
to build from the actual SRPMs that TUV uses.  These are not to be 
released by TUV.  Presumably, CentOS, as what amounts to an owned 
subsidiary of Red Hat, uses SRPMs and the like to build CentOS 
internally -- or has a very extensive tool set for the git 
repositories.  My guess is that both TUV and CentOS construct SRPMs from 
the git repositories to build the respective distributions.  Hence, 
there most likely are (must be) tools/utilities that create from the git 
repositories a compatible coherent set of SRPMs.  Can the SL groups 
either get those tools from CentOS or can these tools be recreated?  For 
a system as complex as EL, any modern version of a build environment 
uses automation -- tools.


Yasha Karant

On 06/11/2014 05:15 PM, Nico Kadel-Garcia wrote:
On Wed, Jun 11, 2014 at 1:10 PM, Yasha Karant <mailto:ykar...@csusb.edu>> wrote:


I  have been following this thread as we will be transitioning to
EL7 as it becomes available from SL. From the Red Hat CentOS web site:

 #

This is amazingly helpful. In the past I’ve spent an enormous
amount of time trying to figure out the appropriate compile
options to get newer versions of software working, and wishing
that CentOS had something like Arch’s ABS – now you do.


Access to the git resources of the Red Hat published packages is 
irrelevant to the build environment. That material is all available in 
the SRPM's.  It's the "mock" and relevant toolchains, used to build 
the hierarchy of critical depdneencies to be able to run mock and 
build the other components, that is still unpublished.


 #

End CentoOS infomercial.

What is the reality of the above -- yes, I have read this SL
thread in so far as it has appeared in my inbox to date.  Is this
truly "amazingly helpful" or is this to be a major impediment? 
Will it only "cause some users to change their workflows a bit",

or is this a much, much larger than "a bit" change?  The answer to
this question must come from the actual SL porting team(s),
presumably at Fermilab and CERN, and as farmed out to those
directly working with the Fermilab/CERN porting/support groups.

Yasha Karant


There are trade offs. A git history of the changes needed to compile 
foe CentOS is potentially useful, A lack of canonical "this tag from 
is from RHEL, the other stuff is all from CentOS" is likely to create 
confusion about which bits were published or added by whom. If 
Scientific Linux is going to built from RHEL and add its unique 
features, rather than rely on CentOS as an immediate upstream, this is 
going to need attention.  It's going to be especially awkward if they 
elect not to publish GPG signed tags to go with the particular 
software updates.


I'm staring at 
ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/os/README, 
which says that the FTP repository for RHEL SRPM mirrors will no 
longer be available. This is going to make manipulating roughly 3000 
distinct git repositories instead of one bulky SRPM directory rather 
critical. And git has no way to report the "list of all the git 
repositories on this server", they're all considered unique. Instead 
that eye-stabbing interface at http://git.centos.org/ will have to be 
parsed to extract the list of actual repositories, many components of 
which may be renamed or discarded in future RHEL 7 releases.


This is going to be a lot of work.

On 06/10/2014 05:11 PM, Nico Kadel-Garcia wrote:

    I'm staring 
athttp://www.redhat.com/about/news/press-archive/2014/6/red-hat-unveils-rhel-7,
Looks like we can start testing trying to build it. Is there anything
I can do to help?

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Akemi Yagi]

On Wed, Jun 11, 2014 at 5:15 PM, Nico Kadel-Garcia  wrote:

> I'm staring at
> ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/os/README, which
> says that the FTP repository for RHEL SRPM mirrors will no longer be
> available. This is going to make manipulating roughly 3000 distinct git
> repositories instead of one bulky SRPM directory rather critical. And git
> has no way to report the "list of all the git repositories on this server",
> they're all considered unique. Instead that eye-stabbing interface at
> http://git.centos.org/ will have to be parsed to extract the list of actual
> repositories, many components of which may be renamed or discarded in future
> RHEL 7 releases.
>
> This is going to be a lot of work.

Yes, but SL developers have actively been helping in that area. All
the activities are visible on the centos-devel mailing list. Just to
give you a few examples:

http://lists.centos.org/pipermail/centos-devel/2014-June/010599.html
http://lists.centos.org/pipermail/centos-devel/2014-June/010496.html
http://lists.centos.org/pipermail/centos-devel/2014-June/010617.html

The last one is from Bonnie about "tool to list repos on git.centos.org".

Akemi

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

On Wed, Jun 11, 2014 at 1:10 PM, Yasha Karant  wrote:

>  I  have been following this thread as we will be transitioning to EL7 as
> it becomes available from SL.  From the Red Hat CentOS web site:
>


> This is amazingly helpful. In the past I’ve spent an enormous amount of
> time trying to figure out the appropriate compile options to get newer
> versions of software working, and wishing that CentOS had something like
> Arch’s ABS – now you do.
>

Access to the git resources of the Red Hat published packages is irrelevant
to the build environment. That material is all available in the SRPM's.
It's the "mock" and relevant toolchains, used to build the hierarchy of
critical depdneencies to be able to run mock and build the other
components, that is still unpublished.


>   End CentoOS infomercial.
>
> What is the reality of the above -- yes, I have read this SL thread in so
> far as it has appeared in my inbox to date.  Is this truly "amazingly
> helpful" or is this to be a major impediment?  Will it only "cause some
> users to change their workflows a bit", or is this a much, much larger than
> "a bit" change?  The answer to this question must come from the actual SL
> porting team(s), presumably at Fermilab and CERN, and as farmed out to
> those directly working with the Fermilab/CERN porting/support groups.
>
> Yasha Karant
>

There are trade offs. A git history of the changes needed to compile foe
CentOS is potentially useful, A lack of canonical "this tag from is from
RHEL, the other stuff is all from CentOS" is likely to create confusion
about which bits were published or added by whom. If Scientific Linux is
going to built from RHEL and add its unique features, rather than rely on
CentOS as an immediate upstream, this is going to need attention.  It's
going to be especially awkward if they elect not to publish GPG signed tags
to go with the particular software updates.

I'm staring at
ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/os/README, which
says that the FTP repository for RHEL SRPM mirrors will no longer be
available. This is going to make manipulating roughly 3000 distinct git
repositories instead of one bulky SRPM directory rather critical. And git
has no way to report the "list of all the git repositories on this server",
they're all considered unique. Instead that eye-stabbing interface at
http://git.centos.org/ will have to be parsed to extract the list of actual
repositories, many components of which may be renamed or discarded in
future RHEL 7 releases.

This is going to be a lot of work.



> On 06/10/2014 05:11 PM, Nico Kadel-Garcia wrote:
>
> I'm staring at 
> http://www.redhat.com/about/news/press-archive/2014/6/red-hat-unveils-rhel-7,
> Looks like we can start testing trying to build it. Is there anything
> I can do to help?
>
>
>

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Yasha Karant]

I  have been following this thread as we will be transitioning to EL7 as 
it becomes available from SL. From the Red Hat CentOS web site:



   Getting the sources for CentOS 7

Tuesday , 10, June 2014 Jim Perrin Uncategorized 
<http://seven.centos.org/category/uncategorized/> 1 Comment 
<http://seven.centos.org/2014/06/getting-the-sources-for-centos-7/#comments> 



As part of the preparation for CentOS 7, and with a growing focus around 
making the source easier to work with for developers and Special 
Interest Groups, the CentOS Project is publishing the git source tree 
used for building the distribution. This represents a bit of a change 
from previous releases and we understand that it will cause some users 
to change their workflows a bit. We’ve put together a wiki page 
outlining how to get the sources, and a brief walk-through for using the 
tools to make it easier.


If you’re interested in working with the code for various SIGs, to help 
us with branding hunts, or just want to play around with the source for 
your own means, please see http://wiki.centos.org/Sources.  If you have 
questions or would like to make improvements to the toolkit, please join 
us on the centos-devel mailing list at 
http://lists.centos.org/mailman/listinfo/centos-devel.


One Comment
#
James Pearson <http://changedmy.name> says:
June 10, 2014 at 11:32 pm 
<http://seven.centos.org/2014/06/getting-the-sources-for-centos-7/#comment-3559> 



This is amazingly helpful. In the past I’ve spent an enormous amount of 
time trying to figure out the appropriate compile options to get newer 
versions of software working, and wishing that CentOS had something like 
Arch’s ABS – now you do.


End CentoOS infomercial.

What is the reality of the above -- yes, I have read this SL thread in 
so far as it has appeared in my inbox to date.  Is this truly "amazingly 
helpful" or is this to be a major impediment? Will it only "cause some 
users to change their workflows a bit", or is this a much, much larger 
than "a bit" change?  The answer to this question must come from the 
actual SL porting team(s), presumably at Fermilab and CERN, and as 
farmed out to those directly working with the Fermilab/CERN 
porting/support groups.


Yasha Karant


On 06/10/2014 05:11 PM, Nico Kadel-Garcia wrote:

I'm staring at 
http://www.redhat.com/about/news/press-archive/2014/6/red-hat-unveils-rhel-7,
Looks like we can start testing trying to build it. Is there anything
I can do to help?

Re: RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Paul Robert Marino]

Yes a lot of us noticed.Recompiling an entire distro from scratch is not an easy proposition. Furthermore they need to strip out all of the Red Hat branding. Expect it to take a while at least a month or two if not more.As far as helping I'm sure the offer is appreciated but due to certain legal grey areas the process of recompiling Red Hat into an other distro is generally a closed process done internally by the group respinning it. The best way you can help is assisting with the QA testing when the betas start to come out.-- Sent from my HP Pre3On Jun 10, 2014 20:12, Nico Kadel-Garcia  wrote: I'm staring at http://www.redhat.com/about/news/press-archive/2014/6/red-hat-unveils-rhel-7,
Looks like we can start testing trying to build it. Is there anything
I can do to help?

RHEL 7 just hit the market place, I'm looking forward to when we can start testing SL 7

[Nico Kadel-Garcia]

I'm staring at 
http://www.redhat.com/about/news/press-archive/2014/6/red-hat-unveils-rhel-7,
Looks like we can start testing trying to build it. Is there anything
I can do to help?

Re: RHEL 7

[Nico Kadel-Garcia]

On Sun, Feb 16, 2014 at 2:55 AM, CDR  wrote:
> When are we going to see SL 7.0m even beta?
> It is very important for my company.

Then test with the RHEL 7 beta. It's free to access with a trial
license from Red Hat, or via direct download at:

   ftp://ftp.redhat.com/pub/redhat/rhel/beta/7/

I grabbed it from the FTP site to evaluate it myself.

RHEL 7

[CDR]

When are we going to see SL 7.0m even beta?
It is very important for my company.

RHEl 7

[CDR]

I wonder when are we going to have Scientific Linux Beta 7 version. The
upstream version is already out.
Federico

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Nico Kadel-Garcia]

On Mon, Jul 29, 2013 at 1:25 PM, Lamar Owen  wrote:
> On 07/29/2013 10:47 AM, Pat Riehecky wrote:
>>
>> I believe there was some relevant information in this year's Red Hat
>> Enterprise Linux Roadmap
>>  at Red Hat Summit.
>
>
> See
> https://rhsummit.files.wordpress.com/2013/06/dumas_w_0120_rhel_roadmap1.pdf
>
> See slide 11.
>
> Also includes info relevant to the large filesystem thread. Seems EL7
> may ship with XFS as the default filesystem if it passes validation. (Slide
> 17).
>
> A very good read; time will tell how much actually comes to pass.
>
> (I'm personally looking forward to IEEE1588 PTP as shown on slide 38)...

It is interesting. I also see Samba 3.x, not Samba 4.x. *Rats*. I was
hoping for built-in Active Directory server replacements: guess I'll
be rebundling the work I've done backporting Samba 4.0.7 to RHEL 6.
And the slides don't say anything about the migration from SysV init
scripts to systemd: that is going to be a *serious* adventure for
3rd-party open source components, like EPEL and Repoforge and atrpms.

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Lamar Owen]

On 07/29/2013 10:47 AM, Pat Riehecky wrote:
I believe there was some relevant information in this year's Red Hat 
Enterprise Linux Roadmap 
 at Red Hat 
Summit.


See 
https://rhsummit.files.wordpress.com/2013/06/dumas_w_0120_rhel_roadmap1.pdf


See slide 11.

Also includes info relevant to the large filesystem thread. Seems 
EL7 may ship with XFS as the default filesystem if it passes validation. 
(Slide 17).


A very good read; time will tell how much actually comes to pass.

(I'm personally looking forward to IEEE1588 PTP as shown on slide 38)...

Re: [SCIENTIFIC-LINUX-USERS] Any rumors on rhel 7?

[Pat Riehecky]

I believe there was some relevant information in this year's Red Hat 
Enterprise Linux Roadmap 
<http://videos.cdn.redhat.com/2013-summit-platform-2.mp4> at Red Hat Summit.


On 07/26/2013 12:42 PM, Jamie Duncan wrote:

not this year.


On Fri, Jul 26, 2013 at 1:32 PM, Jos Vos mailto:j...@xos.nl>> 
wrote:

On Fri, Jul 26, 2013 at 10:19:13AM -0700, Todd And Margo Chester wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=988732

This is now protected ;-).

    > that targets RHEL 7.  Is 7 in beta?  Any target date
> to the general release?  Red Hat's web site is still
> saying 6 is it.

I've see a few bugs talking about RHEL 7 alpha.  Usually there are
a few public betas for RHEL and then it still takes many months
before GA.  Personally, I'd be surprised of RHEL 7 GA will be this
year.

--
--Jos Vos mailto:j...@xos.nl>>
--X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364

--Amsterdam, The Netherlands| Fax: +31 20 6948204





--
Thanks,

Jamie Duncan
@jamieeduncan




--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: Any rumors on rhel 7?

[Jamie Duncan]

not this year.


On Fri, Jul 26, 2013 at 1:32 PM, Jos Vos  wrote:

> On Fri, Jul 26, 2013 at 10:19:13AM -0700, Todd And Margo Chester wrote:
>
> > https://bugzilla.redhat.com/show_bug.cgi?id=988732
>
> This is now protected ;-).
>
> > that targets RHEL 7.  Is 7 in beta?  Any target date
> > to the general release?  Red Hat's web site is still
> > saying 6 is it.
>
> I've see a few bugs talking about RHEL 7 alpha.  Usually there are
> a few public betas for RHEL and then it still takes many months
> before GA.  Personally, I'd be surprised of RHEL 7 GA will be this
> year.
>
> --
> --Jos Vos 
> --X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
> --Amsterdam, The Netherlands| Fax: +31 20 6948204
>



-- 
Thanks,

Jamie Duncan
@jamieeduncan

Re: Any rumors on rhel 7?

[Jos Vos]

On Fri, Jul 26, 2013 at 10:19:13AM -0700, Todd And Margo Chester wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=988732

This is now protected ;-).

> that targets RHEL 7.  Is 7 in beta?  Any target date
> to the general release?  Red Hat's web site is still
> saying 6 is it.

I've see a few bugs talking about RHEL 7 alpha.  Usually there are
a few public betas for RHEL and then it still takes many months 
before GA.  Personally, I'd be surprised of RHEL 7 GA will be this
year.

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--Amsterdam, The Netherlands| Fax: +31 20 6948204

Any rumors on rhel 7?

[Todd And Margo Chester]

Hi All,

I just got a bug update:

https://bugzilla.redhat.com/show_bug.cgi?id=988732

that targets RHEL 7.  Is 7 in beta?  Any target date
to the general release?  Red Hat's web site is still
saying 6 is it.

Many thanks,
-T