I found the problem it starts at line 178 in /usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py there is handling for .gz files but not .bz2 files
On Mon, Jun 3, 2013 at 4:03 PM, Paul Robert Marino <[email protected]>wrote: > I think I figured out the cause of this > if im right its because their updateinfo.xml is compressed with bzip > instead of gzip > I know I cant process it at all. > > http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/repodata/updateinfo.xml.bz2 > > > > On Tue, May 28, 2013 at 9:17 AM, Paul Robert Marino > <[email protected]>wrote: > >> the yum clean all was the first thing i tried >> >> interestingly i did find an error in the taskomatic logs the error itself >> is a little puzzling >> this happens over and over again but only on scientific Linux channels >> >> " >> ng repos for channel: Scientific Linux 6 Updates FastBug (x86_64) >> INFO | jvm 1 | 2013/04/23 00:30:31 | 2013-04-23 00:30:31,913 >> [DefaultQuartzScheduler_Worker-9] ERROR >> com.redhat.rhn.manager.satellite.SystemCommandExecu >> tor - Error encountered executing (args=[/usr/bin/spacewalk-repo-sync, >> --channel, scientific6-x86_64-updates-fast, --type, yum]) >> INFO | jvm 1 | 2013/04/23 00:30:31 | 2013-04-23 00:30:31,913 >> [DefaultQuartzScheduler_Worker-9] ERROR >> com.redhat.rhn.manager.satellite.SystemCommandExecu >> tor - Error message from process: Traceback (most recent call last): >> INFO | jvm 1 | 2013/04/23 00:30:31 | File >> "/usr/bin/spacewalk-repo-sync", line 103, in <module> >> INFO | jvm 1 | 2013/04/23 00:30:31 | sys.exit(abs(main() or 0)) >> INFO | jvm 1 | 2013/04/23 00:30:31 | File >> "/usr/bin/spacewalk-repo-sync", line 96, in main >> INFO | jvm 1 | 2013/04/23 00:30:31 | sync.sync() >> INFO | jvm 1 | 2013/04/23 00:30:31 | File >> "/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py", >> line 112, in sync >> INFO | jvm 1 | 2013/04/23 00:30:31 | self.error_msg("ERROR: %s" >> % e.value) >> INFO | jvm 1 | 2013/04/23 00:30:31 | AttributeError: >> 'exceptions.IOError' object has no attribute 'value' >> INFO | jvm 1 | 2013/04/23 00:30:31 | >> INFO | jvm 1 | 2013/04/23 00:30:31 | 2013-04-23 00:30:31,913 >> [DefaultQuartzScheduler_Worker-9] INFO >> com.redhat.rhn.taskomatic.task.RepoSyncTask - Repo URL: >> http://ftp.scientificlinux.org/linux/scientific/6/x86_64/updates/fastbugs/ >> INFO | jvm 1 | 2013/04/23 00:30:31 | Packages in repo: >> 106 >> INFO | jvm 1 | 2013/04/23 00:30:31 | No new packages to sync. >> INFO | jvm 1 | 2013/04/23 00:30:31 | >> INFO | jvm 1 | 2013/04/23 00:30:31 | 2013-04-23 00:30:31,913 >> [DefaultQuartzScheduler_Worker-9] ERROR >> com.redhat.rhn.taskomatic.task.RepoSyncTask - Traceback (most recent call >> last): >> INFO | jvm 1 | 2013/04/23 00:30:31 | File >> "/usr/bin/spacewalk-repo-sync", line 103, in <module> >> INFO | jvm 1 | 2013/04/23 00:30:31 | sys.exit(abs(main() or 0)) >> INFO | jvm 1 | 2013/04/23 00:30:31 | File >> "/usr/bin/spacewalk-repo-sync", line 96, in main >> INFO | jvm 1 | 2013/04/23 00:30:31 | sync.sync() >> INFO | jvm 1 | 2013/04/23 00:30:31 | File >> "/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py", >> line 112, in sync >> INFO | jvm 1 | 2013/04/23 00:30:31 | self.error_msg("ERROR: %s" >> % e.value) >> INFO | jvm 1 | 2013/04/23 00:30:31 | AttributeError: >> 'exceptions.IOError' object has no attribute 'value' >> INFO | jvm 1 | 2013/04/23 00:30:31 | >> >> " >> >> I updated my test instance to spacewalk 1.9 and it seems to have fixed it >> but a new error appears in the reposync log >> >> " >> Linking packages to channel. >> >> Repo http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/ has >> comps file comps-sl6-x86_64.xml.gz. >> ERROR: Not a gzipped file >> Sync completed. >> Total time: 1:46:18 >> >> " >> >> Note: I'm still seeing this on my production instance which is still >> running 1.9 . >> Also to fix it i had to completely remove all the packages from the >> channels effected and resync them but I didn't need to delete the packages >> from the system just from the channels. >> >> >> >> On Tue, May 28, 2013 at 4:22 AM, Tomas Lestach <[email protected]>wrote: >> >>> ----- Original Message ----- >>> > From: "Paul Robert Marino" <[email protected]> >>> > To: [email protected] >>> > Sent: Sunday, May 26, 2013 6:38:13 PM >>> > Subject: [Spacewalk-list] Issues with Scientific Linux 6.4 >>> > >>> > >>> > >>> > >>> > >>> > Ive been having issues with Spacewalk 1.8 client and Scientific Linux >>> > 6.4 and 6 Rolling. note this does not seem to effect Scientific >>> > Linux 6.3 as far as i can tell. >>> > >>> > in my test instance spacewalks web interface says i have 6449 >>> > packages in the base channel for Scientific Linux 6.4 but from the >>> > client when i run " yum repolist -v" it tells me i have 6,448 in >>> > that same channel. >>> >>> To make sure you work with latest repodata, I'd run: >>> # yum clean all >>> and repeat your repolist command. >>> >>> If it does not help, check, when the repodata was generated for your >>> channel. >>> ('Last Repo Build' item on the >>> /rhn/channels/ChannelDetail.do?cid=<channel_id> page) >>> >>> Any errors in the /var/log/rhn/rhn_taskomatic_daemon.log? >>> >>> Regards, >>> -- >>> Tomas Lestach >>> RHN Satellite Engineering, Red Hat >>> >>> >>> > Ive tracked it to python-libguestfs-1.16.34-2.el6.x86_64.rpm as the >>> > package the show up in spacewalk but not in yum >>> > >>> > >>> > >>> > >>> > the repo sync doesnt show an error >>> > " >>> > ['/usr/bin/spacewalk-repo-sync', '--channel', >>> > 'scientific-6.4-x86_64', '--type', 'yum'] >>> > Repo URL: >>> > http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/ >>> > Packages in repo: 6449 >>> > Packages already synced: 6448 >>> > Packages to sync: 1 >>> > 1/1 : python-libguestfs-1.16.34-2.el6-1.x86_64 >>> > Repo http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/ >>> > has comps file comps-sl6-x86_64.xml.gz. >>> > " >>> > >>> > >>> > Ive checked the sums of the packages on the FTP servers and the one >>> > in spacewalk along with the headers, signatures, and file size every >>> > thing matches. >>> > >>> > If I add the SL repos the package seems installs fine directly from >>> > the FTP site via yum. >>> > >>> > >>> > has any one else run into any thing similar. >>> > >>> > >>> > >>> > _______________________________________________ >>> > Spacewalk-list mailing list >>> > [email protected] >>> > https://www.redhat.com/mailman/listinfo/spacewalk-list >>> >>> _______________________________________________ >>> Spacewalk-list mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/spacewalk-list >>> >> >> >
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
