Bug 1324787 - sqlite packages in el5 seems to be broken
Summary: sqlite packages in el5 seems to be broken
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: sqlite
Version: el5
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Itamar Reis Peixoto
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-07 09:51 UTC by Dennis Moers
Modified: 2017-04-06 10:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-06 10:05:07 UTC
Type: Bug


Attachments (Terms of Use)

Description Dennis Moers 2016-04-07 09:51:33 UTC
Description of problem:
Any yum commands end with the prompt "Error: no such table: packages". A google research tells me to clean up the yum cache and try again but this process does not help in any way.

Steps to Reproduce:
1. yum clean all
2. yum makecache
3. yum check-updates

At the third step I got the following stack trace:

Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 309, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 178, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 345, in doCommands
    self._getTs(needTsRemove)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 101, in _getTs
    self._getTsInfo(remove_only)
  File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 112, in _getTsInfo
    pkgSack = self.pkgSack
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 662, in <lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 502, in _getSacks
    self.repos.populateSack(which=repos)
  File "/usr/lib/python2.4/site-packages/yum/repos.py", line 260, in populateSack
    sack.populate(repo, mdtype, callback, cacheonly)
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 168, in populate
    if self._check_db_version(repo, mydbtype):
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 226, in _check_db_version
    return repo._check_db_version(mdtype)
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 1226, in _check_db_version
    repoXML = self.repoXML
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 1399, in <lambda>
    repoXML = property(fget=lambda self: self._getRepoXML(),
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 1391, in _getRepoXML
    self._loadRepoXML(text=self)
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 1381, in _loadRepoXML
    return self._groupLoadRepoXML(text, ["primary"])
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 1366, in _groupLoadRepoXML
    self._commonRetrieveDataMD(mdtypes)
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 1343, in _commonRetrieveDataMD
    misc.bunzipFile(dl_local, local)
  File "/usr/lib/python2.4/site-packages/yum/misc.py", line 615, in bunzipFile
    data = s_fn.read(1024000)
EOFError: compressed file ended before the logical end-of-stream was detected

Regarding this stack trace and the fact I am using a clean cache I would suggest that something is not build properly so that it is not possible to decompross it. Furthermore I have added a simple "print source" in "/usr/lib/python2.4/site-packages/yum/misc.py". So I got an output regarding sqlite.

epel                                                                                                                                                                                                                  | 3.6 kB     00:00
epel/primary_db                                                                                                                                                                                                       | 2.9 MB     00:00
/var/cache/yum/epel/db9985946b749cb63ab71416a79b1c382c449d3a-primary.sqlite.bz2
...
stack trace as you can see above.

Comment 1 Fedora End Of Life 2017-04-06 10:05:07 UTC
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5
is no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
or Fedora EPEL, please feel free to reopen this bug against that version. If
you are unable to reopen this bug, please file a new report against the current
release. If you experience problems, please add a comment to this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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