On 08/26/2012 10:06 PM, Jeff Licquia wrote: > 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.
I'll check that and report back. > - 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. The use of CODENAME isn't built into unattended-upgrades, it read "origin patterns" from its configuration file which may contain variables like $distro_id or $distro_codename. Therefore, I don't think a general fallback would be feasible - what's sensible would depend on the user configuration. That said, it's of course possible to not use variables at all and just hardcode "testing" or "wheezy". Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
