Description of problem: Deleting the errata does not trigger a repo regeneration process under taskomatic Version-Release number of selected component (if applicable): Satellite 5.7 How reproducible: On the Satellite WebUI navigate Errata --> Clone Errata --> select a few erratas --> confirm --> Publish the errata then check the date and time on the repodata, you will see fresh new repodata and the errata will be there. Now try to delete the errata Errata --> Manage Errata --> select the errata you had published in the preview step and delete them. Check the repodata and you will see the taskamatic never generate new. On the clients we still see the errata but on the WebUI are removed
spacewalk.git: 1c3435a94001d00aa01c2ac0207702c04131ce40
When I delete errata from channel, repodata in /var/cache/rhn/repodata/<channel> are regenereted except for updateinfo.xml.gz that contains metadata of actually deleted errata -rw-r--r--. 1 root root 14194 Aug 5 11:36 filelists.xml.gz -rw-r--r--. 1 root root 608733 Aug 5 11:36 other.xml.gz -rw-r--r--. 1 root root 4340 Aug 5 11:36 primary.xml.gz -rw-r--r--. 1 root root 871 Aug 5 11:36 repomd.xml -rw-r--r--. 1 root root 713 Aug 5 11:30 updateinfo.xml.gz Steps to verify: 1. Create channel, create dummy packages and push packages to channel 2. Create erratum only with few of the packages, publish erratum 3. Register system to channel 4. There are 31 packages and 1 errata in channel WebUI With old package spacewalk-java-2.3.8-147.el6sat.noarch 5. Check last modified and repo build dates in channel details Last Modified 2016-08-05 11:54:02 CEST Last Repo Build 2016-08-05 11:54:02 CEST 6. Check repodata in /var/cache/rhn/repodata/<channel> -rw-r--r--. 1 root root 17756 Aug 5 11:54 filelists.xml.gz -rw-r--r--. 1 root root 662382 Aug 5 11:54 other.xml.gz -rw-r--r--. 1 root root 4781 Aug 5 11:54 primary.xml.gz -rw-r--r--. 1 root root 1134 Aug 5 11:54 repomd.xml -rw-r--r--. 1 root root 712 Aug 5 11:54 updateinfo.xml.gz from filelists.xml.gz: <filelists xmlns="http://linux.duke.edu/metadata/filelists" packages="31"> 7. yum repolist shows 31 packages 8. Delete errata 9. There are 26 packages, 0 errata in channel WebUI 10. Last repo build date does't change after taskomatic job channel-repodata Last Modified 2016-08-05 11:54:02 CEST Last Repo Build 2016-08-05 11:54:02 CEST ll /var/cache/rhn/repodata/<channel> is without change and yum repolist shows always 31 packages With spacewalk-java-2.3.8-149.el6sat.noarch 5. Check last modified and repo build dates in channel details Last Modified 2016-08-05 11:30:22 CEST Last Repo Build 2016-08-05 11:30:22 CEST 6. Check repodata in /var/cache/rhn/repodata/<channel> -rw-r--r--. 1 root root 14503 Aug 5 11:30 filelists.xml.gz -rw-r--r--. 1 root root 609048 Aug 5 11:30 other.xml.gz -rw-r--r--. 1 root root 4777 Aug 5 11:30 primary.xml.gz -rw-r--r--. 1 root root 1134 Aug 5 11:30 repomd.xml -rw-r--r--. 1 root root 713 Aug 5 11:30 updateinfo.xml.gz from filelists.xml.gz: <filelists xmlns="http://linux.duke.edu/metadata/filelists" packages="31"> 7. yum repolist shows 31 packages 8. Delete errata 9. In channel WebUI there are 26 packages and 0 errata 10. After taskomatic job channel-repodata Dates are modified Last Modified 2016-08-05 11:36:46 CEST Last Repo Build 2016-08-05 11:36:46 CEST -rw-r--r--. 1 root root 14194 Aug 5 11:36 filelists.xml.gz -rw-r--r--. 1 root root 608733 Aug 5 11:36 other.xml.gz -rw-r--r--. 1 root root 4340 Aug 5 11:36 primary.xml.gz -rw-r--r--. 1 root root 871 Aug 5 11:36 repomd.xml -rw-r--r--. 1 root root 713 Aug 5 11:30 updateinfo.xml.gz In filelists.xml.gz there are 26 packages <filelists xmlns="http://linux.duke.edu/metadata/filelists" packages="26"> yum repolist shows 26 packages in channel
Patrik, does the repomd.xml list updateinfo.xml.gz?
No it doesn't. The repomd.xml lists only primary.xml.gz, filelists.xml.gz and other.xml.gz
All right, the issue you've discovered is neither caused by this fix, nor a regression, nor a blocker as if the updateinfo isn't listed in repomd.xml, there's no reason, why yum should be downloading the file. I suggest to create a new BZ describing the behavior, when updateinfo won't be deleted and to proceed with this BZ.
OK, I have created new BZ for this issue. There's link https://bugzilla.redhat.com/show_bug.cgi?id=1365410 and I'm closing this as verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-1645.html