Hi, On Fri, 22 Mar 2013, Didier 'OdyX' Raboud wrote: > > No LSB modules are available. > > Distributor ID: Debian > > Description: Debian GNU/Linux Kali Linux 1.0 > > Release: Kali Linux 1.0 > > Codename: n/a > > You're saying that the wrong line is "Distributor ID" (the output of > lsb_release -i), right ?
Yes, but description looks wrong too. It could use the PRETTY_NAME from /etc/os-release instead of making up something weird. > > 3/ /etc/dpkg/origins/default if none of the above exist > > 4/ some wild guess based on APT otherwise > > > > Please let me know if you need help. > > From what I can see in the code, the current logic is the following: > 1/ /etc/lsb-release - get_lsb_information() > 2/ 'Debian' - guess_debian_release() Yes. > That said, /etc/os-release is not used anywhere in lsb(-release) yet, so I'm /etc/os-release has been promoted as a vendor-neutral file on which we should standardize. I believe it would be a good idea to use it. > open to implement "3/ /etc/dpkg/origins/default" parsing for now, but would > rather avoid parsing os-release only for ID (but help is welcome). Also, I'm > yet to see an advantage for apt parsing where dpkg origins are already > supposed to provide the correct information (as derivatives are supposed to > fork base-files anyway). I also don't see the value on the APT parsing but I saw code for this so I left it in my list. > I'll see if I can get a patch for "3/ /etc/dpkg/origins/default" parsing > soon, > but I welcome help there too. reportbug has some python code parsing that file in /usr/share/pyshared/reportbug/debbugs.py Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org