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