hi,
http://buildlogs.centos.org/centos/7/os/x86_64-20140625/ is now online, livemedia to match this tree is in the isos/ dir at http://buildlogs.centos.org/centos/7/isos/x86_64/
Cloud images, docker images, coming shortly.
Note: this tree now has a centos-release that implements the scope of change we were talking about in the numbering thread. I went through quite a few permutations and what we have here seems like the best middle ground to be on. I am also going to try and circle back to some of the RH folks to make sure they are ok with how we message around where the CentOS Linux release is built from.
Please also test scope and breath,
The builds included address all closed bug reports so far, so please keep the reports coming as we start staging for final builds.
Hi,
On 06/25/2014 04:50 PM, Karanbir Singh wrote:
Note: this tree now has a centos-release that implements the scope of change we were talking about in the numbering thread. I went through quite a few permutations and what we have here seems like the best middle ground to be on. I am also going to try and circle back to some of the RH folks to make sure they are ok with how we message around where the CentOS Linux release is built from.
Still looking for feedback here - were pretty much at release grade at this point and the number conversation needs to close off before we can push to prod.
The tree's from the last few days have still implemented the 7.1406 scheme with almost no feedback, but for us to move forward we need a +1 vote from people here.
the other scheme that is also on the options is the 7-0-1406 and 7-0-core-1406
Finally, people have emailed and msged privately to say that having different content in redhat-release V/s centos-release is causing them some level of grief, so we'll roll that change back to make redhat-release look like centos-release.
There are going to be a few builds today, lets try and work through this and get the final release out of the door.
- KB
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Karanbir Singh Sent: 02 July 2014 10:24 To: centos-devel@centos.org Subject: Re: [CentOS-devel] Latest builds are now online 2014-06-25_build 4
....
The tree's from the last few days have still implemented the 7.1406 scheme with almost no feedback, but for us to move forward we need a +1 vote from people here.
the other scheme that is also on the options is the 7-0-1406 and 7-0-core-1406
Assuming STV, my preference would be
1. 7-0-core-1406 2. 7-0-1406 3. 7.1406
(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images)
Tim
Finally, people have emailed and msged privately to say that having different content in redhat-release V/s centos-release is causing them some level of grief, so we'll roll that change back to make redhat-release look like centos-release.
There are going to be a few builds today, lets try and work through this and get the final release out of the door.
- KB
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 07/02/2014 11:31 AM, Tim Bell wrote:
-----Original Message----- From:centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Karanbir Singh Sent: 02 July 2014 10:24 To:centos-devel@centos.org Subject: Re: [CentOS-devel] Latest builds are now online 2014-06-25_build 4
....
The tree's from the last few days have still implemented the 7.1406 scheme with almost no feedback, but for us to move forward we need a +1 vote from people here.
the other scheme that is also on the options is the 7-0-1406 and 7-0-core-1406
Assuming STV, my preference would be
- 7-0-core-1406
- 7-0-1406
I have the same preferences as the original poster ("(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images) ") about these two. Even if I am still not convinced at all that we need to make this change.
- 7.1406
definite -1 . We lose the pairing with the corresponding RHEL minor release
On 02/07/14 09:49, Manuel Wolfshant wrote:
I have the same preferences as the original poster ("(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images) ") about these two. Even if I am still not convinced at all that we need to make this change.
+1 on all that from here too
T
On Wed, Jul 2, 2014 at 1:58 AM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 02/07/14 09:49, Manuel Wolfshant wrote:
I have the same preferences as the original poster ("(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images) ") about these two. Even if I am still not convinced at all that we need to make this change.
+1 on all that from here too
+1 from me.
Akemi
On 07/02/2014 05:27 AM, Akemi Yagi wrote:
On Wed, Jul 2, 2014 at 1:58 AM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 02/07/14 09:49, Manuel Wolfshant wrote:
I have the same preferences as the original poster ("(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images) ") about these two. Even if I am still not convinced at all that we need to make this change.
+1 on all that from here too
+1 from me.
FWIW, +1 here too. 7-0-core-1406 is clear, even if a bit verbose.
On Wed, Jul 02, 2014 at 09:58:41AM +0100, Trevor Hemsley wrote:
On 02/07/14 09:49, Manuel Wolfshant wrote:
I have the same preferences as the original poster ("(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images) ") about these two. Even if I am still not convinced at all that we need to make this change.
+1 on all that from here too
while I don't have huge issues with the proposed scheme, I agree with this (and earlier) posters.
Fred
On 07/02/2014 10:49 AM, Manuel Wolfshant wrote:
On 07/02/2014 11:31 AM, Tim Bell wrote:
-----Original Message----- From:centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Karanbir Singh Sent: 02 July 2014 10:24 To:centos-devel@centos.org Subject: Re: [CentOS-devel] Latest builds are now online 2014-06-25_build 4
....
The tree's from the last few days have still implemented the 7.1406 scheme with almost no feedback, but for us to move forward we need a +1 vote from people here.
the other scheme that is also on the options is the 7-0-1406 and 7-0-core-1406
Assuming STV, my preference would be
- 7-0-core-1406
- 7-0-1406
I have the same preferences as the original poster ("(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images) ") about these two. Even if I am still not convinced at all that we need to make this change.
+1
- 7.1406
definite -1 . We lose the pairing with the corresponding RHEL minor release
Also -1 for 3rd option.
On Wed, Jul 02, 2014 at 08:31:44AM +0000, Tim Bell wrote:
Assuming STV, my preference would be
- 7-0-core-1406
- 7-0-1406
- 7.1406
(option 1 makes it clear what RHEL release the build is derived from, with consistent naming for SIGs to follow and a date stamp to show the build age and cover rebuilds for cloud images)
I'd reverse the order of 1 and 2, but I'm not overly fussed about it, as long as we don't go 3 ...
On 02/07/14 09:23, Karanbir Singh wrote:
Hi,
On 06/25/2014 04:50 PM, Karanbir Singh wrote:
Note: this tree now has a centos-release that implements the scope of change we were talking about in the numbering thread. I went through quite a few permutations and what we have here seems like the best middle ground to be on. I am also going to try and circle back to some of the RH folks to make sure they are ok with how we message around where the CentOS Linux release is built from.
Still looking for feedback here - were pretty much at release grade at this point and the number conversation needs to close off before we can push to prod.
The tree's from the last few days have still implemented the 7.1406 scheme with almost no feedback, but for us to move forward we need a +1 vote from people here.
-1
the other scheme that is also on the options is the 7-0-1406 and 7-0-core-1406
I assume you mean 7.0-1406 and 7.0-core-1406 here?
I am less opposed to these as they retain some semblance of a correlation to upstream 7.0, although presumably any release would now be .1407 rather than .1406 as we are now into July?
Finally, people have emailed and msged privately to say that having different content in redhat-release V/s centos-release is causing them some level of grief, so we'll roll that change back to make redhat-release look like centos-release.
There are going to be a few builds today, lets try and work through this and get the final release out of the door.
- KB
On 07/02/2014 10:31 AM, Ned Slider wrote:
On 02/07/14 09:23, Karanbir Singh wrote:
Hi,
On 06/25/2014 04:50 PM, Karanbir Singh wrote:
Note: this tree now has a centos-release that implements the scope of change we were talking about in the numbering thread. I went through quite a few permutations and what we have here seems like the best middle ground to be on. I am also going to try and circle back to some of the RH folks to make sure they are ok with how we message around where the CentOS Linux release is built from.
Still looking for feedback here - were pretty much at release grade at this point and the number conversation needs to close off before we can push to prod.
The tree's from the last few days have still implemented the 7.1406 scheme with almost no feedback, but for us to move forward we need a +1 vote from people here.
-1
the other scheme that is also on the options is the 7-0-1406 and 7-0-core-1406
I assume you mean 7.0-1406 and 7.0-core-1406 here?
no, we've never actually done a .anything relese, refer back to the centos-release rpms from the last 10 odd years :)
eg: centos-6 is at the moment : 6-5.11.2
It was always CentOS-4 or 5 or 6, it will be CentOS-7 here.
I am less opposed to these as they retain some semblance of a correlation to upstream 7.0, although presumably any release would now be .1407 rather than .1406 as we are now into July?
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
On 07/02/2014 10:38 AM, Karanbir Singh wrote:
I am less opposed to these as they retain some semblance of a correlation to upstream 7.0, although presumably any release would now be .1407 rather than .1406 as we are now into July?
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
This is a great example of why the date scheme is much better than the old one - it clearly reflects the state of code inside the release.
If we were to now roll in all the ZD+later updates, we'd have marked it 1407, but since it reflects the codebase from 14 06, its tagg'ed 1406.
- KB
On Wed, Jul 2, 2014 at 4:52 AM, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 10:38 AM, Karanbir Singh wrote:
I am less opposed to these as they retain some semblance of a correlation to upstream 7.0, although presumably any release would now be .1407 rather than .1406 as we are now into July?
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
This is a great example of why the date scheme is much better than the old one - it clearly reflects the state of code inside the release.
What would that date actually reflect? The last change from upstream, the date of the matching upstream release, or the CentOS release date? I think what people want is to keep it closely tied to the upstream identification.
On 07/02/2014 03:30 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 4:52 AM, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 10:38 AM, Karanbir Singh wrote:
I am less opposed to these as they retain some semblance of a correlation to upstream 7.0, although presumably any release would now be .1407 rather than .1406 as we are now into July?
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
This is a great example of why the date scheme is much better than the old one - it clearly reflects the state of code inside the release.
What would that date actually reflect? The last change from upstream, the date of the matching upstream release, or the CentOS release date?
As i said, it would refleft ( as it does not ) the code age, and not a centos release.
I think what people want is to keep it closely tied to the upstream identification.
yes, which is what this achieves.
2014-07-02 16:35 GMT+02:00 Karanbir Singh mail-lists@karan.org:
On 07/02/2014 03:30 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 4:52 AM, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 10:38 AM, Karanbir Singh wrote:
I am less opposed to these as they retain some semblance of a correlation to upstream 7.0, although presumably any release would now be .1407 rather than .1406 as we are now into July?
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
This is a great example of why the date scheme is much better than the old one - it clearly reflects the state of code inside the release.
What would that date actually reflect? The last change from upstream, the date of the matching upstream release, or the CentOS release date?
As i said, it would refleft ( as it does not ) the code age, and not a centos release.
I think what people want is to keep it closely tied to the upstream identification.
yes, which is what this achieves.
No, it doesn't. Close to upstream means 7.0 and not 7-0-core-1406.
CentOS 7.0 will reflect RHEL 7.0 codebase / code age. Based on upstream.
CentOS 7-0-core-1406 will confuse many people.
Best regards,
Morten
On Wed, Jul 2, 2014 at 9:48 AM, Morten Stevens mstevens@fedoraproject.org wrote:
I think what people want is to keep it closely tied to the upstream identification.
yes, which is what this achieves.
No, it doesn't. Close to upstream means 7.0 and not 7-0-core-1406.
CentOS 7.0 will reflect RHEL 7.0 codebase / code age. Based on upstream.
CentOS 7-0-core-1406 will confuse many people.
The confusion could be solved by a little table on the CentOS web site showing the matching identifiers. Then again, if it is a 1:1 correspondence, why change it at all? Just make the table showing the dates.... Or look at the timestamp on the file the way you usually find dates when things were done.
On 07/02/2014 03:53 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 9:48 AM, Morten Stevens mstevens@fedoraproject.org wrote:
I think what people want is to keep it closely tied to the upstream identification.
yes, which is what this achieves.
No, it doesn't. Close to upstream means 7.0 and not 7-0-core-1406.
CentOS 7.0 will reflect RHEL 7.0 codebase / code age. Based on upstream.
CentOS 7-0-core-1406 will confuse many people.
The confusion could be solved by a little table on the CentOS web site showing the matching identifiers. Then again, if it is a 1:1 correspondence, why change it at all? Just make the table showing the dates.... Or look at the timestamp on the file the way you usually find dates when things were done.
this is a great idea, I will write up something that expands on the numbering and also use that as something to point people working with variants and alternative media at.
was going to do something for the release announcement, but having it more visible on the website and often linked ( maybe a readme in centos-release ? ) might be a great ( and easy ) win.
- KB
On 2 iulie 2014 18:02:55 EEST, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 03:53 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 9:48 AM, Morten Stevens mstevens@fedoraproject.org wrote:
I think what people want is to keep it closely tied to the
upstream
identification.
yes, which is what this achieves.
No, it doesn't. Close to upstream means 7.0 and not 7-0-core-1406.
CentOS 7.0 will reflect RHEL 7.0 codebase / code age. Based on
upstream.
CentOS 7-0-core-1406 will confuse many people.
The confusion could be solved by a little table on the CentOS web
site
showing the matching identifiers. Then again, if it is a 1:1 correspondence, why change it at all? Just make the table showing
the
dates.... Or look at the timestamp on the file the way you usually find dates when things were done.
this is a great idea, I will write up something that expands on the numbering and also use that as something to point people working with variants and alternative media at.
was going to do something for the release announcement, but having it more visible on the website and often linked ( maybe a readme in centos-release ? ) might be a great ( and easy ) win.
If the content is small enough, entry #1 in CentOS 7 FAQ. If not, separate wiki page also linked from FAQ #1
- KB
On 07/02/2014 10:30 AM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 4:52 AM, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 10:38 AM, Karanbir Singh wrote:
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
...
What would that date actually reflect? The last change from upstream, the date of the matching upstream release, or the CentOS release date?
It would seem that it would be the date of the matching upstream release, per KB's comment in the thread.
On 07/02/2014 03:36 PM, Lamar Owen wrote:
On 07/02/2014 10:30 AM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 4:52 AM, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 10:38 AM, Karanbir Singh wrote:
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
...
What would that date actually reflect? The last change from upstream, the date of the matching upstream release, or the CentOS release date?
It would seem that it would be the date of the matching upstream release, per KB's comment in the thread.
right, on the flip side, had we rolled in all the updates into the release content [1] - we could call it a 1407 release. Updates since zeroday and all content since that point, will drop into the updates and extras repo.
[1]: which we are not, since we always try and match 1:1 with upstream release media
On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh mail-lists@karan.org wrote:
[1]: which we are not, since we always try and match 1:1 with upstream release media
If you aren't consuming upstream src rpms from their repositories any more, will you still actually know that you have a 1:1 match?
On 2 iulie 2014 21:26:25 EEST, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh mail-lists@karan.org wrote:
[1]: which we are not, since we always try and match 1:1 with
upstream
release media
If you aren't consuming upstream src rpms from their repositories any more, will you still actually know that you have a 1:1 match?
We consume the same sources as before. Just that instead of being pushed by RH to the world as src.rpm we have the content (still pushed by RH !) already exploded. Incidentally this happens in a convenient git environment.
On Wed, Jul 2, 2014 at 1:31 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh mail-lists@karan.org wrote:
[1]: which we are not, since we always try and match 1:1 with
upstream
release media
If you aren't consuming upstream src rpms from their repositories any more, will you still actually know that you have a 1:1 match?
We consume the same sources as before. Just that instead of being pushed by RH to the world as src.rpm we have the content (still pushed by RH !) already exploded. Incidentally this happens in a convenient git environment.
I don't understand how that relates to the upstream release packaging, though. Is there a way to distinguish something included in a future 7.1 release and a subsequent 0-day update? Or do you have to check the package versioning against their release?
On 07/02/2014 02:01 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 1:31 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh mail-lists@karan.org wrote:
[1]: which we are not, since we always try and match 1:1 with
upstream
release media
If you aren't consuming upstream src rpms from their repositories any more, will you still actually know that you have a 1:1 match?
We consume the same sources as before. Just that instead of being pushed by RH to the world as src.rpm we have the content (still pushed by RH !) already exploded. Incidentally this happens in a convenient git environment.
I don't understand how that relates to the upstream release packaging, though. Is there a way to distinguish something included in a future 7.1 release and a subsequent 0-day update? Or do you have to check the package versioning against their release?
We always have to check it against the release .. there are several different repos that we crunch into one (Server, Server-Optional, Workstation, Workstation-Optional, Client, Client-Optional, HPCNode, HPCNode-Optional, etc).
The whether the list of SRPMs is in a directory or in GIT .. it is all the same stuff in one spot.
For example:
ftp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/
That is a list of all the SRPMS ... they have a list in all the other things too .. 6Client, 6Workstation, 6Node .. we combine them all into one big set of unique SRPMs and build them all. Same thing in git .. all the versions are there, imported.
The difference is, in git you can roll back to whatever version you want, all in one spot, see the specs and sources already exploded, edit them if required, etc.
We always also need to look at the compilation of those binaries to match up the isos, etc.
On 07/03/2014 03:01 AM, Johnny Hughes wrote:
On 07/02/2014 02:01 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 1:31 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh mail-lists@karan.org wrote:
[1]: which we are not, since we always try and match 1:1 with
upstream
release media
If you aren't consuming upstream src rpms from their repositories any more, will you still actually know that you have a 1:1 match?
We consume the same sources as before. Just that instead of being pushed by RH to the world as src.rpm we have the content (still pushed by RH !) already exploded. Incidentally this happens in a convenient git environment.
I don't understand how that relates to the upstream release packaging, though. Is there a way to distinguish something included in a future 7.1 release and a subsequent 0-day update? Or do you have to check the package versioning against their release?
We always have to check it against the release .. there are several different repos that we crunch into one (Server, Server-Optional, Workstation, Workstation-Optional, Client, Client-Optional, HPCNode, HPCNode-Optional, etc).
The whether the list of SRPMs is in a directory or in GIT .. it is all the same stuff in one spot.
For example:
ftp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/
That is a list of all the SRPMS ... they have a list in all the other things too .. 6Client, 6Workstation, 6Node .. we combine them all into one big set of unique SRPMs and build them all. Same thing in git .. all the versions are there, imported.
The difference is, in git you can roll back to whatever version you want, all in one spot, see the specs and sources already exploded, edit them if required, etc.
We always also need to look at the compilation of those binaries to match up the isos, etc.
I think that his question was more like "how do we - as end consumers wishing to look "straight at the source" - know that a specific package-version-release came as update for 7.0 or was released as part of 7.1 ?". Am I right, Les ?
On Wed, Jul 2, 2014 at 9:14 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
The difference is, in git you can roll back to whatever version you want, all in one spot, see the specs and sources already exploded, edit them if required, etc.
We always also need to look at the compilation of those binaries to match up the isos, etc.
I think that his question was more like "how do we - as end consumers wishing to look "straight at the source" - know that a specific package-version-release came as update for 7.0 or was released as part of 7.1 ?". Am I right, Les ?
No, I wasn't thinking of needing to check for myself - just wanted to know that someone already had. But, having tried to assemble systems with back-rev components to duplicate and debug issues I'm wondering if that will be better/worse/same? It's not particularly easy now, especially once you cross minor rev releases.
On 07/02/2014 08:01 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 1:31 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh mail-lists@karan.org wrote:
[1]: which we are not, since we always try and match 1:1 with
upstream
release media
If you aren't consuming upstream src rpms from their repositories any more, will you still actually know that you have a 1:1 match?
We consume the same sources as before. Just that instead of being pushed by RH to the world as src.rpm we have the content (still pushed by RH !) already exploded. Incidentally this happens in a convenient git environment.
I don't understand how that relates to the upstream release packaging, though. Is there a way to distinguish something included in a future 7.1 release and a subsequent 0-day update? Or do you have to check the package versioning against their release?
All the content went into a single directory earlier as well, now its git. and the distro is still '7'
I think one issue that is clear is that lots of people were working under or just assuming context that never existed, because either its not something they interacted with -or- they didnt need to.
nutshell: git.c.o has the same content, in an easier to consume manner and an easier to track and trace format.
On Fri, Jul 4, 2014 at 11:59 AM, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 08:01 PM, Les Mikesell wrote:
On Wed, Jul 2, 2014 at 1:31 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh mail-lists@karan.org wrote:
[1]: which we are not, since we always try and match 1:1 with
upstream
release media
If you aren't consuming upstream src rpms from their repositories any more, will you still actually know that you have a 1:1 match?
We consume the same sources as before. Just that instead of being pushed by RH to the world as src.rpm we have the content (still pushed by RH !) already exploded. Incidentally this happens in a convenient git environment.
I don't understand how that relates to the upstream release packaging, though. Is there a way to distinguish something included in a future 7.1 release and a subsequent 0-day update? Or do you have to check the package versioning against their release?
All the content went into a single directory earlier as well, now its git. and the distro is still '7'
I think one issue that is clear is that lots of people were working under or just assuming context that never existed, because either its not something they interacted with -or- they didnt need to.
nutshell: git.c.o has the same content, in an easier to consume manner and an easier to track and trace format.
I've been gone for a while, and am back for now. I've been going over this, and no, it's not easier to manage or consume.
A full local build, or even maintaining a local mirror for content review, requires tracking over 3,000 distinct git repositories, without an automatic "grab the lastest version" or "mirror all this content locally" as was available with "yum", "wget", or "rsync", or "reposync" pointing to any of hundreds of public RedHat or CentOS mirrors. It makes git.centos.org itself a single point of failure in the build system, and the lack of verification of the individual builds puts "consumers" at the risk of various man in the middle attacks. And with each repository having a *separate* report of that the available builds are, rather than an easily reviewed master list, it's an extra layer of complexity.
I'm sure it's easier to track and trace git.centos.org if you wrote the system and evolved your tools to cope with it. But it's not easier then the formally workable 'yum list --disablerepo=* --enablrepo=[sourcerepo" comman, or using "reposync" to keep a relatively small repository of only the latest SRPM's. And *those* packages had verifiable GPG checksums, so they could be verified even if they came from a local mirror. Also, my working assumption is that those SRPM's had all the source and patches that actually went into the software build.
I don't believe that either RHEL nor CentOS do this, but I'm encountering way too many SRPM's that *exclude* source material depending on the local configuration options. I'm also encountering way too many SRPM's that dynamically download source content as part of the build process. Do not get me *started* on Perl packages that run 'cpan' as part of their build process, to resolve their dependencies at build time, and the steps needed to prevent that when making clean SRPM's!!!! In such cases, and to deduce such cases, it's very helpful to have the actual SRPM used at compilation. Not the git repo, the git repo is also potentially cluttered with files that are *not* in the SRPM, material such as the ".[package].metadata". That file, for example, is a git.centos.org repository artifact and never makes it into the SRPM, near as I can tell.
One solution to help with the security concerns is to use 'git tags', GPG signed, to indicate the available SRPM source trees, rather than relying purely on reports generated from git logs. I've already mentioned elsewhere that the "show_possible_srpms.sh" script is vulnerable to the accidental use of the word "import" in other logs, such as the word "important", and will produce spurious reports if it does not sanitize its inputs better. Hey, point me to the relevant bugzilla, I'll happily submit a patch for that!
Anyway: git tags would would ease the security concerns I've been raising elsewhere and am now raising here: with the verified theft of signature authorities from "GlobalSign", and other unreported certificate thefts and abuse of local proxies to manipulate local signature authorities, SSL is simply not trustworthy enough. Red Hat and CentOS can be completely rigorous and reliable in their own SSL certificate handling, but there are too many man-in-the-middle ddle risks to rely on just SSL for something as critical as production source code.
That's actually an issue for the new CentOS 7 daily builds, as well, but it's a sufficiently separate matter. That has, I hope, been discussed elsewhere.
On 07/04/2014 09:19 PM, Nico Kadel-Garcia wrote:
I'm sure it's easier to track and trace git.centos.org if you wrote the system and evolved your tools to cope with it.
you would do well to research the issue a bit,
- KB
On 07/04/2014 04:41 PM, Karanbir Singh wrote:
On 07/04/2014 09:19 PM, Nico Kadel-Garcia wrote:
I'm sure it's easier to track and trace git.centos.org if you wrote the system and evolved your tools to cope with it.
you would do well to research the issue a bit,
- KB
So, the tools we used were developed after the git repo was populated. Pat Riehecky, Tyler Parsons and Bonnie King from Scientific Linux provided the patches for the existing tools to make them work much better (and some of the tools themselves) ... and Brian Stinson from Kansas State University provided centpkg. Kay Williams provided a tool to help with branding identification. Testers put in bugs at bugs.centos.org in a totally open QA process.
All of the mock configs are provided in git.centos.org:
https://git.centos.org/tree/sig-core!bld-seven.git
the repos we built against are provided on buildlogs.centos.org (starting with c7-*):
We simply use the git repo to create an SRPM, then send it to mock to build, the output you see there.
I guarantee you, I am the one building the RPMs, and I am building them using get_sources.sh, into_srpm.sh, return_disttag.sh, show_possible_srpms.sh, etc. from centos-git-common:
https://git.centos.org/tree/centos-git-common.git
I use the activity log of git:
https://git.centos.org/project/?p=rpms
and the rhn public errata page
https://access.redhat.com/security/updates/active/
to figure out if I need to build a package.
The git tree is just an exploded SRPM ... rpmbuild -bp turns it back into an SRPM, rpmbuild -bb (or mock) turns it into binaries.
There are no special tools, it is just repetitive, tedious work to check the activity log, if something changes, then check it out from the git repo, turn it into an SRPM, submit it to mock, sign it and put it where it goes.
On Fri, Jul 4, 2014 at 6:49 PM, Johnny Hughes johnny@centos.org wrote:
On 07/04/2014 04:41 PM, Karanbir Singh wrote:
On 07/04/2014 09:19 PM, Nico Kadel-Garcia wrote:
I'm sure it's easier to track and trace git.centos.org if you wrote the system and evolved your tools to cope with it.
you would do well to research the issue a bit,
- KB
So, the tools we used were developed after the git repo was populated. Pat Riehecky, Tyler Parsons and Bonnie King from Scientific Linux provided the patches for the existing tools to make them work much better (and some of the tools themselves) ... and Brian Stinson from Kansas State University provided centpkg. Kay Williams provided a tool to help with branding identification. Testers put in bugs at bugs.centos.org in a totally open QA process.
Right. And you had direct access to the authors, and they had direct access to the build process. Come in from outside, and it looks like spaghetti until you spend a *lot* of time analyzing the code, which is changing even as we speak (witness centpkg).
This is *normal*. A new build process almost invariably looks like spaghetti until some procedures and API's are written, and available, to provide defined procedures. There are little missing steps like "set up a working mock to build RPM's in" that someone from outside, with less experience than you or me, would not be aware of.
All of the mock configs are provided in git.centos.org:
Wow! What an intuitive, apparent, and well labeled name, completely obvious from the git.centos.org front page! And its name makes it completely apparent that it contains the mock configurations, especially since it has no description whatsoever for the repo itself!
I'm afraid you just made my point. It looks like spaghetti. And there is no link to 'bugs.centos.org' from the 'git.centos.org' website, which would be helpful.
the repos we built against are provided on buildlogs.centos.org (starting with c7-*):
We simply use the git repo to create an SRPM, then send it to mock to build, the output you see there.
And that's all cool, thank you for the pointers. Any chance of getting those into README.md for https://git.centos.org/tree/sig-core!bld-seven.git
I guarantee you, I am the one building the RPMs, and I am building them using get_sources.sh, into_srpm.sh, return_disttag.sh, show_possible_srpms.sh, etc. from centos-git-common:
https://git.centos.org/tree/centos-git-common.git
I use the activity log of git:
I've mentioned separately about that, *ouch*. I really think that you, as a builder, would benefit from consistent use of 'git tag' for denoting the avaious builds.
and the rhn public errata page
https://access.redhat.com/security/updates/active/
to figure out if I need to build a package.
The git tree is just an exploded SRPM ... rpmbuild -bp turns it back into an SRPM, rpmbuild -bb (or mock) turns it into binaries.
And boy, do I understand and sympathize with that process. I'd love to see the relevant mock configurations get into a relevant RPM with daily build compatible config files, but that would be dependent on the installation of a 'mock' RPM. That gets into weirdness with CentOS build environments being dependent on mock from a third party (such as the EPEL beta 7 repository), and needing something like a 'yum-conf-epel' RPM to enable EPEL, then something like a "mock-conf-centos-daily' package to enable CentOS nightly build access. Would that be acceptable?
Would you like any of those, to help with offsite developers? I'd be happy to submit code!
There are no special tools, it is just repetitive, tedious work to check the activity log, if something changes, then check it out from the git repo, turn it into an SRPM, submit it to mock, sign it and put it where it goes.
That signature is, IMHO, too late. I'd love to see the signatures on git tags from the git repository itself, to help ensure provenance. But since you're the one doing signatures, I'm also afraid that would probably double *your* workload.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 07/05/2014 04:49 PM, Nico Kadel-Garcia wrote:
Wow! What an intuitive, apparent, and well labeled name, completely obvious from the git.centos.org front page! And its name makes it completely apparent that it contains the mock configurations, especially since it has no description whatsoever for the repo itself!
given that this is SIG Core effort, I'd expect people to look at that project's code for this content, and its clearly marked. But feel free to submit patches to docs etc.
also, please use git format-patch and post to this list; if you want to use bugs.c.o as a marker, thats fine, but the patch content needs to come to this list and will be commited from here.
And boy, do I understand and sympathize with that process. I'd love to see the relevant mock configurations get into a relevant RPM with daily build compatible config files, but that would be dependent on the installation of a 'mock' RPM. That gets into weirdness with CentOS build environments being dependent on mock from a third party (such as the EPEL beta 7 repository), and needing something like a 'yum-conf-epel' RPM to enable EPEL, then something like a "mock-conf-centos-daily' package to enable CentOS nightly build access. Would that be acceptable?
all of this is already in place, look at the buildlogs site and track down a build target, it has the mock config, the environment around it and the input + ouput results. And this is per build, so address's the concern around environment changes etc.
creating 'chaser' or 'shadow' builder threads is easy, chain it from a reposync call ( each of the build targets has a complete repodata/ dir )
That signature is, IMHO, too late. I'd love to see the signatures on git tags from the git repository itself, to help ensure provenance. But since you're the one doing signatures, I'm also afraid that would probably double *your* workload.
the piece that is still missing is the quantification of what that delivers.
- KB
Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 10:38 AM, Karanbir Singh wrote:
no it wont, we use the tag that matches upstream's release stamp, so will stay 1406
This is a great example of why the date scheme is much better than the old one - it clearly reflects the state of code inside the release.
If we were to now roll in all the ZD+later updates, we'd have marked it 1407, but since it reflects the codebase from 14 06, its tagg'ed 1406.
Sorry, I still don't get it. A tag of 0 also clearly reflects the state of the code inside the release.
In what way is the date scheme better? The amount of additional information it conveys is minimal: I almost never need to know when a particular update was released. And to convert back to the update number one has to refer to a table on the website.
It has been said that there's no problem in computer science that can't be solved by an additional level of indirection. I don't understand what problem is being solved here.
Ron
On 2 July 2014 03:38, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 10:31 AM, Ned Slider wrote:
On 02/07/14 09:23, Karanbir Singh wrote:
Hi,
On 06/25/2014 04:50 PM, Karanbir Singh wrote:
Note: this tree now has a centos-release that implements the scope of change we were talking about in the numbering thread. I went through quite a few permutations and what we have here seems like the best middle ground to be on. I am also going to try and circle back to some of the RH folks to make sure they are ok with how we message around where the CentOS Linux release is built from.
Still looking for feedback here - were pretty much at release grade at this point and the number conversation needs to close off before we can push to prod.
The tree's from the last few days have still implemented the 7.1406 scheme with almost no feedback, but for us to move forward we need a +1 vote from people here.
-1
the other scheme that is also on the options is the 7-0-1406 and 7-0-core-1406
I assume you mean 7.0-1406 and 7.0-core-1406 here?
no, we've never actually done a .anything relese, refer back to the centos-release rpms from the last 10 odd years :)
eg: centos-6 is at the moment : 6-5.11.2
Ohhh. you know if I had realized that was what you were talking about this whole time :).
7-core-1406
[though I would prefer 201406]
and your bikeshed needs to be pale yellow.
On 07/02/2014 04:09 PM, Stephen John Smoogen wrote:
Ohhh. you know if I had realized that was what you were talking about this whole time :).
7-core-1406
[though I would prefer 201406]
to be honest, i am struggling to get 'core' included in here, having an alphanumeric character creates some interesting challenges with rpm version tracking etc.
we might need to go with a : 7-0-1406 (Core)
testing continues, i will have options online later today
and your bikeshed needs to be pale yellow.
right, i agree - we cant have it be sunlight yellow :)
On 2 July 2014 09:36, Karanbir Singh mail-lists@karan.org wrote:
On 07/02/2014 04:09 PM, Stephen John Smoogen wrote:
Ohhh. you know if I had realized that was what you were talking about this whole time :).
7-core-1406
[though I would prefer 201406]
to be honest, i am struggling to get 'core' included in here, having an alphanumeric character creates some interesting challenges with rpm version tracking etc.
we might need to go with a : 7-0-1406 (Core)
I wonder if this is similar to why we can't have repotags via koji
testing continues, i will have options online later today
and your bikeshed needs to be pale yellow.
right, i agree - we cant have it be sunlight yellow :)
I have changed my mind it needs to be electric yellow with the trim a sharp chartreuse.
On 07/02/2014 05:36 PM, Karanbir Singh wrote:
On 07/02/2014 04:09 PM, Stephen John Smoogen wrote:
Ohhh. you know if I had realized that was what you were talking about this whole time :).
7-core-1406
[though I would prefer 201406]
to be honest, i am struggling to get 'core' included in here, having an alphanumeric character creates some interesting challenges with rpm version tracking etc.
we might need to go with a : 7-0-1406 (Core)
This is also fine. Maybe even better from my point of view.
testing continues, i will have options online later today
and your bikeshed needs to be pale yellow.
right, i agree - we cant have it be sunlight yellow :)
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel- bounces@centos.org] On Behalf Of Ljubomir Ljubojevic Sent: 02 July 2014 19:19 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] Latest builds are now online 2014-06-25_build 4
On 07/02/2014 05:36 PM, Karanbir Singh wrote:
On 07/02/2014 04:09 PM, Stephen John Smoogen wrote:
Ohhh. you know if I had realized that was what you were talking about this whole time :).
7-core-1406
[though I would prefer 201406]
to be honest, i am struggling to get 'core' included in here, having an alphanumeric character creates some interesting challenges with rpm version tracking etc.
we might need to go with a : 7-0-1406 (Core)
This is also fine. Maybe even better from my point of view.
For me (Core) would be fine. I would want to be able to extract the SIG from the release in a consistent fashion using Puppet as we would be likely to run multiple SIGs in parallel according to the application needs.
Tim
testing continues, i will have options online later today
and your bikeshed needs to be pale yellow.
right, i agree - we cant have it be sunlight yellow :)
-- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe
StarOS, Mikrotik and CentOS/RHEL/Linux consultant _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 02/07/14 18:25, Tim Bell wrote:
For me (Core) would be fine. I would want to be able to extract the SIG from the release in a consistent fashion using Puppet as we would be likely to run multiple SIGs in parallel according to the application needs.
Did anyone suggest the possibility of using centos-$sig-release rpms as a way to opt into a particular SIG? Might be better than jury rigging -core- into the main release package?
T
-
Akemi Yagi -
Fred Smith -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Morten Stevens -
Ned Slider -
Neil Thompson -
Nico Kadel-Garcia -
Patrick Bervoets -
Ron Yorston -
Stephen John Smoogen -
Tim Bell -
Trevor Hemsley