This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 111669 - problem parsing config lines longer than 80 chars
problem parsing config lines longer than 80 chars
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
1
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-08 10:30 EST by Andre Schlink
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-10 07:43:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andre Schlink 2003-12-08 10:30:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

Description of problem:
up2date failes fetching obsoletes-list when the repositories entry in
/etc/sysconfig/rhn/sources is longer than 80 chars.

For example:

apt freshrpms http://ayo.freshrpms.net fedora/linux/1/i386 core
updates freshrpms

doesn't work

apt freshrpm http://ayo.freshrpms.net fedora/linux/1/i386 core updates
freshrpms

works

Version-Release number of selected component (if applicable):
up2date-4.1.16-1

How reproducible:
Always

Steps to Reproduce:
1. Add a apt-repository entry longer than 80 chars to config
2. run up2date -u
3. you will get a traceback when up2date tries to fetch obsoletes list
    

Actual Results:  Getting a traceback when up2date tries to fetch
obsoletes list ('No such file or directory')

Expected Results:  should update as usual...

Additional info:

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 1188, in ?
    sys.exit(main() or 0)
  File "/usr/sbin/up2date", line 766, in main
    fullUpdate, dryRun=options.dry_run))
  File "/usr/sbin/up2date", line 1051, in batchRun
    batch.run()
  File "up2dateBatch.py", line 58, in run
  File "up2dateBatch.py", line 96, in __findPackagesToUpdate
  File "packageList.py", line 123, in run
  File "rhnPackageInfo.py", line 404, in obsoletesList
  File "rpcServer.py", line 110, in doCall
  File "repoDirector.py", line 27, in getObsoletes
  File "rpmSource.py", line 249, in getObsoletes
  File "/usr/share/rhn/up2date_client/repoBackends/aptRepo.py", line
157, in getObsoletes
    hdrList = rpm.readHeaderListFromFile(fileHdrList)
rpm.error: (2, 'No such file or directory')
Comment 1 Adrian Likins 2003-12-08 17:30:43 EST
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. 
Comment 2 Andre Schlink 2003-12-09 07:43:18 EST
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')

Comment 3 Adrian Likins 2003-12-09 12:54:50 EST
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.
Comment 4 Andre Schlink 2003-12-10 02:56:14 EST
You're right. The mentionend links were in place but 
rm -rf /var/spool/up2date resolved the problem. 
Thank you very much.

Note You need to log in before you can comment on or make changes to this bug.