crash during second scan

[Megaqwerty]

Falcon always crashes during the second time it scans my repository (it always succeeds the first time) with this output:

Falcon repository manager 2.0.4 (C)2005-2008 Dennis Kaarsemaker <email address hidden>
* Scanning component 'gutsy-megabuntu/all'

 === ERROR! ===

An error occured in falcon. This is probably a bug in the software.
Please file a bug at https://launchpad.net/falcon/+filebug and
include the following backtrace:

Traceback (most recent call last):
  File "/usr/bin/falcon", line 235, in ?
    component.scan(clean = action=='clean')
  File "/usr/lib/python2.4/site-packages/falcon/plugin.py", line 157, in wrapped_func
    result = func(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/falcon/pocket.py", line 186, in scan
    files.remove(f)
ValueError: list.remove(x): x not in list

[Dennis Kaarsemaker (dennis)]

Thanks for reporting this bug, can you please post the output of ls -laR pool and the .falcon/data file?

[Megaqwerty (matthewb)]

The output is kinda big, but here is the "ls -laR pool" output.

[Megaqwerty (matthewb)]

and the .falcon/data file.

[Dennis Kaarsemaker (dennis)]

You removed the source for alien-arena from your pool after the first scan. The second scan wants it to be there. It is a bug that falcon crashes on this, but you really should leave the sources in place anyway :)

[Megaqwerty (matthewb)]

What's weird about that is that after deleting my .falcon/data file, and running the scan, then running the scan immediately afterwards, it crashed the second time (with no deletion in the pool between these two time periods.) I'm going to rebuild the alien-arena package (as well as source files) and see if I still get the error. At least it's narrowed down to just that package.

[Dennis Kaarsemaker (dennis)]

Hmm, that would be a more serious bug. I will check this. Falcon 2.0.5 will be released tomorrow and hopefully include a fix for this.

[Megaqwerty (matthewb)]

Yes, I can confirm that it still does this. For the time being, I'll just use your workaround you used in bug #182219 which involves dropping the source and binary package tables, seeing as it works fine during the first scan.

[Dennis Kaarsemaker (dennis)]

The first scan does store wrong information though :)