Bug 111669
Summary: | problem parsing config lines longer than 80 chars | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andre Schlink <andre> |
Component: | up2date | Assignee: | Adrian Likins <alikins> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fanny Augustin <fmoquete> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i586 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-12-10 12:43:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andre Schlink
2003-12-08 15:30:57 UTC
Hmm, there are no intential limits to the size of the config lines /etc/sysconfig/rhn/sources I dont think this is related to the size of the lines, but more likely, the names of the channel changing and there being some bugs in the state handling code for apt repos. I fixed some problems related to this a day or two ago, and while I'm not positive this is the same issue, I suspect it is. up2date-4.3.1 should include the fixes when it lands in rawhide. Just upgraded up2date. The problem remains the same: [root@Gandalf ~ ] > rpm -q up2date up2date-4.3.1-2 [root@Gandalf ~ ] > up2date -u --dry-run Fetching Obsoletes list for channel: freshrpms-core... Fetching obsoletes list for http://ayo.freshrpms.net/fedora/linux/1/i386... Traceback (most recent call last): File "/usr/sbin/up2date", line 1259, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 795, in main fullUpdate, dryRun=options.dry_run)) File "/usr/sbin/up2date", line 1138, in batchRun batch.run() File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 60, in run self.__findPackagesToUpdate() File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 100, in __findPackagesToUpdate plist.run() File "/usr/share/rhn/up2date_client/packageList.py", line 124, in run progressCallback = self.progressCallback ) File "/usr/share/rhn/up2date_client/rhnPackageInfo.py", line 404, in obsoletesList progressCallback = progressCallback ) File "/usr/share/rhn/up2date_client/rpcServer.py", line 112, in doCall ret = apply(method, args, kwargs) File "/usr/share/rhn/up2date_client/repoDirector.py", line 27, in getObsoletes return self.handlers[channel['type']].getObsoletes(channel, msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/rpmSource.py", line 249, in getObsoletes msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/repoBackends/aptRepo.py", line 168, in getObsoletes hdrList = rpm.readHeaderListFromFile(fileHdrList) rpm.error: (2, 'No such file or directory') I can't seem to duplicate this, and I suspect its not the line length. The error your getting is indicating that /var/spool/up2date/link-freshrpms is supposed to be there, but isnt. This should be a symlink to /var/spool/up2date/freshrpms-$DATE (part of the channel download creates it). My suspicision is that something wacky has happen (probabaly one of the bugs I mentioned in the previous response) and the on disk state is incorrect (aka, that symlink is missing). I think I fixed the bugs that could allow that to happen. Could you post a copy of `ls -al /var/spool/up2date` ? also, I suspect a `rm -rf /var/spool/up2date/freshrpm*` should get everything working again. Try that and let me know if it helps. You're right. The mentionend links were in place but rm -rf /var/spool/up2date resolved the problem. Thank you very much. |