Re: lsb-release: please review for release exception
Hi Chris,
On Wed, Nov 15, 2006 at 06:33:03PM -0600, Chris Lawrence wrote:
> On 11/15/06, vagrant+bugs@freegeek.org <vagrant+bugs@freegeek.org> wrote:
> >i am wondering if this bug should be considered RC, as it makes
> >lsb_release unable to report that is is running etch:
> >lsb_release -a
> >No LSB modules are available.
> >Distributor ID: Debian
> >Description: Debian GNU/Linux 4.0 (n/a)
> >Release: 4.0
> >Codename: n/a
> >this bug is present in the version of lsb-release in etch (3.1-15) and
> >though it is fixed in unstable, lsb is frozen, and may require a
> >release exception to propegate to etch.
> I am preparing a new upload at the moment that fixes the two big
> outstanding bugs in 3.1-19, including this issue; that's probably what
> should propogate into etch (and there are a series of bugs fixed
> between 3.1-16 and -20 that should make it in anyway).
Reviewing the diff between -15 and -20, I notice this change in
init-functions:
if [ "x$TERM" != "xdumb" ] && [ -x $TPUT ] && [ -x $EXPR ] && $TPUT hpa 60 >/dev/null 2>&1 && $TPUT setaf 1 >/dev/null 2>&1; then
- FANCYTTY=1
- true
+ [ -z $FANCYTTY ] && FANCYTTY=1
else
FANCYTTY=0
- false
fi
+ case "$FANCYTTY" in
+ 1|Y|yes|true) true;;
+ *) false;;
+ esac
The addition of the [ -z $FANCYTTY ] && FANCYTTY=1 isn't going to work right
under set -e; if FANCYTTY is non-empty for whatever reason, then [ -z
$FANCYTTY ] returns false -- and short-circuits, causing the function to
return false immediately instead of returning true farther down as intended.
Do you want to upload a fix for this, or should I go ahead and approve -20
as-is? This is minor and the rest of the diff looks fine, so I have no
problem hinting -20 in.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: