On 11/26/2015 02:10 PM, Karanbir Singh wrote: > On 26/11/15 12:21, Honza Horak wrote: >> On 11/26/2015 12:10 PM, Karanbir Singh wrote: >>> >>> CentOS Virtualization SIG Errata and Security Advisory CSIG-2015:0002 >>> Info >>> >>> There is an update notification for content released by the CentOS >>> Virtualisation SIG. >>> >>> The following updated files have been uploaded and are currently >>> syncing to the mirrors: >>> >>> CentOS Linux 6 /virt/x86_64/xen/ >> >> Hopefully this is the test we're supposed to provide feedback.. >> >> This seems to me unclear for people who are not familiar with mirrors >> yet, would it be bad to use full URL here? I understand that other >> mirror URLs will look differently, but that's what users would >> understand I guess. > > Part of the problem with that is - at this point we dont know where > these packages are going. Let me look into this, it should not be too > hard to solve. > >> >>> -------- >>> a6dbfb7ffcabf469dec88e0b844f24bd98ab9aef4ae7357d747ac51a5c711bc0 >>> libvirt-python-1.2.15-1.el6.x86_64.rpm >>> >>> >>> Sources: /virt/Source/xen/ >>> -------- >>> 69db6203a08bd35a9032126e9f841b3a031ea42c4342669c973c6e0c9d8b7698 >>> libvirt-python-1.2.15-1.el6.src.rpm >>> * Tue Jan 06 2015 Johnny Hughes <johnny at centos.org> - 0.600.0-25 >>> - roll in tap2 support for xen >>> >>> * Fri May 30 2014 Giuseppe Scrivano <gscrivan at redhat.com> - 0.600.0-24 >>> - Mark RHEL7 as supported (rhbz#1102345) >>> >>> * Thu May 29 2014 Giuseppe Scrivano <gscrivan at redhat.com> - 0.600.0-23 >>> - virtinst: by default add USB2 controllers (rhbz#1001999) >>> - pvpanic device support (rhbz#1101536) >> >> Is this just a diff from last released RPM? >> > > That's what I would like to get to. at the moment, its just the latest 3 > entries. There is no real state being stored anywhere. In order to get > the diff from last-release, either i can just store the entire changelog > from last time somewhere, and diff -U it, post the difference, or better > ( really! ) is to store that in a db, and only look at newer entries ( > dates? ) since last release. > > The other thing is, that when we do a new release ( eg. an SCL ) - the > first night's email will include a -lot- of srpms/rpms and their > changelogs. Every srpm has its changelog posted. What if the initial release didn't include any changelog and only additional releases would? I don't want to make it more complicated to do though, so I'm fine with either way. Honza