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 at 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 at 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/673013755b70ab1c50a53bae58d36a2321005e5f0122c215a412c4b855d78e94-updateinfo.xml.gz >>>> >>>> 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. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc