On 08/11/2012 09:49 PM, Nikolaus Rath wrote: > Here we go: I've played with this a little, using the results from the dir listings (which don't look odd to me).
>From what I can tell, the ultimate cause of the failure is when apt decides to invalidate all repositories and "apt-cache policy" only reports the local dpkg database as a valid "repo". At that point, the code uses different logic to try and figure out the distro information, which doesn't include the CODENAME. So there are a number of ways to fix the problem: - When unattended-upgrades decides to stop working, I would bet that "apt-cache policy" only returns the "100 /var/lib/dpkg/status" package file. Figure out why that's happening and make it not happen, and I'm sure lsb_release would fall into line. - Assuming there's a good reason for "apt-cache policy" to do this, we might be able to do better at guessing the release. We read /etc/debian_version, and understand versions like "wheezy/sid" (its current contents as of today). We parse off the "/sid" and keep hold of the prefix (so long as it's not "testing"), but if the apt check fails, we end up just discarding it. We might be able to fall back to something like parsing sources.list to determine if we're running sid or not, and based on that, set the CODENAME. - Of course, another way to fix this would be for unattended-upgrades to be a little more robust about a missing CODENAME; maybe it could use some fallback, or a different value from the info returned by get_distro_information(), or something. Anyone want to weigh in on which is the best solution? (or point out where I'm totally off base) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org