bug triage

bug triage

[Richard Hartmann]

found 161506 4.3.9-1
thanks

Is there any reason not to simply move the manpages
from (1) to (7)?
If there is not, is upstream interested in a patch?


Richard

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161506

Re: Bug triage

[Bart Schaefer]

On Dec 30,  4:23pm, Vincent Lefevre wrote:
}
} On 2008-12-30 14:15:35 +0000, Clint Adams wrote:
} > Sorry, what I had meant was
} > 
} >     if ! _deb_packages_cache_avail=(
} 
} This doesn't change anything either.

I think this is going to require an { ... } always { ... } block to be
sure that the cache variable is deleted on an interrupt.

Re: Bug triage

[Vincent Lefevre]

On 2008-12-30 14:15:35 +0000, Clint Adams wrote:
> On Tue, Dec 30, 2008 at 12:44:09PM +0100, Vincent Lefevre wrote:
> > > +    if _deb_packages_cache_avail=(
> > >        ${(f)"$(apt-cache --generate pkgnames 2>/dev/null)"}
> > > -    )
> > > +    ); then
> > > +      unset _deb_packages_cache_avail
> > > +    fi
> 
> Sorry, what I had meant was
> 
>     if ! _deb_packages_cache_avail=(

This doesn't change anything either.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug triage

[Clint Adams]

On Tue, Dec 30, 2008 at 12:44:09PM +0100, Vincent Lefevre wrote:
> > +    if _deb_packages_cache_avail=(
> >        ${(f)"$(apt-cache --generate pkgnames 2>/dev/null)"}
> > -    )
> > +    ); then
> > +      unset _deb_packages_cache_avail
> > +    fi

