As the subject says, I know it's been discussed before (albeit not any great length); however, can we open discussions again about including errata in the repositories?
With the more communal nature of the CentOS project and management through "Special Interest Groups" or SIGs, can we perhaps open up a packaging SIG?
Nothing to big, something simply to start packaging errata into the repositories to start. Later on it can evolve, but I think that would be a great first step to tackle.
Thoughts?
Steven Crothers steven.crothers@gmail.com
On 09/15/2014 08:53 AM, Steven Crothers wrote:
Nothing to big, something simply to start packaging errata into the repositories to start. Later on it can evolve, but I think that would be a great first step to tackle.
What does errata-in-the-repo mean ?
Sorry KB, I thought it was obvious from Fedora (but I forget not all CentOS users are Fedora users and vice versa).
"errata in the repo" means this: http://mirror.steadfast.net/epel/7/x86_64/repodata/673013755b70ab1c50a53bae5...
The errata data is packaged into the yum repository into the repodata folder, making things like Spacewalk automatically import errata on each mirror sync. Also provides some extra features with yum for viewing this data (and later DNF, I think?).
It's more of a convenience or "nice to have" feature. Steven Crothers steven.crothers@gmail.com
On Mon, Sep 15, 2014 at 12:40 PM, Karanbir Singh mail-lists@karan.org wrote:
On 09/15/2014 08:53 AM, Steven Crothers wrote:
Nothing to big, something simply to start packaging errata into the repositories to start. Later on it can evolve, but I think that would be a great first step to tackle.
What does errata-in-the-repo mean ?
-- 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
Hi
On 09/15/2014 05:51 PM, Steven Crothers wrote:
Sorry KB, I thought it was obvious from Fedora (but I forget not all CentOS users are Fedora users and vice versa).
"errata in the repo" means this: http://mirror.steadfast.net/epel/7/x86_64/repodata/673013755b70ab1c50a53bae5...
The errata data is packaged into the yum repository into the repodata folder, making things like Spacewalk automatically import errata on each mirror sync. Also provides some extra features with yum for viewing this data (and later DNF, I think?).
ok, so the updateinfo content - we can carry that, where would the data come from ?
On 09/15/2014 11:55 AM, Karanbir Singh wrote:
Hi
On 09/15/2014 05:51 PM, Steven Crothers wrote:
Sorry KB, I thought it was obvious from Fedora (but I forget not all CentOS users are Fedora users and vice versa).
"errata in the repo" means this: http://mirror.steadfast.net/epel/7/x86_64/repodata/673013755b70ab1c50a53bae5...
The errata data is packaged into the yum repository into the repodata folder, making things like Spacewalk automatically import errata on each mirror sync. Also provides some extra features with yum for viewing this data (and later DNF, I think?).
ok, so the updateinfo content - we can carry that, where would the data come from ?
Can whatever makes the mailing list errata messages be used as a data source to generate updateinfo.xml? Obviously to make this work, something would have to store a persistent history of all previously packaged updates. It would have to be generated and shipped as part of the metadata update when pushing new packages to the mirror.
This is something we would very much like to see in CentOS, since spacewalk relies on this data source for pulling in errata information. Our current workaround is mailing list scraping and it's not reliable.
One solution could be to rearchitect the way errata is released all together. Queue the errata for delivery to the list and also process the data into the update info simultaneously. Giving a single pane of glass to deal with for distributing errata.
On Sep 15, 2014, at 5:34 PM, Kevin Stange kevin@steadfast.net wrote:
On 09/15/2014 11:55 AM, Karanbir Singh wrote: Hi
On 09/15/2014 05:51 PM, Steven Crothers wrote: Sorry KB, I thought it was obvious from Fedora (but I forget not all CentOS users are Fedora users and vice versa).
"errata in the repo" means this: http://mirror.steadfast.net/epel/7/x86_64/repodata/673013755b70ab1c50a53bae5...
The errata data is packaged into the yum repository into the repodata folder, making things like Spacewalk automatically import errata on each mirror sync. Also provides some extra features with yum for viewing this data (and later DNF, I think?).
ok, so the updateinfo content - we can carry that, where would the data come from ?
Can whatever makes the mailing list errata messages be used as a data source to generate updateinfo.xml? Obviously to make this work, something would have to store a persistent history of all previously packaged updates. It would have to be generated and shipped as part of the metadata update when pushing new packages to the mirror.
This is something we would very much like to see in CentOS, since spacewalk relies on this data source for pulling in errata information. Our current workaround is mailing list scraping and it's not reliable.
-- Kevin Stange Chief Technology Officer Steadfast | http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
My question still remains : where is this data going to come from and who is taking ownership of validating the CVE's and bugfix's etc ?
if we can come up with a reasonable answer to that question - then we can move to the next stage of writing the code that generates and process's the information.
in terms of what we do at the moment, this sums it up :
sha256sum * > mail centos-announce@centos.org
- KB
On 09/16/2014 02:12 AM, Steven Crothers wrote:
One solution could be to rearchitect the way errata is released all together. Queue the errata for delivery to the list and also process the data into the update info simultaneously. Giving a single pane of glass to deal with for distributing errata.
On Sep 15, 2014, at 5:34 PM, Kevin Stange kevin@steadfast.net wrote:
On 09/15/2014 11:55 AM, Karanbir Singh wrote: Hi
On 09/15/2014 05:51 PM, Steven Crothers wrote: Sorry KB, I thought it was obvious from Fedora (but I forget not all CentOS users are Fedora users and vice versa).
"errata in the repo" means this: http://mirror.steadfast.net/epel/7/x86_64/repodata/673013755b70ab1c50a53bae5...
The errata data is packaged into the yum repository into the repodata folder, making things like Spacewalk automatically import errata on each mirror sync. Also provides some extra features with yum for viewing this data (and later DNF, I think?).
ok, so the updateinfo content - we can carry that, where would the data come from ?
Can whatever makes the mailing list errata messages be used as a data source to generate updateinfo.xml? Obviously to make this work, something would have to store a persistent history of all previously packaged updates. It would have to be generated and shipped as part of the metadata update when pushing new packages to the mirror.
This is something we would very much like to see in CentOS, since spacewalk relies on this data source for pulling in errata information. Our current workaround is mailing list scraping and it's not reliable.
On 09/16/2014 05:41 AM, Karanbir Singh wrote:
My question still remains : where is this data going to come from and who is taking ownership of validating the CVE's and bugfix's etc ?
That is unimportant to me.
There's already "data", a link to the RH web site, along with a list of packages that are updated, and a CESA, CEBA or CEEA number, which flags the type of fix as bug, security, or enhancement. That's all I care about having in updateinfo.xml. I don't care, if you can't list every individual CVE and fix in the description.
I just care that in spacewalk, when it syncs the repo, it automatically associates each update with what type of fix it is and provides the relevant link into RH's web site for further details to those interested.
Trying to do this with the mailing list is imprecise and buggy because there are emails that slightly vary in format and the API spacewalk has for adding errata is less robust than its means for directly importing it from an updateinfo.xml.
if we can come up with a reasonable answer to that question - then we can move to the next stage of writing the code that generates and process's the information.
I hope that answer's reasonable. I don't feel like there is any need for this to be more complicated than just generating what you already do into an updateinfo.xml file. It's more useful than nothing.
in terms of what we do at the moment, this sums it up :
sha256sum * > mail centos-announce@centos.org
Somehow you get a link to RH and issue a CEXA number for each update. Where does that come from?
On 09/16/2014 04:39 PM, Kevin Stange wrote:
On 09/16/2014 05:41 AM, Karanbir Singh wrote:
My question still remains : where is this data going to come from and who is taking ownership of validating the CVE's and bugfix's etc ?
That is unimportant to me.
There's already "data", a link to the RH web site, along with a list of packages that are updated, and a CESA, CEBA or CEEA number, which flags the type of fix as bug, security, or enhancement. That's all I care about having in updateinfo.xml. I don't care, if you can't list every individual CVE and fix in the description.
sounds good, do you want to propose some code that helps make this happen ? there is the update-repo scripts already there, those can be overloaded to make this happen.
sha256sum * > mail centos-announce@centos.org
Somehow you get a link to RH and issue a CEXA number for each update. Where does that come from?
thats a manual process, someone hasto go look and find it :(
On 09/16/2014 10:46 AM, Karanbir Singh wrote:
On 09/16/2014 04:39 PM, Kevin Stange wrote:
On 09/16/2014 05:41 AM, Karanbir Singh wrote:
My question still remains : where is this data going to come from and who is taking ownership of validating the CVE's and bugfix's etc ?
That is unimportant to me.
There's already "data", a link to the RH web site, along with a list of packages that are updated, and a CESA, CEBA or CEEA number, which flags the type of fix as bug, security, or enhancement. That's all I care about having in updateinfo.xml. I don't care, if you can't list every individual CVE and fix in the description.
sounds good, do you want to propose some code that helps make this happen ? there is the update-repo scripts already there, those can be overloaded to make this happen.
I'll give this a look and see what can be done. The question is how and where to store the previous errata content. Is it already kept somewhere or would we just have to scrape it all off the mailing list to recover what's already been sent?
sha256sum * > mail centos-announce@centos.org
Somehow you get a link to RH and issue a CEXA number for each update. Where does that come from?
thats a manual process, someone hasto go look and find it :(
Is there a script that assembles the email or is it a copy and paste job?
-
Karanbir Singh -
Kevin Stange -
Steven Crothers