Sorry, what I had meant was

    if ! _deb_packages_cache_avail=(

Re: Bug triage

[Vincent Lefevre]

On 2008-12-30 13:38:12 +0100, Vincent Lefevre wrote:
> There's still the possibility to replace
> 
>   ${+_deb_packages_cache_installed} -eq 0
> 
> by
> 
>   -n "$+_deb_packages_cache_installed"

Oops, I meant:

  -z "$+_deb_packages_cache_installed"

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug triage

[Vincent Lefevre]

On 2008-12-30 04:55:14 +0000, Clint Adams wrote:
> Index: Completion/Debian/Type/_deb_packages
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Completion/Debian/Type/_deb_packages,v
> retrieving revision 1.8
> diff -u -r1.8 _deb_packages
> --- Completion/Debian/Type/_deb_packages	2 Nov 2008 14:12:29 -0000	1.8
> +++ Completion/Debian/Type/_deb_packages	30 Dec 2008 04:54:18 -0000
> @@ -6,9 +6,11 @@
>    if ( [[ ${+_deb_packages_cache_avail} -eq 0 ]] ||
>        _cache_invalid DEBS_avail ) && ! _retrieve_cache DEBS_avail;
>    then
> -    _deb_packages_cache_avail=(
> +    if _deb_packages_cache_avail=(
>        ${(f)"$(apt-cache --generate pkgnames 2>/dev/null)"}
> -    )
> +    ); then
> +      unset _deb_packages_cache_avail
> +    fi
>  
>      _store_cache DEBS_avail _deb_packages_cache_avail
>    fi

With "dpkg -s lib[TAB]", the problem is with
_deb_packages_update_installed and the variable
_deb_packages_cache_installed, even though I suppose that the
other functions are affected by the same bug. Even if I add

  if [[ -z "$_deb_packages_cache_installed" ]]
  then
    unset _deb_packages_cache_installed
  fi

in _deb_packages_update_installed, the variable eventually gets
defined, and the bug still occurs. Perhaps this is due to the
cachevar=_deb_packages_cache_installed. But I don't know how the
function should end when the cache couldn't be filled up.

There's still the possibility to replace

  ${+_deb_packages_cache_installed} -eq 0

by

  -n "$+_deb_packages_cache_installed"

but this isn't the best solution.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug triage

[Vincent Lefevre]

On 2008-12-30 04:55:14 +0000, Clint Adams wrote:
> Index: Completion/Debian/Type/_deb_packages
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Completion/Debian/Type/_deb_packages,v
> retrieving revision 1.8
> diff -u -r1.8 _deb_packages
> --- Completion/Debian/Type/_deb_packages	2 Nov 2008 14:12:29 -0000	1.8
> +++ Completion/Debian/Type/_deb_packages	30 Dec 2008 04:54:18 -0000
> @@ -6,9 +6,11 @@
>    if ( [[ ${+_deb_packages_cache_avail} -eq 0 ]] ||
>        _cache_invalid DEBS_avail ) && ! _retrieve_cache DEBS_avail;
>    then
> -    _deb_packages_cache_avail=(
> +    if _deb_packages_cache_avail=(
>        ${(f)"$(apt-cache --generate pkgnames 2>/dev/null)"}
> -    )
> +    ); then
> +      unset _deb_packages_cache_avail
> +    fi
>  
>      _store_cache DEBS_avail _deb_packages_cache_avail
>    fi

This changes nothing.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Bug triage

[Clint Adams]

On Mon, Dec 29, 2008 at 06:40:33PM -0500, Matt Wozniski wrote:
> Seems that not defining the variable when the function that defined it
> was interrupted would be best, if it's not too tough to implement.
> Regarding an empty variable as invalid is still better than allowing
> an empty variable, but depending on the code (which I haven't looked
> at) it might be able to create a variable holding only part of a valid
> cache.
> 
> Just something to think about.

I don't know.  How about

Index: Completion/Debian/Type/_deb_packages
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Debian/Type/_deb_packages,v
retrieving revision 1.8
diff -u -r1.8 _deb_packages
--- Completion/Debian/Type/_deb_packages	2 Nov 2008 14:12:29 -0000	1.8
+++ Completion/Debian/Type/_deb_packages	30 Dec 2008 04:54:18 -0000
@@ -6,9 +6,11 @@
   if ( [[ ${+_deb_packages_cache_avail} -eq 0 ]] ||
       _cache_invalid DEBS_avail ) && ! _retrieve_cache DEBS_avail;
   then
-    _deb_packages_cache_avail=(
+    if _deb_packages_cache_avail=(
       ${(f)"$(apt-cache --generate pkgnames 2>/dev/null)"}
-    )
+    ); then
+      unset _deb_packages_cache_avail
+    fi
 
     _store_cache DEBS_avail _deb_packages_cache_avail
   fi

Re: Bug triage

[Richard Hartmann]

On Tue, Dec 30, 2008 at 00:35, Vincent Lefevre <vincent@vinc17.org> wrote:

> found 381842 4.3.6-7

For easy reference:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381842


> I can reproduce it all the time on my powerpc machine, but not on
> x86_64 (but perhaps because this x86_64 machine is so fast I cannot
> type Ctrl-C early enough).

I thought I was fast enough (I had several cpuburn instances & bonnie++
running while trying it); sorry :/


Richard

Re: Bug triage

[Matt Wozniski]

On 12/29/08, Vincent Lefevre wrote:
> reopen 381842
>  found 381842 4.3.6-7
>  thanks
>
>  On 2008-12-29 22:11:49 +0100, Richard Hartmann wrote:
>  > I am triaging bugs against zsh in Debian's BTS.
>  > zsh 4.3.6 does not show this behaviour, any more.
>  >
>  > Re-open if I made a mistake, please.
>
>  The bug occurs when one types Ctrl-C at the first dpkg completion
>  (e.g. "dpkg -s lib[TAB]"), and before zsh could find the possible
>  matches. A shell variable _deb_packages_cache_installed gets defined
>  but contains nothing.
>
>  I can reproduce it all the time on my powerpc machine, but not on
>  x86_64 (but perhaps because this x86_64 machine is so fast I cannot
>  type Ctrl-C early enough).
>
>  I can also reproduce it on my Nokia N810 with a zsh 4.3.9 I compiled.
>
>  I don't know how this can be fixed, but something like: do not
>  define this variable when the function that computed this cache
>  had been interrupted, or regard an empty variable as an invalid
>  cache.

Seems that not defining the variable when the function that defined it
was interrupted would be best, if it's not too tough to implement.
Regarding an empty variable as invalid is still better than allowing
an empty variable, but depending on the code (which I haven't looked
at) it might be able to create a variable holding only part of a valid
cache.

Just something to think about.

~Matt

Re: Bug triage

[Vincent Lefevre]

reopen 381842
found 381842 4.3.6-7
thanks

On 2008-12-29 22:11:49 +0100, Richard Hartmann wrote:
> I am triaging bugs against zsh in Debian's BTS.
> zsh 4.3.6 does not show this behaviour, any more.
> 
> Re-open if I made a mistake, please.

The bug occurs when one types Ctrl-C at the first dpkg completion
(e.g. "dpkg -s lib[TAB]"), and before zsh could find the possible
matches. A shell variable _deb_packages_cache_installed gets defined
but contains nothing.

I can reproduce it all the time on my powerpc machine, but not on
x86_64 (but perhaps because this x86_64 machine is so fast I cannot
type Ctrl-C early enough).

I can also reproduce it on my Nokia N810 with a zsh 4.3.9 I compiled.

I don't know how this can be fixed, but something like: do not
define this variable when the function that computed this cache
had been interrupted, or regard an empty variable as an invalid
cache.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)