Bug#934926: [Pkg-zsh-devel] Bug#934926: update (overridding of default fpath causes uncessary complexity and pain for software providing zsh completions)

[Frank Terbeck]

Axel Beckert wrote:
[…]
>> With that, we could add the prefix based site-functions directory,
>> but deprecate its use.
>
> Ack, that thought came to me also after having read your mail
> half-through. It though has the danger that some so far not active
> plugins will suddenly start to work. So we add least need to
> debian/zsh.bug-script.
>
> Currenty it only checks for packages that ship files in
> /usr/share/zsh/vendor-completions/ and
> /usr/share/zsh/vendor-functions/.

True. Although "normal" function don't get activated automatically. Only
files that match ‘_*’ in $fpath get activated automatically by compinit,
if the user calls that function in their configuration files.


>> That way, packages that disrespect the zsh package's policy still
>> work, while keeping the possibility of a clean system, in case all
>> package adhere to the policy. We could file a bunch of bugs for the
>> packages that are currently using /usr/share/zsh/site-functions
>> right now.
>
> Debian prefers lintian warnings over mass bug filing. Mass bug filing
> needs to be discussed on the debian-devel mailing list first.

That is fair.


> What I now still wonder to (hopefully) address Joey's issue:
>
> Is there a way to build the Debian zsh (respectively probably the
> zsh-dev) package in a way so that locally installed Zsh extensions get
> cleanly installed into /usr/local/ while Debian packages still install
> stuff to /usr/ (preferably these vendor-* directories)?

Well, I  am not sure what  "plugins" do in terms  of installation proce-
dures. The  only such package that  I have written¹ ships  a script that
asks you for a directory that it should use for deployment.

If I were to do some sort of automatic site-local installation, I'd pro-
bably install to this: zsh -c '${fpath[1]}'


> I wonder if something like a dh_zsh helper could help here (i.e. for
> the vendor-* directory part) as well.

I suppose we could make it do this:

Install files from the source  directory, that are not generally instal-
led by  the upstream installation  process. I  think that this  is still
more often than not the case:

  dh_zsh -c -s examples/_foobar contrib/_quux
  dh_zsh -f -s examples/some-function


Similarly, move functions from the in the packaging root directory, in
case things get installed by the upstream installation procedure:

  dh_zsh -c -p /usr/local/share/zsh/site-functions/_foobar
  dh_zsh -f -p /usr/share/zsh/site-functions/some-function

The mnemonics here are:

  -c → Completion system function; put into vendor-completions
  -f → General, auto-loadable function file.
  -s → From Source directory
  -p → From package root directory.

I suppose we could also add a ‘-r’ option to make the process recursive.


In addition, we  could add an automatic mode for  stuff in the packaging
root directory, if called without  arguments, which should fix naïve in-
stallation procedures automatically, due to zsh's convention about names
for completion functions:

  - Scan these directories:
- /usr/local/share/zsh/site-functions
- /usr/share/zsh/site-functions
  - Move files matching ‘_*’ to vendor-completions
  - Move the other files to vendor-functions.
  - Remove those two directories (they should be empty now)


I think that should support most installation schemes.


WDYT?


Regards, Frank

Bug#934926: update

[Frank Terbeck]

Daniel Shahaf wrote:
[…]
> - Packages that are part of Debian should install to
>   /usr/share/zsh/vendor-*.
>
> - Upstream packages have three options:
>
>   + Install to /usr/local/share/zsh/site-functions (regardless of their
> own $PREFIX _and_ of zsh's $PREFIX)

This is precisely  the right fpath entry for site  local function files.
The Debian package set this to a /usr/local directory even when configu-
red with --prefix=/usr since before the current team took over.

This  is the  right thing  to do  in any  case, since  non-package files
should just be dropped into /usr/share/.

We  *added* the  ‘vendor-*’ directories  to get  fpath entries  that are
under the control of the package  system for packages to drop additional
functions into. It's been this way since about 2011.

A couple of years later (2014-ish) zsh upstream changed its compile time
configuration semantics  with respect  to site-function  directories: It
now ensures  that /usr/local/share/zsh/site-functions is  *always* there
and on top of the fpath variable.

This acknowledges  that /usr/local/  is the right  place for  site local
additions, which I don't think anybody disputes.

The change  in handling site-function  directories is that  compile time
configuration  also  adds a  PREFIX/share/zsh/site-functions  directory,
with lower priority than the one in /usr/local.

The reason  this doesn't  get added  on Debian right  now is  that we're
still  setting ‘--enable-site-fndir=/usr/local/share/zsh/site-functions’
explicitly. Dropping this setting would change this.

Since  Debian's ‘vendor-*’  directory handling  predates this  by years,
changing this,  effectively adding  a second path  for the  same purpose
seems inelegant, since it adds redundancy where none is needed.

This however, sucks:

% apt-file search usr/share/zsh/site-functions/ | wc -l
30

Because that is thirty functions that will not work.

When we  added the ‘vendor-*’ stuff,  we filed bug reports  for packages
that  tried this,  because  even  back then,  it  wouldn't have  worked,
because site-functions always was in /usr/local with Debian's zsh.

That resulted in this:

% apt-file search vendor-completions | wc -l
166


I am  not sure if  there's an elegant way  to resolve this,  because the
‘vendor-*’ directories  are the documented  way for zsh packages  to add
functions for more than a decade. I  don't think dropping them is a good
idea, because it would break backward compatibility. And as I said, just
adding the second  --prefix based site-functions entry  would litter the
system by added multiple destinations for the same purpose.

Maybe there's a way to add a  lintian check for the installation path of
zsh function files in Debian packages.  With that, we could add the pre-
fix based  site-functions directory,  but deprecate  its use.  That way,
packages  that disrespect  the zsh  package's policy  still work,  while
keeping the possibility of a clean system, in case all package adhere to
the policy. We could file a bunch of bugs for the packages that are cur-
rently using /usr/share/zsh/site-functions right now.


Regards, Frank

Bug#970848: Problem with path to completion scripts

[Frank Terbeck]

Georgy Komarov wrote:
> I encountered with a problem, when trying to use custom zsh completions.

As debian/README.Debian states:

Load-path for functions from other packages
---

In respsonse to #620452, the zsh-binary from Debian's zsh package started to
provide two entries to $fpath (the search path for loadable functions) for
other packages to drop function files into:

  - /usr/share/zsh/vendor-completions for functions that add functionality to
zsh's function based completion system (compsys)

  - /usr/share/zsh/vendor-functions for all other functions

If you maintain another Debian package that wants to add functions to zsh's
function load-path, please use the those conventions when installing function
files.

Bug#921236: [Pkg-zsh-devel] Bug#921236: Bug#921236: zsh: provide equivalent of dh_bash-completion

[Frank Terbeck]

Daniel Shahaf wrote:
> [...] and autoloadable
> functions (first line is "#autoload") to /usr/share/zsh/vendor-functions;
> both of these paths are Debian-specific.  I suggest that, at least for
> now, you manually install the files to these paths.

vendor-functions takes any sort of zsh function file, "#autoload" or
manually loaded.

Bug#622933: [Pkg-zsh-devel] Bug#622933: zsh: Enable completions by default, unless skip_global_compinit is set

[Frank Terbeck]

Hi,

TS wrote:
[...]
> Replying here because i think the patch that never got applied
> should look like:

In the meantime (it's been more  than seven years), I've changed my mind
about this.  I think a vendor should  do as little as  possible in their
global configuration files. We already do a fair bit with regard to key-
board setup.¹ But compsys is much more expensive in  comparison, and al-
most all zsh user will call this  in their zshrc file anyway. And all of
those people, we'll force  to create a .zshenv file just  to to revert a
change in a vendor file.

In short, I am firmly against doing this.


Regards, Frank

¹ A case could be made that this is overstepping the boundaries already.
  And maybe that's  true. Getting keyboard handling in  a terminal right
  is a hard task, however. It  requires intimate knowledge about some of
  the subtleties of how terminals work  and about the facilities zsh of-
  fers to work with  those. It would be much better, if  zsh did some of
  this out  of the box,  but alas it doesn't.  (The rationale is  to not
  break existing setups — and that's a valid argument, too.)

Bug#898619: [Pkg-zsh-devel] Bug#898619: Bug#898619: zsh autocompletion does not deal gracefully with upgrades in the background

[Frank Terbeck]

Axel Beckert wrote:
> Philipp Kern wrote:
[...]
>> My gut feeling is that this is because I did not autocomplete in the
>> old shell yet but now the module is gone.
>
> Yes, that's the same conclusion I came to.
>
>> At least with a new shell complist.so is only in /proc/$$/maps after
>> an attempted completion.

Yes, modules are loadable at run-time.

>> Would it be possible to make sure that the autocompletion system
>> loads the module on startup rather than on-demand?

Zsh is  setup to  do lots  of things  on demand.  It would  certainly be
conceivable  to be  more gracious  about  the issue.  But when  versions
upgrade, I don't  think it's unreasonable to restart a  shell, like Axel
mentioned via "exec zsh".

If you'd really like that module loaded all the time, you can load it in
your setup. Personally, I'm loading a bunch of modules at startup time.


Regards, Frank

Bug#879187: zsh-completion: add --clean for vim

[Frank Terbeck]

Hello Christian,

Christian Brabandt wrote:
[...]
> Vim since patchlevel 8.0.0716 includes the --clean argument for starting 
> in a clean mode (only loading defaults.vim and in non-cp mode). So 
> please add this patch to the vim completion.
[...]
> --- _vim.backup   2017-10-20 08:48:15.615046979 +0200
> +++ _vim  2017-10-20 08:52:07.185668608 +0200
> @@ -74,6 +74,7 @@
[...]
> +  '--clean[start with defaults in non-compatible mode]'

Thanks, I've submitted this one to zsh-workers (zsh requires patches
against its codebase to go through its mailing lists, except for truly
trivial changes).

I'll commit it upstream as soon as the mail makes it back.


Regards, Frank
-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925

Bug#859070: [Pkg-zsh-devel] Bug#859070: /bin/zsh: status of resumed background jobs incorrectly listed as 'unknown signal (core dumped)'

[Frank Terbeck]

Axel Beckert wrote:
>> Here's the upstream commit:
>> 
>> commit 12d950ba0cc345d047c94c9d94325dbfe47fc79d
>> Author: Barton E. Schaefer 
>> Date:   Thu Feb 23 16:19:07 2017 -0800
>
> Indeed looks small.
>
> Daniel, Frank: Do we have to expect any side effects from
> cherry-picking that commit for 5.3.1?

The signals code has always been hairy  (as with any code base I'd say).
That change  looks right to  me (with my  limited knowledge of  the code
paths in question), and possible side effects should be harmless.

No guarantees, of course. :)


Regards, Frank
-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925

Bug#844095: fdm: please make the build reproducible

[Frank Terbeck]

Hi,

Reiner Herrmann wrote:
> While working on the "reproducible builds" effort [1], we have noticed
> that fdm could not be built reproducibly. It collects source files
> with "echo *.c", which varies with different locales. This causes a
> different order of objects during linking.

Thanks! Commendable effort, you guys are pursuing there. This is just to
let you know, I've seen the bug; but I won't be able to do anything
about it before the upcoming weekend. I well get to it eventually,
though.


Regards, Frank

Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

[Frank Terbeck]

Hey,

Martin Steigerwald wrote:
>> On a tangent: what do "nyae" mean?  I couldn't find the answer in the
>> manual.
>
> I thought about this as well.

This would be:

(Y)es, (N)o, (A)bort, (E)dit.


Regards, Frank

Bug#843582: 0xffff: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: 0x
Version: 0.6.1-3
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

0x seems to use:

  /usr/share/zsh/functions/Completion/Unix/_0x

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843576: taskwarrior: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: taskwarrior
Version: 2.5.1+dfsg-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

taskwarrior seems to use:

  /usr/share/zsh/functions/Completion/Unix/_task

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843581: python3-doit: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: python3-doit
Version: 0.28.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

python3-doit seems to use:

  /usr/share/zsh/functions/Completion/Linux/_doit3

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843578: dochelp: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: dochelp
Version: 0.1.3+b1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

dochelp seems to use:

  /usr/share/zsh/functions/Completion/Debian/_dochelp

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843573: herbstluftwm: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: herbstluftwm
Version: 0.7.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

herbstluftwm seems to use:

  /usr/share/zsh/functions/Completion/X/_herbstclient

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843580: autojump: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: autojump
Version: 22.5.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

autojump seems to use:

  /usr/share/zsh/functions/Completion/Unix/_j

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843575: ninja-build: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: ninja-build
Version: 1.7.1-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

ninja-build seems to use:

  /usr/share/zsh/functions/Completion/_ninja

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843579: python-doit: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: python-doit
Version: 0.28.0-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

python-doit seems to use:

  /usr/share/zsh/functions/Completion/Linux/_doit

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843577: nikola: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: nikola
Version: 7.6.4-1
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

nikola seems to use:

  /usr/share/zsh/functions/Completion/Linux/_nikola

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843574: sup-mail: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: sup-mail
Version: 0.22.1-2
Severity: normal

Dear Maintainer,

Debian's zsh package offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

sup-mail seems to use:

  /usr/share/zsh/functions/Completion/Unix/_sup

Please consider using the dedicated directory instead.

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank — on behalf of the pkg-zsh team.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#843483: torsocks: Zsh completion should be deployed to /usr/share/zsh/vendor-completions

[Frank Terbeck]

Package: torsocks
Version: 2.2.0-1
Severity: normal

Dear Maintainer,

Debian's zsh packages offers a dedicated directory for other packages to
put additional completion function files into. That directory is:

  /usr/share/zsh/vendor-completions

Torsocks seems to use:

  /usr/share/zsh/functions/Completion/Unix/_torsocks

See the zsh package's README for details:

  https://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/README.Debian

Regards, Frank

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages torsocks depends on:
ii  libc6  2.24-5

Versions of packages torsocks recommends:
ii  tor  0.2.8.9-1

torsocks suggests no packages.

-- no debconf information

Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Frank Terbeck]

Hi,

Michael Biebl wrote:
[...]
 martin@merkaba:~> systemctl status

 ^[[0;1;31m●^[[0m merkaba

 State: ^[[0;1;31mdegraded^[[0m
 
  Jobs: 0 queued

Failed: 2 units

I can't reproduce this.

If zsh changed its terminal to behave like that, no coloured output
would work at all. This smells a lot like broken configuration.

Please provide a minimal example, that triggers the problem (freshly
started terminal, preferably xterm, and freshly started zsh, with only
as much configuration as to trigger the problem). If it is indeed a
problem, that zsh is responsible for, we can talk.


Regards, Frank

Bug#828180: zsh: $RANDOM number generator is not reset for subshells

[Frank Terbeck]

Ben Longbons wrote:
> Dear Maintainer,

Hi Ben,

> Zsh just repeats the same number when $RANDOM is requested in fresh
> subshells. In general, this sort of bug is a security vulnerability,
> though I'm not aware of anyone doing security-sensitive stuff in zsh.

This works exactly as documented and is therefore not a bug:

RANDOM 
A  pseudo-random  integer  from 0 to 32767, newly generated each
time this parameter is referenced.  The random number  generator
can be seeded by assigning a numeric value to RANDOM.

The   values   of   RANDOM   form   an  intentionally-repeatable
pseudo-random sequence; subshells  that  reference  RANDOM  will
result  in  identical  pseudo-random  values unless the value of
RANDOM is referenced or seeded in the parent  shell  in  between
subshell invocations.

This comes up on zsh's mailing list every once in a while. Here is a
recent-ish thread: http://www.zsh.org/mla/workers/2015/msg00549.html

> bash handles this correctly in variables.c by checking
> `subshell_environment && seeded_subshell != pid` on every call and
> reseeding then; it would also be possible to use `pthread_atfork` (or,
> since the forking is entirely within the main executable, just the
> manual equivalent at the call site).

There is no standard that mandates how $RANDOM should behave. So this
boils down to "zsh is no bash".


Regards, Frank

Bug#823093: zsh-common: Zsh config files are stored in /etc/zsh instead of /etc/zsh.d, which is more expected by users

[Frank Terbeck]

Hi,

Christopher Slojkowski wrote:
> Zsh files are stored in /etc/zsh, they should be stored in /etc/zsh.d instead.
> This is more consitant with other directories. I included a patch which makes
> the new folder, moves, and creates a symlink. There is proabably a better
> solution, but I just created a quick hack.

I disagree. Usually, the use of .d directories signifies that all files
from such a directory are being loaded by an application. That is not at
all the case with /etc/zsh.

Also, this is longstanding behaviour with the debian package and, as
far as I am concerned, this is not going to change.


Regards, Frank

Bug#790535: susv4: fails to install: post-installation script returned error exit status 1

[Frank Terbeck]

Hello maintainer!

I just tried to install the "susv4" package on my system and it revealed
the following issue, which I believe was mentioned in the bug id I am
reopening right now.

Note, that I tried to install "susv2" and "susv3" and neither of those
packages had any problems of that kind.


Regards, Frank


i-(6007)-~% apt-get install susv4
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  susv4
0 upgraded, 1 newly installed, 0 to remove and 56 not upgraded.
Need to get 0 B/3,088 B of archives.
After this operation, 15.4 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package susv4.
(Reading database ... 319792 files and directories currently installed.)
Preparing to unpack .../susv4_7.20150719_all.deb ...
Unpacking susv4 (7.20150719) ...
Processing triggers for doc-base (0.10.6) ...
Processing 1 added doc-base file...
Error in `/usr/share/doc-base/susv4', line 9: all `Format' sections are invalid.
Note: `install-docs --verbose --check file_name' may give more details about 
the above error.
Setting up susv4 (7.20150719) ...
Fetching file...
--2016-01-06 14:06:16--  
http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4tc1.tar.bz2
Resolving pubs.opengroup.org (pubs.opengroup.org)... 69.80.200.148
Connecting to pubs.opengroup.org (pubs.opengroup.org)|69.80.200.148|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 3638538 (3.5M) [application/x-bzip2]
Saving to: ‘/tmp/tmp.CEtMv9qZZX/susv4tc1.tar.bz2’

susv4tc1.tar.bz2100%[=>]   3.47M  
56.7KB/sin 41s

2016-01-06 14:06:58 (87.2 KB/s) - ‘/tmp/tmp.CEtMv9qZZX/susv4tc1.tar.bz2’ saved 
[3638538/3638538]

Verifying SHA512 checksum...
dpkg: error processing package susv4 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 susv4
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#720707: state of RFP: grml-zsh-config?

[Frank Terbeck]

Hi,

Disclaimer: Even though I am involved with grml's setup a great deal, I
never was a big fan of packaging it up for Debian. The reason for
that being mainly, that I am absolutely convinced that a vendor
should impose the least possible changes to a package as possible
and most certainly not impose a bunch of settings for every user on
a system.


Thomas Koch wrote:
> sorry, I wanted to ask you on Saturday: What's the state of the 
> grml-zsh-config 
> packaging for Debian? Could you provide a braindrop of the problems you're 
> aware of and what discussions have happened?

That being said, I just realised that there is actually nothing at all
missing for such a package. Zsh code like grml's setup doesn't belong to
/etc anyway. We could probably distribute it somewhere in /usr/share/zsh.

Then users who want the setup can just

  source /usr/share/zsh/cfg/grml-zshrc

and be done. We could even package a byte-compiled version of the setup.

I am still firmly against anything that would enable the setup per
default for everyone on a system.


Regards, Frank

Bug#794967: zsh: please enhance /etc/zshrc

[Frank Terbeck]

Hi!

Carsten Hey wrote:
 * Frank Terbeck [2015-08-08 23:46 +0200]:
[...]
 I firmly believe, that a vendor's *global* setup file should be as
 minimal as possible, which is why I really don't want to add anything
 that's more than making the zsh defaults behave more robustly across
 multiple terminals or deal with stuff specific to Debian.

 It looks like you changed your opinion since you wrote
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622933#10


Heh. I honestly don't even remember sending those mails. I do remember
the issue (ie. the fact that Ubuntu does compinit in the global zshrc),
but I thought my reaction had matched my reaction right now.


For the record, let it be known that the statement from my previous mail
in *this* thread is indeed my actual position in the matter. And it has
been for a while. I'm sure there is evidence of that in threads of other
bug reports that would show that.

Today I wouldn't take that code snippet from my own mail to enter our
setup. It's the wrong thing to do. I think they still do that in Ubuntu,
which is another reason why setopt no_global_rcs is part of my
personal zsh setup in my ~/.zshenv file.


Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756138: Bug#792703: zsh: please improve newuser.zshrc.recommended and add new prompt_debian_setup

[Frank Terbeck]

Hi Carsten,

I looked through the suggestions from your last mail; comments inline.

Carsten Hey wrote:
[...]
 I think #setopt no_beep and #stty -ixon should also be added to

The latter might better be replaced by zsh's no_flow_control option.

[...]
 This prompt color-scheme-able via zstyle.  If the variabale TERM is set to
 'dumb', colors are disabled, though.  You can invoke the prompt thus:

   prompt debian
   TERM=dumb prompt debian

You could also check something like a blacklist style, that could be a
list of term names (or better yet, patterns). That way you could
blacklist $TERMs like emacs for colours as well.

 To configure the prompt's colors, this command can be used (don't forget to
 run 'prompt debian' again to activate the changes):

   zstyle ':prompt:debian:*' STYLE COLOR

Good! I like it when people refrain from polluting the global parameter
name space just for prompt colours. This is good. :-)

[...]
 Displaying version control information via vcs_info and displaying the name of
 a Debian chroot is supported by this prompt, but only the latter is enabled by
 default.  To enable vcs_info with the user-context 'prompt_debian', run:

   add-zsh-hook precmd prompt_debian_precmd_vcsinfo

Makes sense.

[...]
   PROMPT='%B!%!%b '$PROMPT
   zstyle ':vcs_info:*' nvcsformats '%B%F{2}%(1j.j%j .)%(2L.L%L .)%b%f'

Maybe use a name rather than a number here: %F{green}

 EOF
 }

 prompt_debian_precmd_vcsinfo () {
 setopt localoptions noxtrace
 vcs_info prompt_debian || return $?
 }

 prompt_debian_setup () {
 prompt_opts=(cr subst percent)

 local 
 zstyle_pattern=:prompt:debian:${HOST:-unknown}:${USERNAME:-unknown}

 local pwd_max_length=60
 local pwd_max_subdirs=5
 local wrap_at_char='-25'

Maybe make these configurable via styles?


 local p_exit='${${options[printexitvalue]#on}:+%0(?..%? )}'
 local p_pwd=%${pwd_max_length}...%$(( pwd_max_subdirs + 1
   ))(~:.../:)%${pwd_max_subdirs}~%
 local p_space_or_newline=%${wrap_at_char}(l: :${prompt_newline})
 local p_vcsinfo='${vcs_info_msg_0_-}'
 local p_reset='%b%f%k'
 local p_2nd_newline=%1(l:%${wrap_at_char}(l..${prompt_newline}):)

I think that looks reasonable.

 if [[ ${TERM-} == dumb ]]; then
 PROMPT=$p_exit\${debian_chroot:+(\$debian_chroot)}%n@%m $p_pwd
 PROMPT+=$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%# 
 else
 # color config:
 local dircolor= usercolor= usercolor_root= exitcolor= exitcolor_root=
 zstyle -s $zstyle_pattern dircolor   dircolor
 zstyle -s $zstyle_pattern usercolor  usercolor
 zstyle -s $zstyle_pattern usercolor-root usercolor_root
 zstyle -s $zstyle_pattern exitcolor  exitcolor
 zstyle -s $zstyle_pattern exitcolor-root exitcolor_root
 : ${dircolor:=4} ${usercolor:=2} ${usercolor_root:=1}
 : ${exitcolor:=1} ${exitcolor_root:=2}

To set defaults you can do:

  zstyle -s $zstyle_pattern dircolor dircolor || dircolor=4

And again, maybe rather use names instead of numbers:

  zstyle -s $zstyle_pattern dircolor dircolor || dircolor=blue

You also don't need to initialise to the empty string in the local
above.


 PROMPT=%B%{%0(#:%F{$exitcolor_root}:%F{$exitcolor})%}$p_exit
 PROMPT+=%{%F{$dircolor}%}\${debian_chroot:+(}
 
 PROMPT+=%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}\${debian_chroot-}
 PROMPT+=%{%F{$dircolor}%}\${debian_chroot:+)}
 PROMPT+=%{%0(#:%F{$usercolor_root}:%F{$usercolor})%}%n@%m 
 PROMPT+=%{%F{$dircolor}%}$p_pwd%b%f
 PROMPT+=$p_space_or_newline$p_vcsinfo$p_reset$p_2nd_newline%B%#%b 

Assembling a non-trivial prompt like always looks unreadable. I've seen
worse than this.

 ##TODO uncomment if setopt transientrprompt works in a prompt function
 ## Ease copying multi-line commands with the mouse.
 ## http://www.zsh.org/mla/workers/2015/msg01767.html
 #local rps2color=$dircolor
 #setopt transient_rprompt

I don't understand this. transientrprompt can — and IMO should be —
set outside a prompt setup.

 #PS2='${${options[singlelinezle]#off}:+%_ }'

I'd do this in an if ...; then...; fi to improve readability.

 #RPS2=${RPS2:-%B%{%F{$rps2color}%}%^%f%b}

[...]
 # Autoload and configure vcs_info:
 # The format strings 'formats' and 'actionformats' should end with a space
 # to fit into the prompt's design.
 # Colors: 1:=red, 2:=green, 3:=yellow, 4:=blue, 5:=magenta, 6:=cyan, ...

Again, you can use the colour names instead of the numbers instead.

[...]

The contents of the .thisfiledoesnotexist file seems very similar to
the one of the prompt_debian_setup file. Attached by mistake?


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 

Bug#794967: zsh: please enhance /etc/zshrc

[Frank Terbeck]

Carsten Hey wrote:
[...]
  * Please add some additional keybindings, at least for the emacs keymap:

- bind PageUp ${terminfo[kpp]} to history-search-backward
- bind PageDown ${terminfo[knp]} to history-search-forward
- bind BackTabKey ${terminfo[kcbt]} to reverse-menu-complete

I firmly believe, that a vendor's *global* setup file should be as
minimal as possible, which is why I really don't want to add anything
that's more than making the zsh defaults behave more robustly across
multiple terminals or deal with stuff specific to Debian.

This is stuff for the recommended setup file.

  In terminfo(5), the capname cbt is described as back tab (P)
  and kcbt is described as back-tab key, therefore the suggested
  'BackTabKey' instead of 'BackTab' - even though grml confuses
  people that know terminfo(5) by using 'BackTab' as name.

By that logic, kpp would need to be mapped to PreviousPageKey. I think
the current naming is fine.

- Maybe F1 could invoke run-help?  But then the output of run-help
  w/o arguments should be more useful for new users.

- Red Hat maps or mapped space to magic-space, I think Debian should
  _not_ do this, but initially I thought that this would be a good
  idea.

Again, this fits into the recommended setup file

  * $key should be unset unless there is a reason for not doing so.

The reason I left it set, is because its layout matches the $key
dictionary, that zsh's zkbd function produces and can be used as a
drop-in replacement. I still think that's a reasonable idea, even though
it slightly violates the A vendor's global setup needs to be minimal
rule.

  * (( ${+aliases[run-help]} )) requires the zsh/parameter module.  If,
in rare cases, possibly involving zsh-static, there is a chance that
this module is not loaded successfully, you should consider doing
this instead to remove the alias w/o error message:

  alias run-help=
  unalias run-help

That's a good point. I think we can do it like this:

unhash -a -m 'run-help' || true

-a removes alias from its hash table. -m uses the argument as a pattern.
Since there's no character that's significant to pattern matching, this
will work. This way, there is no error message. The '|| true' is to make
sure the setup file exits with successful status.

We could also just do this:

unalias run-help 2/dev/null || true

…if that's more straight-forward to read.


Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#794968: zsh: please clear console on logout (if recommended config is used)

[Frank Terbeck]

Carsten Hey wrote:
 Please clear console on logout if the recommended config for new users
 is used.

I think this should be doable with a zshexit hook like this:

function debian_clear_upon_exit () {
clear
}
add-zsh-hook zshexit debian_clear_upon_exit

That hook could be installed in the recommended setup file.

Disclaimer: I didn't try this. :-)


Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780531: zsh: tail -F does not complete file names

[Frank Terbeck]

Hello Sebastian,

Sebastian Ramacher wrote:
[...]
 The completion for tail -f  correctly completes files, but it does not for
 tail -F . tail -F tab displays completing -f and and nothing else. I'd
 also expect to get completing files there.

Zsh does not supply a completion function for tail. Thus, it should fall
back to file-completion for programs it doesn't know for any better.

You can try this:

% zsh -f
% autoload -Uz compinit; compinit
% tail -F tab

and try to reproduce the issue with a clean zsh instance with just the
completion system loaded. You'll see that you can't; because I can't.

My guess is, that you've got a completion handler configured for tail.

Like ‘_gnu_generic’. Try this (from a failing shell of yours):

% print ${_comps[tail]}

and that will most likely print ‘_gnu_generic’.


Long story short: This is not a bug in Debian's zsh package. But rather
in your configuration, since it assumes _gnu_generic can handle the
--help output of current GNU tail versions. Which it apparently can't.

You could argue, that this might be considered a bug in zsh's
_gnu_generic function; but really, that's a hack to try and parse
completion information from --help of any given command you assign to
it. If that output changes in an incompatible way, the function is
screwed. It's a best-guess solution rather than something sustainable.

I would suggest dropping the completion function assignment from your
configuration.


Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776964: Headers installed by zsh-dev packages miss critical pieces

[Frank Terbeck]

Hey there!

ZyX wrote:
[...]
 To use zsh headers in some module at least `config.h` file is needed

Finally, someone who actually wants to use zsh's facilities to load
third party modules. Yay. ;)

 in addition to those already present in the package. `config.h` files
 contains defines guessed by ./configure script and including it prior
 to `zsh.h` is the only sane variant to include `zsh.h` (insane variant
 is using module’s own configure script which will create those
 defines). Without `config.h` including `zsh.h` will fail due to
 missing defines, and even if it was not failing it would make #include
 zsh.h do the wrong thing because of the bits like
[...]

I agree.

 (configure.h-driven definition of zlong and zulong which has the potential of 
 breaking ABI compatibility in some cases).

 In addition to this file it is good to have a patched `zsh.mdh` file
 which glues together all zsh includes and is a single entry point.
 Patch needed to include this file in the distribution may be performed
 with the following script:

   for file in Src/{zsh.mdh,*.h} ; do

We'd probably want to do that in a POSIX compatible way, so we'd refrain
from using brace expansion but that's just cosmetics.

   sed -i 's@\.\./config\.h@config.h@' $file
   sed -i 's@#\(\s*\)include \([^]\+\)@#\1include zsh/\2@' 
 $file

Sed's -i option requires GNU sed. But then, I don't know if debian even
ships another version of sed. ...I think it doesn't; but I also don't
know about the policy with respect to non-POSIX features in packaging.

   done

 . I am doing this in a Gentoo ebuild and the result works just fine.

Yeah, I think this could work.

Do you think it would make sense to include the other header files with
zsh-dev as well? Like zshterm.h etc?


Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776663: Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

[Frank Terbeck]

Tach Axel,

Axel Beckert wrote:
 Hi Frank and Tim,

 Frank Terbeck wrote:
 Tim Booth wrote:
  This is a request on behalf of Bio-Linux and the Debian Med
  developers. The attached file shows the zshrc used on Bio-Linux, and
  the part we'd really like to see in the standard zsh-common package is
  support for a zprofile.d configuration directory[...]
 
 Is there a specific problem you'd like to address?

 I'd be curious about Tim's reason, too. I see, he (co-)maintains quite
 a lot of packages in Debian, but nothing which strikes me as
 zsh-related.

 Oh, and I'm glad we're having that discussion in a bug report! So I'm
 not the only one who thought about such a feature! ;-) (SCNR)

I actually though that this had been discussed before, but I couldn't
find a previous discussion. The instance I was recalling was a about
sourcing stuff from /etc/profile and /etc/profile.d/ itself (see below).


 I'm not a big fan of these kitchen sink directories everybody and
 their dog gets to dump stuff into.

 I'm actually quite a big fan of them (otherwise I probably never would
 have written Run::Parts[1]). They make packaging extensions, addons,
 plugins, etc. way easier as there's no need to modify the
 configuration files of other packages (which is forbidden by Debian's
 Policy).

   [1] https://packages.qa.debian.org/libr/librun-parts-perl.html
   https://metacpan.org/release/Run-Parts

 See e.g. /etc/apache2/*-enabled/, /etc/apt/apt.conf.d/ or
 /etc/bash_completion.d/ for examples used successfully by many
 packages. And I recently saw that /etc/apt/preferences.d/ is actively
 used by apt-listbugs to hold packages with RC bugs via pinning.

The bash_completions thing is only there because bash doesn't have sane
autoloadable functions. The apache directories I find rediculously
messy.

The apt-usecase seems legit.

With respect to shells, I usually find that applications, that need to
inject code into a user's shell to be by and large mis-designed.

Something that *might* make sense is to source stuff from /etc/profile
and “/etc/profile.d/” in POSIX-mode. See ¹, a mail about that from 2011.
Nobody cared enough to reply; which I guess that tells you something
about the urgency of the situation. ;-)

But like the mails says, even if we did that, it's hard to decide what
because it's not used for portable purposes alone. The bash completion
thing is sourced from there, which other POSIX shells will have a major
problem with.

I think the situation is messy and I'd like to not get my hands dirty.
This is, however, my personal opinion and does by no means reflect the
opinion of the rest of Debian's zsh packaging team. :-)


 Another nice example which would be much easier that way is the
 planned packaging grml's zshrc. (Which is still on my TODO list.)

Grml's zshrc could replace the existing configuration. It has everything
Debian's zshrc has and just piles up on that.


 As far as I know we already have /usr/share/zsh/vendor-functions and
 /usr/share/zsh/vendor-completions (of which only the latter is used so
 far), but that doesn't cover startup files like zshrc, zprofile,
 zshenv, etc.

Yeah, those are used for completely different purposes, though. And
adding them comes at virtually no additional costs.


 Especially in “/etc” since it's kind of hard for a package to remove
 stuff from there again.

 Huh? I'm sorry, but I have no idea what kind of issues you might refer
 to. If it's a conffile coming from a package, dpkg handles that
 well. If it's a generated file there's ucf to properly handle it. So
 I'd be happy if you could elaborate that issue a little bit as I'd be
 curious to learn about issues I'm not yet aware of.

(*puts on grml-zshrc hat*) As I recall, with grml's zsh configuration,
we had a ton of stuff in /etc/zsh/... and for some reason (I'm not
familiar with any particulars in the developer reference), we couldn't
just remove them in a maintainer script.

It was a huge pain in the ass and for quite a while we had code in the
setup that checked for the existence of old files in those directories,
asking the user to consider removing them. (*puts off hat again*)

To my understanding, stuff in /etc is considered a configuration file,
that might have been changed or added by the user and can therefore not
be removed by packages.  I could see using checksums to gauge whether or
not a file is still in mint condition. I don't know if that is being
done by dpkg these days.


 The common argument against .d directories with configuration snippets
 so far seemed performance issues to me.

My main issue with it is littering.

Performance is a true concern (my personal config file is split up into
multiple files and it not even funny - I'm putting off merging it into
one file again for a while now), though. Albeit not my primary one.


Regards, Frank

¹ 
http://lists.alioth.debian.org/pipermail/pkg-zsh-devel/2011-October/000248.html

-- 
In protocol design, perfection has been reached not when

Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

[Frank Terbeck]

Hey Tim,

Tim Booth wrote:
[...]
 This is a request on behalf of Bio-Linux and the Debian Med
 developers. The attached file shows the zshrc used on Bio-Linux, and
 the part we'd really like to see in the standard zsh-common package is
 support for a zprofile.d configuration directory[...]

Is there a specific problem you'd like to address? I'm not a big fan of
these kitchen sink directories everybody and their dog gets to dump
stuff into. Especially in “/etc” since it's kind of hard for a package
to remove stuff from there again.

 In Bio-Linux this is hooked from zshrc but actually a modified zprofile
 probably makes more sense.

 This is pretty trivial to implement, as far as I can see.  What do you think?
[...]
 for i in `( setopt null_glob ; echo -n /etc/zsh/zshrc.d/*.zsh )` ; do

Ungh... Don't do it like this! Just use globbing to create a list of
files. The idea about null_glob is sound in itself (even though in zsh
solvable differently, using the N glob qualifier). But since you do
this test in the loop:

 if [ -r $i ]; then
   source $i

you don't need null_glob at all. Thus, I'd do this:

for i in /etc/zsh/zshrc.d/*.zsh; do
# I'm quoting the parameter, because someone might have
# set the SH_WORD_SPLIT option in, say ~/.zshenv.
if [ -r $i ]; then
source $i
fi
done


Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

[Frank Terbeck]

Frank Terbeck wrote:
[...]
 you don't need null_glob at all. Thus, I'd do this:

 for i in /etc/zsh/zshrc.d/*.zsh; do

Well, since zsh's default behaviour is to error out with non-matching
globs, using the qualifier is actually required:

for i in /etc/zsh/zshrc.d/*.zsh(N); do
 # I'm quoting the parameter, because someone might have
 # set the SH_WORD_SPLIT option in, say ~/.zshenv.
 if [ -r $i ]; then
 source $i
 fi
 done


 Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707760: zsh: Alternatives broken for long time during upgrade from zsh4 to zsh5

[Frank Terbeck]

Frank Terbeck wrote:
[...]
 #!/bin/zsh -f

 if [[ -o interactive ]]; then
[...]

This wasn't the smartest idea ever. Since this is a script, it's
obviously not interactive invocation, which means that the test always
fails. Oh well. I guess we can just warn upon every invocation
interactive or not.


Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764650: zsh: FTBFS with noatime mounts

[Frank Terbeck]

Hi Thorsten!

Thorsten Glaser wrote:
 Justification: FTBFS, but maybe m68k are the only ones with noatime?

 http://buildd.debian-ports.org/status/fetch.php?pkg=zsharch=m68kver=5.0.6-3stamp=1412524530

 ../../Test/C02cond.ztst: test failed.
 The following may (or may not) help identifying the cause:
   This test can fail on NFS-mounted filesystems as the access and
   modification times are not updated separately.  The test will fail
   on HFS+ (Apple Mac OS X default) filesystems because access times
   are not recorded.  Also, Linux ext3 filesystems may be mounted
   with the noatime option which does not update access times.
   Failures in these cases do not indicate a problem in the shell.
 […]

Hum. There are a few tests, that are supposed to detect systems that
don't support that test, like systems with noatime filesystems and skip
that particular test.

In particular for noatime:

  elif test -f /etc/mtab  { grep $(df . 2/dev/null| tail -n1 | awk '{print 
$1}') /etc/mtab | grep -q noatime; }; then

...which doesn't catch the problem in the buildd, it would seem.

It does work on my laptop, but then, I have no clue about buildds. :)

Someone with a better, more portable version of that test around?


Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707760: zsh: Alternatives broken for long time during upgrade from zsh4 to zsh5

[Frank Terbeck]

Axel Beckert wrote:
 Sven Joachim wrote:
[...]
 How about adding a symlink /bin/zsh4 - zsh5 in the zsh package?  Not
 extremely pretty, but it should work.

 What about putting a shell script at /bin/zsh4 which more or less
 looks this?

   #!/bin/sh
   
   echo $0 is deprecated, please switch to /bin/zsh or /usr/bin/zsh 12
   exec /bin/zsh5 $@

I think this is the way to go. Maybe even like this:

#!/bin/zsh -f

if [[ -o interactive ]]; then
echo $0 is deprecated, please switch to /bin/zsh or /usr/bin/zsh 12
echo Use: chsh -s /bin/zsh 12
echo This command ($0) will disappear eventually! 12
fi
exec /bin/zsh $@

 Or maybe even

   #!/bin/sh
   set -e
   
   echo $0 is deprecated, please switch to /bin/zsh or /usr/bin/zsh 12
   /bin/zsh5 $@
   exit 1

Too intrusive, IMHO.


Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764650: zsh: FTBFS with noatime mounts

[Frank Terbeck]

Thorsten Glaser wrote:
 Frank Terbeck dixit:
[...]
  elif test -f /etc/mtab  { grep $(df . 2/dev/null| tail -n1 | awk '{print 
 $1}') /etc/mtab | grep -q noatime; }; then
[...]
 Hm, I think this rings a bell. Didn’t we have this on another buildd
 already, years ago, because something like mtab wasn’t available or
 something? Will need to dig through mail/bts archives…

Axel hinted at that on IRC, as well. He thought that /proc/mounts should
be available, which I think has the same syntax. We could just double up
the test, once against /etc/mtab and then against /proc/mounts.

Would that help?


Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753296: Acknowledgement (mpv completion fails)

[Frank Terbeck]

Yuri D'Elia wrote:
 Ahh sorry, I noticed only now that the _mpv function is shipped with mpv
 itself.

 Could you reassign it to mpv?

The problem you're describing looks like a broken completions-cache
file. Before you proceed, try this:

  % rm ~/.zcompdump
  % exec zsh

And see if the problem persists.


Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#418199: Fwd: Re: segfault with exceedingly long path [origin: schae...@brasslantern.com]

[Frank Terbeck]

Goswin von Brederlow wrote:
 On Sat, Jan 18, 2014 at 10:19:39AM +0100, Axel Beckert wrote:
[...]
 upstream said, this is an issue which is unlikely ever to be fixed.
 Marking as such.
[...]
 From: Bart Schaefer schae...@brasslantern.com:
 [...]  Various parts
 of the shell rely on system limits such as PATH_MAX which cannot be
 dynamically changed.  There's a comment with some explanation around
 lines 109-137 of Src/compat.c.
[...]
 Could you fix that in Debian even if upstream doesn't care? A segfault

Fixing it in debian and not upstream is very unlikely. It is not like
upstream doesn't care. It's much more that the underlying problem is
quite hard to fix correctly in the current code. If we had a proper fix,
they would take it faster than you can say ouch, that was a segfault..

 is never right. If zsh can't handle the long path then it must check

Yes, they are never right. Bart Schaefer from upstream (who said that is
unlikely to be fixed) knows that as well. He also send a patch that
should stop the shell from segfaulting in this particular case:

  http://www.zsh.org/mla/workers/2014/msg00085.html

But this is currently more like plucking holes than fixing the
underlying problem; i.e. the reliance on static system limits like
PATH_MAX.

 the length and give an error. Not fixing a segfault is imho
 unacceptable.

As always, send patches.

Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733075: zsh: command completion not working after semicolon

[Frank Terbeck]

Hello Jay!

Jay Berkenbilt wrote:
 Usually when I type a command followed by ;, after the ;, zsh is back
 to a state where TAB should complete on commands again.  This is
 pretty basic completion behavior.  After I upgraded to 5.0.4-1, I
 observed that this was no longer working.  As soon as I type a ;,
 completion reverts to simple path completion.

Ungh. This is annoying. :-/

What version did you upgrade from? I'm seeing this behaviour in an older
development snapshot (zsh-5.0.2-174-g8a70a98) on my laptop as well. A
much older (4.3.10) version behaves properly.

 I observe this with my elaborate customizations and also with zsh -f.
 I have not looked into it, but it seems so fundamental, I thought it
 was worth reporting right away in case there's a real issue here.

I see. Same here.

Note however, that after zsh -f there is another completion system in
place (yes, zsh has two of them: compctl [the very old one] and compsys
[the slightly less old one]). To enable compsys in a plain zsh -f
instance, you can always run this:

  zsh% autoload -Uz compinit
  zsh% compinit

I wonder why compctl and compsys are both broken...


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733075: Bug#733075: zsh: command completion not working after semicolon

[Frank Terbeck]

Hey Richard!

Richard Hartmann wrote:
 Seems we worked in parallel here; I already confirmed and forwarded to
 zsh-workers.

Seems like it. :-)

 5.0.2-6 was not affected.

I git-bisected this to:

[568e0db7a964feefa45061967d0c7079a0e59c1e]
  31611: attempt to fix crash completing redirection in do loop

The relevant zsh-workers thread is:
  http://www.zsh.org/mla/workers/2013/msg00652.html


This is in zle_tricky.c, so naturally I'm afraid to touch it. :)

Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727222: debian/patches/38-linux-3.11-sf.patch

[Frank Terbeck]

The fix James proposes does indeed fix the issue for me.

I'm attaching the patch-file I used as

  debian/patches/38-linux-3.11-sf.patch

for convenience.

Regards, FrankDescription: Import upstream fix for shared folders with linux 3.11

 Apparently, listing directories in shared folders with linux kernel
 version 3.11 causes the application requesting the directory list to
 enter a busy loop.  This is the indended fix from upstream's VCS.

Author: Virtualbox Upstream
Bug-Debian: http://bugs.debian.org/727222
Upstream-Fix-URL: https://www.virtualbox.org/changeset/48529/vbox

--- virtualbox-4.2.16-dfsg.orig/src/VBox/Additions/linux/sharedfolders/dirops.c
+++ virtualbox-4.2.16-dfsg/src/VBox/Additions/linux/sharedfolders/dirops.c
@@ -282,10 +282,13 @@ static int sf_dir_read(struct file *dir,
 }
 
 #if LINUX_VERSION_CODE = KERNEL_VERSION(3, 11, 0)
-err = dir_emit(ctx, d_name, strlen(d_name), fake_ino, DT_UNKNOWN);
+if (!dir_emit(ctx, d_name, strlen(d_name), fake_ino, DT_UNKNOWN))
+{
+LogFunc((dir_emit failed\n));
+return 0;
+}
 #else
 err = filldir(opaque, d_name, strlen(d_name), dir-f_pos, fake_ino, DT_UNKNOWN);
-#endif
 if (err)
 {
 LogFunc((filldir returned error %d\n, err));
@@ -293,6 +296,7 @@ static int sf_dir_read(struct file *dir,
only when it runs out of space in opaque */
 return 0;
 }
+#endif
 
 dir-f_pos += 1;
 #if LINUX_VERSION_CODE = KERNEL_VERSION(3, 11, 0)

Bug#717002: zsh: Update for git-buildpackage completion

[Frank Terbeck]

Hey,

with my pkg-zsh hat on, here are some thoughts:

Guido Günther wrote:
 On Mon, Oct 28, 2013 at 03:50:33PM -0300, Felipe Sateler wrote:
 On Mon, Oct 28, 2013 at 2:22 PM, Vincent Bernat ber...@debian.org wrote:
   ❦ 15 juillet 2013 23:27 CEST, Felipe Sateler fsate...@debian.org :
[...]
  Unfortunately my completion foo is quite limited, so they are not as
  good as they could be (multiple pq commands are allowed;
  cannot detect when to require a dsc or a package name in import-dsc and
  others).
 
  I still think the result is somewhat useful.
 
  It is working fine for me. Maybe this could be shipped with gbp instead?

The three options are: a) Shipping the completion separately (which is
the worst possible solution; b) have it shipped with gbp; and c) have it
shipped with zsh.

Upstream zsh welcomes additions to the pool of available completion
functions. Debian already has its own sub-directory within that pool, so
adding ‘_gbp’ to that pool would be a natural thing to do. The advantage
of that would be, that knowledgeable eyes at least scan the code you
submit. On the flip-side, you'd have to regularly sync your version of
the completion with zsh's repository, because nobody gains anything from
massively outdated completion functions.


 GBP maintainers, would you mind adding this file to the gbp package?
 It's a start for a zsh completion, but it is already useful.

If you choose to ship ‘_gbp’ with gbp itself, the advantage would be
that you'd ship a completion that always exactly matches the command
line interface of the software - if you keep the completion up to date.

Debian's zsh package provides an $fpath entry for other packages to drop
completion function files into. That entry was introduced to
specifically support completions that are shipped with the target
software rather than with upstream zsh. That directory would be:

  /usr/share/zsh/function/vendor-completions

For completeness, if you want to ship non-completion functions, the
directory to use would be:

  /usr/share/zsh/function/vendor-functions


 If somebody submits a patch I'd be happy to. I do wonder why you
 hardcode the options though instead of parsing it from the command's
 --help output?

The idea is usually to provide context-specific completion depending on
the option-set. That's why you often need to name the options anyway
since the following code-paths depend on them. By context-sensitive, I
mean for example, with git's completion, git add tab only shows
files that are not .gitignored and either not tracked yet or contain
changes. To identify that context, the completion needs to know about
‘add’.

Those are my 2¢.

Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724721: zsh: Tab completion error with vi

[Frank Terbeck]

Hi Ludovic,

Ludovic Lebègue wrote:
[...]
 While using zsh shell trying to autocomplete with tab key display the 
 following
 message instead of showing the files in the current directory :

 ludo@leonardo ~ % vi
 _arguments:450: _vim_files: function definition file not found

Did this happen after updating zsh? What's the old zsh version?

In any case, what's the output of following?

  % head ~/.zcompdump


Problems like this are usually cause by that cache file being out of
date and something is keeping an automatic rebuild from happening.

If you remove the file and restart the shell, the problem should be
gone.

Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#720707: RFP: grml-zsh-config -- zsh configuration that ships with the Debian-based grml distro

[Frank Terbeck]

Thomas Koch wrote:
 thank you very much for taking this! Your question about how the zshrc will 
 be provided is so common that I proposed a general solution:

 http://lists.alioth.debian.org/pipermail/soc-coordination/2012-February/001156.html

 In short and for the start I'd say: just put the files under /usr/share/grml-
 zsh-config and provide a shell script that adds the necessary symlinks from 
 my 
 current homedir. It's already a big improvement to have the files in the 
 archive and to get updates.

Yes, thank you! Not having the add-on configuration in /etc sounds like
the right thing to do, because then things can remain in the hands of
the package system.

 Once there is a canonical location for grml-zsh-config I already have my 
 first 
 wishlist items:

 - Integrate vcsh into the prompt

Grml's zsh setup uses a rather extensible prompt (since the last few
releases). Generally, I'd like to not include too many special purpose
code in grml's main configuration, because it is already quite large and
complex.

There are some facilities to implement special-purpose prompt support
with grml's new prompts, though. There is an example, that adds
virtual-env support:

  http://bewatermyfriend.org/p/2013/003/

Adding support for vcsh should be fairly straight forward. (Support for
it could also be done via vcs_info and its hook subsystem.)

 - make it configurable whether the name of the VCS is shown. I use git 
 exclusively so I'm just interested in the branch name.

Grml's VCS information is provided by zsh's vcs_info system. That system
is pretty configurable¹ and your wish is already easily solved. You just
need to acknowledge, that grml's setup uses two vcs_info formats: One
for its prompt and the other for setting titles in GNU screen and tmux
based on the currently checked out branch.

  zstyle ':vcs_info:*' formats '[%b] ' 'zsh: %r'
  zstyle ':vcs_info:*' actionformats '[%b|%a] ' 'zsh: %r'

Add colouring to your preference. ;)

Regards, Frank

¹ man zshcontrib | less -p GATHER


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#692785: zsh: '.zprofice' typo in zshrc

[Frank Terbeck]

Michael Terry wrote:
 Package: zsh
 Version: 5.0.0-2
[...]
 Ubuntu user Logan Rosen provided the attached patch to fix a typo in
 debian/zshrc.  .zprofice should be .zprofile.

Hey there,

this does not apply to the debian package, since we don't call
`compinit' under any circumstances in the global zshrc¹.

  # If you don't want compinit called here, place the line
  # skip_global_compinit=1
 -# in your $ZDOTDIR/.zshenv or $ZDOTDIR/.zprofice
 +# in your $ZDOTDIR/.zshenv or $ZDOTDIR/.zprofile

Also, the comment isn't quite right. I'd leave the mention of
`.zprofile' out entirely, because using it would only work for zsh
instances that are interactive shells AND login shells. If the shell
wouldn't be a login shell, setting something in that file doesn't have
any effect whatsoever.

Regards, Frank

¹ 
http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=blob;f=debian/zshrc;hb=HEAD


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685511: zsh: /etc/zsh/zshrc brokes return on numpad

[Frank Terbeck]

sergio wrote:
[...]
 Version: 5.0.0-2

 After upgrade to 5.0 numpad return (KP_Enter) key doesn't work anymore.

Yes. This is due to our reimplementation of keyboard handling within the
global zshrc file of the 5.0.0 packages.

What we did is enable application mode in the terminal, when the line
editor is active. Doing that is the right thing, because only then are
the entries in `$terminfo' correct.

Now as for KP_Enter: The corresponding terminfo capability for that key
is `kent', so the  following will work:

  % bindkey ${terminfo[kent]} accept-line

However, not all terminals include `kent' in their terminfo entries.
Notably, the `screen' entry (used by terminal multiplexers such as GNU
screen and tmux) does not. So it's hard to bind that key properly.

You could fallback to the value from the `xterm' entry and hope every
other terminal follows xterm's lead... but what are the changes of that
happening? Anyway, here's a snippet that might work in many cases (at
least for xterm and urxvt with or without screen/tmux running inside):

[snip]
if (( ${+terminfo[kent]} )); then
kent=${terminfo[kent]}
else
kent=$(TERM=xterm echoti kent 2/dev/null)
# If there is nothing in `$kent' yet, use ESC O M, which is
# what xterm and urxvt use.
[[ -z $kent ]]  kent=$'\eOM'
fi
bindkey $kent accept-line
unset kent
[snap]

A little too hacky for debian's global zshrc, I think.

Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666755: [zsh] GnuPG2 completion

[Frank Terbeck]

Mika Suomalainen wrote:
 zsh is not automatically completing options for gpg2 (package gnupg).
 Many gpg2 command line flags are probably same as gpg ones.

If so, then the following may be a workaround for your configuration
until someone comes up with a full-featured gpg2 completion:

  compdef gpg2=gpg

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666168: zsh: Many function definitions are missing zsh-newuser-install, compinit, etc.

[Frank Terbeck]

Hong Xu wrote:
 /usr/share/zsh/4.3.17/scripts/newuser:6: zsh-newuser-install: function
 definition file not found
[...]
 autoload -U compinit
 compinit
[...]
 zsh: compinit: function definition file not found


This sounds like a severely broken installation. Debian's zsh packages
do not split the function files off of the main package (yet). So that
really shouldn't happen.

What is the output of this:

  print -l $fpath
  c=( ${^fpath}/compinit(N.) )
  (( $#c ))  ls -l $c[1] || echo compinit not found

The last command shouldn't come up with compinit not found. If it does
the output from the first command is probably reflecting breakage.

In case it's broken try this:

  % zsh -f
  (and in that new shell)
  % autoload -Uz compinit
  % compinit
  % print ${#_comps}

The `compinit' call should *not* fail and the `print' call should return
an integer in the range of slightly above one thousand.

If this does not work, your installation is very likely broken (however
that happened...).

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666168: zsh: Many function definitions are missing zsh-newuser-install, compinit, etc.

[Frank Terbeck]

Hong Xu wrote:
 On 03/29/2012 09:18 PM, Frank Terbeck wrote:
[...]
print -l $fpath
c=( ${^fpath}/compinit(N.) )
(( $#c ))  ls -l $c[1] || echo compinit not found
[...]
 It cames up with:

   /opt/intel/composerxe-2011.5.220/mkl/include
   compinit not found

I have no idea were this is coming from. Please do this:

  % zsh -f
  (and in that new shell)
  % print -l $fpath

If that yields /opt/intel/composerxe-2011.5.220/mkl/include then that
is not from our package. That would be completely broken.

 In case it's broken try this:

% zsh -f
(and in that new shell)
% autoload -Uz compinit
% compinit
% print ${#_comps}

 The `compinit' call should *not* fail and the `print' call should return
 an integer in the range of slightly above one thousand.

 compinit fails, and the print gives 0.

This makes me think that your zsh is actually entire broken, what source
are you getting your package from? Do:

  % apt-cache policy zsh

The unchanged $fpath from a default zsh installation on a recent debian
sid system should look like this:

[snip]
/usr/local/share/zsh/site-functions
/usr/share/zsh/vendor-functions
/usr/share/zsh/vendor-completions
/usr/share/zsh/functions/Calendar
/usr/share/zsh/functions/Chpwd
/usr/share/zsh/functions/Completion
/usr/share/zsh/functions/Completion/AIX
/usr/share/zsh/functions/Completion/BSD
/usr/share/zsh/functions/Completion/Base
/usr/share/zsh/functions/Completion/Cygwin
/usr/share/zsh/functions/Completion/Darwin
/usr/share/zsh/functions/Completion/Debian
/usr/share/zsh/functions/Completion/Linux
/usr/share/zsh/functions/Completion/Mandriva
/usr/share/zsh/functions/Completion/Redhat
/usr/share/zsh/functions/Completion/Solaris
/usr/share/zsh/functions/Completion/Unix
/usr/share/zsh/functions/Completion/X
/usr/share/zsh/functions/Completion/Zsh
/usr/share/zsh/functions/Exceptions
/usr/share/zsh/functions/MIME
/usr/share/zsh/functions/Misc
/usr/share/zsh/functions/Newuser
/usr/share/zsh/functions/Prompts
/usr/share/zsh/functions/TCP
/usr/share/zsh/functions/VCS_Info
/usr/share/zsh/functions/VCS_Info/Backends
/usr/share/zsh/functions/Zftp
/usr/share/zsh/functions/Zle
[snap]

In particular, we do NOT have any /opt/intel/... paths in there.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666168: zsh: Many function definitions are missing zsh-newuser-install, compinit, etc.

[Frank Terbeck]

Hong Xu wrote:
 On Mar 29, 2012, at 21:59, Frank Terbeck f...@bewatermyfriend.org wrote:
[...]
 In particular, we do NOT have any /opt/intel/... paths in there.
 

 I know what's going on here now: intel compiler init scripts change the fpath 
 variable.

Is that by chance the Intel Fortran Compiler? I'm just curious.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#663982: zsh: autocompletion does not work anymore after compinit

[Frank Terbeck]

Martin Steigerwald wrote:
 auto completion stopped worked since this week. This might be related
 to an upgrade of Z-Shell. It is related configuration, with an empty
 .zshrc it works. But with the recommended configuration from the
 system administrator it does not.

 I found it to stop working after compinit. With empty configuration:

 mango% cd Infrastruktur/ [aborted with Ctrl-C]
 mango% autoload -Uz compinit
 mango% cd Infrastruktur/ [aborted with Ctrl-C]

Before you're running `compinit', the function-based completion system
is *NOT* online yet. Zsh will fall back to the older compctl system.

 mango% compinit
 mango% cd In

 No reaction on tab anymore.

When you say no reaction do you mean that zsh eats up all CPU or does
it actually hang without and CPU utilisation at all?

 But this only happens for *one* user that uses a home directory on NFS.

If NFS is in play it could also be bad performance with certain options.
Does the shell hang or does completion just take a very very long time?
As in minutes?

 Neither with root nor with a local user I can reproduce this.

 Tab completion worked for the NFS user as well before. I can fix it by
 uncommenting compinit from his .zshrc.

Sounds weird. Can't identify a reason off hand.

 This is the .zshrc of the user, but as said it also does not work
 with the system admin recommended one.
[...]

There is nothing in there, that would cause that I think. The other
files (zshenv, zprofile, zlogin - global and user-only) are empty, I
presume?

[...]
 Even with this configuration auto completion does not work for the
 autocd case. But for the local test user it works also in the autocd
 case. For the local test user it also works when I navigate on the
 NFS export.

My *guess* is that something triggers user-name lookups which may take a
very long time with a lot of users in networked environments. But like I
said, it's a guess for now...

Sorry for taking so long. I'm pretty swamped with other work right now.
I hope the other guys from the maintenance team will chime in. ;-)

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#658223: zsh: 'man zshmisc' typo: defintions

[Frank Terbeck]

tags 658223 + fixed-upstream
thanks

A. Costa wrote:
[...]
 Found a typo in '/usr/share/man/man1/zshmisc.1.gz', see attached '.diff'.
 Hope this helps...
[...]
 --- zshmisc.1 2012-01-22 18:15:59.0 -0500
[...]


Thanks for noticing!

Zsh's manual is not in roff format, though. It's in yodl format, from
which all destination formats are generated. I've committed a fix to the
right files upstream¹, therefore it'll be in zsh's next version. Thanks
again.

Regards, Frank

¹ 
http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=756f17a755fe52eb36aefc99bed4a41385d41df8



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#463507: Triage

[Frank Terbeck]

A. Costa wrote:
[...]
 Still there in 'zsh' v4.3.15-1.  Example: I typed
 what's above the carets and the Tab key, then the line
 looks like:

   ls -_main_complete:166: permission denied: 
   

Please do this:

  % rm ~/.zcompdump
  % zsh -f
  (and in that new shell)
  % autoload -Uz compinit
  % compinit
  % ls -tab

That should work. Sometimes, when `~/.zcompdump' is outdated, weird
issues have been known to appear. If you can still reproduce the problem
with the above recipe, I'd be interested in how your system differs from
other people's systems.

If you cannot, your zsh setup is broken.

Needless to say, I can't reproduce the issue.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Just for the record: This issue is fixed upstream by now and will be in
the next version of the package.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654444: zsh: `q' flag for paramater expansion does not work as advertised

[Frank Terbeck]

Samuel Bronson wrote:
 Frank Terbeck wrote:
 Samuel Bronson wrote:
[...]
 | naesten@hydrogen:~/hacking/crawl/crawl-ref/source% echo -n ${(q)$(echo | 
 -e \e)}|hd
 |   24 27 1b 27                                       |$'.'|
 | 0004
[...]
 zsh% printf '%s\n' ${(q)$(echo -e \e)}
 $'\033'

 Oh, really? Leaves one wondering about the point of echo -e...

Not really. The problem is not the inner, but the outer echo. The inner
echo ($the $(echo -e \e))produces an actual escape character (0x1b).

The (q) produces an octal escape in $'...' quotes (0x1b == 033o). The
outer echo sees the octal escape and interprets it, producing a literal
ASCII escape character again.

Echo is like that - or not, depending on the shell in question. Even
POSIX says:

[SUSv3, echo]
  New applications are encouraged to use printf instead of echo.
[...]
  The echo utility has not been made obsolescent because of its
  extremely widespread use in historical applications. Conforming
  applications that wish to do prompting without newlines or that
  could possibly be expecting to echo a -n, should use the printf
  utility derived from the Ninth Edition system.
[/SUSv3]

In other words: `echo' is crap. We've just not removed it, because it's
in heavy use. If you want consistent predictable behaviour, use
`printf'.

If you're wondering why zsh's `echo' has the `-e' option at all,
although it interprets the escape sequences anyway, then the answer is:
Because zsh tries to please everyone. There is an `-E' option, that
disables the escape sequences effect. And there's a `BSD_ECHO' option,
that makes that behaviour the default for zsh's `echo'. In order to get
the interpreting behaviour with that option set, the `-e' option is
provided.

This is yet another reason not to use echo. Different shells have
annoyingly different echos and in zsh you can even alter its behaviour
by options.

I hope that clears things up.

Regards, Frank



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
[...]
 What you are missing is that you never once tried the combination setting
 I described as causing problem. Please try to set a non-utf8 _country_

I'd be surprised to see different results with `de_DE' and `POSIX'.

 locale for the LANG variable together with a utf8 locale for the LC_ALL
 variable. E.g. at your zsh prompt:

export LANG=de_DE
export LC_ALL=de_DE.utf8

 type in e.g. an umlaut character, type backspace to delete it and notice
 that it is deleted piecemeal by octet. It should happen to you too!

It doesn't. For me, zsh works as expected, even with that combination.

[...]
 This combination

export LANG=
export LC_ALL=da_DK.utf8

 is okay. So it is the specific combination of a non-utf8 country locale
 for LANG and a utf8 country locale for LC_ALL that is at fault.

I can't reproduce this yet. I'll try to replicate your system more
closely this afternoon...

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
[...]
export LANG=de_DE
export LC_ALL=de_DE.utf8

 type in e.g. an umlaut character, type backspace to delete it and notice
 that it is deleted piecemeal by octet. It should happen to you too!

Hum.

I can reproduce this right now. I'm unsure where I went wrong before.
But since mika couldn't get the problem triggered either, I don't feel
too bad. ;)

I'll look into it. Thanks for reporting. (It might take a while, unless
someone else from upstream jumps in.)

Regards, Frank

  For the record:

a) Start a blank shell (zsh -f)
b) export LANG=de_DE (*not* POSIX)
   export LC_ALL=de_DE.utf8
   ...or whatever language you like, just the UTF-8 locale in
   `LC_ALL' and the non-UTF-8 locale in `LANG'. Both locales
   should probably exist on your system. So check locale -a and
   update `/etc/locale.gen' and run `locale-gen' if needed.
c) Type two multibyte characters, like `ö' (o with diaeresis).
d) Type backspace four time.
e) See the cursor erase parts of your prompt.
f) Rant about locales in your native tongue.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Frank Terbeck wrote:
[...]
 I can reproduce this right now. I'm unsure where I went wrong before.

Now I know.

The order in which you have to set LANG and LC_ALL is crucial to
reproduce the issue. And the order in my recipe from the last mail is
wrong:

[...]
 b) export LANG=de_DE (*not* POSIX)
export LC_ALL=de_DE.utf8
[...]

It actually has to be the other way around. So:


b) export LC_ALL=de_DE.utf8
   export LANG=de_DE (*not* POSIX)
   ...or whatever language you like, just the UTF-8 locale in
   `LC_ALL' and the non-UTF-8 locale in `LANG'. Both locales
   should probably exist on your system. So check locale -a and
   update `/etc/locale.gen' and run `locale-gen' if needed.
c) Type two multibyte characters, like `ö' (o with diaeresis).
d) Type backspace four time.
e) See the cursor erase parts of your prompt.
f) Rant about locales in your native tongue.


Regards, Frank



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Michael Prokop wrote:
[...]
 I sadly still can't reproduce it yet, FTR.

Mika and I talked about this on IRC. Turns out he had `LC_CTYPE' in his
environment, which gets saved by zsh's handling, which prevents the
problem.

So, the real[tm] recipe is this:


a) Start a blank zsh (zsh -f)
b) unset LC_CTYPE
c) export LC_ALL=de_DE.utf8
   export LANG=de_DE (*not* POSIX)
   ...or whatever language you like, just the UTF-8 locale in
   `LC_ALL' and the non-UTF-8 locale in `LANG'. Both locales
   should probably exist on your system. So check locale -a and
   update `/etc/locale.gen' and run `locale-gen' if needed.
d) Type two multibyte characters, like `ö' (o with diaeresis).
e) Type backspace four time.
f) See the cursor erase parts of your prompt.


Regards, Frank



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: PATCH: Restore `LC_ALL' when setting `LANG'

[Frank Terbeck]

(Cc:ing Upstream)

When setting LANG, zsh sets LC_ALL and then goes on to restore all
interesting LC_* values after that. Up to now, it did not restore LC_ALL
itself, though.

That could lead to trouble when setting LC_ALL=something-utf8-ish and
after that LANG=something-non-utf8.

This was reported in Debian bugreport #654225:

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

A recipe to reproduce the issue is here:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654225#65

I think the patch below fixes the issue correctly, by restoring LC_ALL
from its parameter along the way with all the other LC_* values zsh
cares about.

(FWIW, the test-suite still passes with this change.)

Regards, Frank


---
 Src/params.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/Src/params.c b/Src/params.c
index 446..6d98b8e 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -3780,6 +3780,9 @@ static struct localename {
 #ifdef LC_TIME
 {LC_TIME, LC_TIME},
 #endif
+#ifdef LC_ALL
+{LC_ALL, LC_ALL},
+#endif
 {NULL, 0}
 };
 
-- 
1.7.8.rc3.17.gf56ef1




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654444: zsh: `q' flag for paramater expansion does not work as advertised

[Frank Terbeck]

Samuel Bronson wrote:
[...]
 ,
 | q
 |  Quote the resulting words with backslashes; unprintable or invalid
 |  characters are quoted using the $'\NNN' form, with separate quotes
 |  for each octet.  [...]
 `

 Unfortunately, the second clause seems to be only half correct;
 unprintable characters do get wrapped in $'...', but not \NNN escaped:

 ,
 | naesten@hydrogen:~/hacking/crawl/crawl-ref/source% echo -n ${(q)$(echo
 | -e \e)}|hd
 |   24 27 1b 27   |$'.'|
 | 0004
 `

 Of course, what I'd *really* like would be for this to get escaped as
 \e, not \NNN, but I was at least expecting the documented behavior!

This is not a bug.  It's echo being echo (ie. a load of $swearword).

zsh% printf '%s\n' ${(q)$(echo -e \e)}
$'\033'

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
 I could not get multibyte support to work in zsh, even if I had a, what
 seemed to me, perfectly working utf-8 environment. I then checked the
 output from the locale command and noticed that all my LC_.* variables
 were set to da_DK.utf8 whereas the $LANG variable missed the utf8
 extension. As soon as I changed it to include this extension, then
 multibyte support worked. As noted, the lack of this setting has not
 affected me at all except in zsh (multibyte support worked fine in bash
 for instance). I believe that zsh should check both the values of the
 LC_CTYPE variable and the LANG variable.

Locale settings work like this: LC_* variables control the different
pieces of the puzzle, when one of those is not set `LANG' is used as a
fallback. `LC_ALL' is special, because it overrides all other LC_*
variables and `LANG' becomes meaningless.

[...]
 Locale: LANGÚ_DK.utf8, LC_CTYPEÚ_DK.utf8 (charmap=UTF-8) (ignored: LC_ALL set 
 to da_DK.utf8)

You're setting `LC_ALL'. So the setting of `LANG' shouldn't matter at
all.

I've got one system that only sets LC_CTYPE=en_US.UTF8 to something
UTF-8-ish and that works for me (LC_* set to `POSIX' - LANG and LC_ALL
both unset).

I did take a quick look at the involved code and I didn't see anything
obviously wrong with it. `LANG' should *not* matter with `LC_ALL' set.
If it does, that's a bug.

Can you give a minimal zsh setup and a simple way to trigger the problem
you're seeing for further inspection?

Regards, Frank



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

[Frank Terbeck]

Morten Bo Johansen wrote:
[...]
 I attach my rather small zshrc.

Nothing in that file is relevant to this issue.

 ~/.zshenv is a symlink to ~/.environment
 which just set a lot of environment variables. It is there that I now
 specifiy the LANG variable which makes zsh behave correctly.

That would be relevant then. What are you doing in there? Are you
exporting the parameters you're setting or not? Which parameters are you
setting (only locale-related parameters matter)?

 zprofile and
 zlogin are empty. On a sidenote, I did specifiy LANG=da_DK.utf8 in
 /etc/default/locale along with LC_ALL=da_DK.utf8. This is supposedly the
 right way to set your locale in Debian, but only the first line with
 LC_ALL is read.

Doesn't the default setup only set `LANGUAGE' and `LANG'?

That would make sense. Because `LC_ALL' is a blunt instrument. If it's
set, you can't deviate from that setting. If you only set `LANG', then
that has the same effect as setting `LC_ALL' until you choose to modify
some aspect of your locale settings. You change `LC_COLLATE' or
`LC_MESSAGES' or whatever and only that setting is changed. All other
unset values default to the value of `LANG'.

 Maybe I should file a bug report for that against the
 locales package?

Don't think it's a bug in their package. (Well, yet, but I think it's
unlikely so far.)


Let's take a look first. I'm running the following in a zsh -f shell,
which means that there's so no setup except for the global zshenv file.
That file is empty in my case, so that is a shell with just defaults.

I am only defining the following function:

l() {
for i in ${${(f)$(locale)}%%\=*}; do
printf '%s (type: %s): %s\n' $i ${(Pt)i} ${(P)i}
done
}

That function prints *all* locale-variables with their respective type
(as far as zsh in concerned) and value, to be able to compare those
settings with the values from the `locale' command.

Zsh handles a few variables itself even if they are not exported into
the environment. As documented in zshparam(1).

So, what's going on when zsh is freshly started?

zsh% l 
LANG (type: scalar-export-special): en_GB.UTF-8
LANGUAGE (type: scalar-export): en_GB:en
LC_CTYPE (type: ): 
LC_NUMERIC (type: ): 
LC_TIME (type: ): 
LC_COLLATE (type: ): 
LC_MONETARY (type: ): 
LC_MESSAGES (type: ): 
LC_PAPER (type: ): 
LC_NAME (type: ): 
LC_ADDRESS (type: ): 
LC_TELEPHONE (type: ): 
LC_MEASUREMENT (type: ): 
LC_IDENTIFICATION (type: ): 
LC_ALL (type: ): 

zsh% locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES=en_GB.UTF-8
LC_PAPER=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_TELEPHONE=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_ALL=

So there. `LANG' and `LANGUAGE' are defined and exported (as configured
in /etc/default/locale). `LANG' is special to the shell, as documented
in zshparam(1).

UTF-8 works like this. Now I do this:

zsh% LANG=POSIX

...which leads to:

zsh% l 
LANG (type: scalar-export-special): POSIX
LANGUAGE (type: scalar-export): en_GB:en
LC_CTYPE (type: ): 
LC_NUMERIC (type: ): 
LC_TIME (type: ): 
LC_COLLATE (type: ): 
LC_MONETARY (type: ): 
LC_MESSAGES (type: ): 
LC_PAPER (type: ): 
LC_NAME (type: ): 
LC_ADDRESS (type: ): 
LC_TELEPHONE (type: ): 
LC_MEASUREMENT (type: ): 
LC_IDENTIFICATION (type: ): 
LC_ALL (type: ): 

zsh% locale
LANG=POSIX
LANGUAGE=en_GB:en
LC_CTYPE=POSIX
LC_NUMERIC=POSIX
LC_TIME=POSIX
LC_COLLATE=POSIX
LC_MONETARY=POSIX
LC_MESSAGES=POSIX
LC_PAPER=POSIX
LC_NAME=POSIX
LC_ADDRESS=POSIX
LC_TELEPHONE=POSIX
LC_MEASUREMENT=POSIX
LC_IDENTIFICATION=POSIX
LC_ALL=

See how all the values that defaulted to en_GB.UTF-8 (the value of
`LANG') before now default to POSIX (the new value of `LANG').

UTF-8 stopps working now, because zsh rightfully thinks that it is not
in a unicode environment.

Let's experiment a bit:

Let's unset `LANG' to get closer to your setup:

zsh% unset LANG

Now we're getting this:

zsh% l
LANG (type: ): 
LANGUAGE (type: scalar-export): en_GB:en
LC_CTYPE (type: ): 
LC_NUMERIC (type: ): 
LC_TIME (type: ): 
LC_COLLATE (type: ): 
LC_MONETARY (type: ): 
LC_MESSAGES (type: ): 
LC_PAPER (type: ): 
LC_NAME (type: ): 
LC_ADDRESS (type: ): 
LC_TELEPHONE (type: ): 
LC_MEASUREMENT (type: ): 
LC_IDENTIFICATION (type: ): 
LC_ALL (type: ): 

zsh% locale
LANG=
LANGUAGE=en_GB:en
LC_CTYPE=POSIX
LC_NUMERIC=POSIX
LC_TIME=POSIX
LC_COLLATE=POSIX
LC_MONETARY=POSIX
LC_MESSAGES=POSIX
LC_PAPER=POSIX
LC_NAME=POSIX
LC_ADDRESS=POSIX
LC_TELEPHONE=POSIX
LC_MEASUREMENT=POSIX
LC_IDENTIFICATION=POSIX
LC_ALL=

Everything as expected. And UTF-8 does not work. Which is correct,
because - again - nothing tells zsh it's in a unicode environment.

Now let's set `LC_ALL':

zsh% LC_ALL=en_GB.UTF-8

And the result:

zsh% l   
LANG (type: ): 
LANGUAGE (type: scalar-export): en_GB:en
LC_CTYPE (type: ): 
LC_NUMERIC (type: ): 
LC_TIME (type: ): 
LC_COLLATE (type: ): 

Bug#648246: fdm: FTBFS(kfreebsd): Unable to configure for GNU/kFreeBSD

[Frank Terbeck]

Sorry for the delay; hardware died on me...

Robert Millan wrote:
 The rest of the blob is OK but mremap() is Linux-specific.

I'll take your word for it.

 Here's a fixed patch (tested and known to build).

Thanks, applied to https://github.com/ft/debian_fdm/.

 Btw, instead of shipping your own strlcat() / strlcpy() / strtonum()
 you could use the ones in libbsd and save some package size.

Yeah, I know. If upstream would move there, I'd obviously follow. But
just for fdm in debian, I don't think the small benefit is worth the
effort.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#648246: fdm: FTBFS(kfreebsd): Unable to configure for GNU/kFreeBSD

[Frank Terbeck]

Robert Millan wrote:
 2011/11/9 Frank Terbeck f...@bewatermyfriend.org:
 +    Linux|GNU/k*BSD)

 Maybe better use:

 Linux|GNU|GNU/*)

 this way it works on GNU/Hurd and possibly other GNU-ish systems.

Fine by me. Do you happen to know whether this actually fixes the build
on kfreebsd? If it does I'll fix the package and forward a patch
upstream.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#631689: Bug#639176: fdm: diff for NMU version 1.6-4.1

[Frank Terbeck]

gregor herrmann wrote:
 I've prepared an NMU for fdm (versioned as 1.6-4.1) and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.

Hey gregor,

I actually got an updated package ready since about a month. I just
didn't get to asking my sponsor to upload it yet. The updated code is
here:

  https://github.com/ft/debian_fdm

An appropriate .orig.tar.gz file is here:

  https://github.com/downloads/ft/debian_fdm/fdm_1.6+cvs20111013.orig.tar.gz

All that is based on a CVS snapshot from upstream, which is very and
upstream could release as a new version. (I asked the developer about
this a while back, and he said that technically there's nothing that
would forbid releasing the code. He is just very busy and can't make
time ATM.) - Anyway, the updated package would address both bugs you're
addressing.


I'm unsure about what the procedure is now that you got an NMU in the
pipeline.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639176: Bug#631689: Bug#639176: fdm: diff for NMU version 1.6-4.1

[Frank Terbeck]

gregor herrmann wrote:
 On Wed, 09 Nov 2011 18:41:51 +0100, Frank Terbeck wrote:
[...]
 I'm unsure about what the procedure is now that you got an NMU in the
 pipeline.
[...]
 minor things I'd change (e.g. remove the quilt build-dep)
[...]

Yes, good point. I should have done that, when I removed the other
native-quilt stuff. That was kind of the point. ;)

 The package doesn't build twice. Output:
[...]
 dpkg-source: info: local changes detected, the modified files are:
  fdm-1.6+cvs20111013/MANUAL
 dpkg-source: error: aborting due to unexpected upstream changes, see 
 /tmp/fdm_1.6+cvs20111013-1.diff.HRWH5Z
 dpkg-source: info: you can integrate the local changes with dpkg-source 
 --commit
 dpkg-buildpackage: error: dpkg-source -b fdm-1.6+cvs20111013 gave error exit 
 status 2


 Quick guess: MANUAL get's created during build, and it should be
 removed again in clean (or the upstream build system needs a patch to
 remove it during clean).

Yes, true again. And quite correctly guessed.

I'm doing most of my work on my laptop, where I'm running stable. The
dpkg-source there doesn't pass `--abort-on-upstream-changes' per
default, which is why I never saw this.

I added a debian/source/local-options file to add that option.

 Just decide which option you prefer :)

Well, I prefer whichever gets this over with the fastest. ;)

If you've got the time, I wouldn't mind if you'd just uploaded an
updated package. The github repo contains additional changes, which
addresses the issues you've raised.

If you see any other problems, shout. :)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#648246: fdm: FTBFS(kfreebsd): Unable to configure for GNU/kFreeBSD

[Frank Terbeck]

Hi there,

Christoph Egger wrote:
 Package: src:fdm
 Version: 1.6+cvs20111013-1
[...]
 Your package failed to build on the kfreebsd-* buildds:
[...]
 test -f config.mk || sh configure
 Unable to configure for GNU/kFreeBSD

Yeah well, `fdm' uses a simple configure script now to setup the build
for a number of known systems. The old system did have support for the
BSD flavours of debian.

I think the `Linux' setup should do the trick (that's what the old build
system did anyway). Could you try if the following patch makes the
package build again? (Also: Is there a still netbsd port? If not the
pattern I used could also be Linux|GNU/kFreeBSD)).

Regards, Frank


diff --git a/configure b/configure
index 9d83f6b..812ba5b 100755
--- a/configure
+++ b/configure
@@ -26,7 +26,7 @@ EOF
 EOF
;;
 # 
--
-Linux)
+Linux|GNU/k*BSD)
cat EOF $CONFIG_H
 #define HAVE_SETRESUID
 #define HAVE_SETRESGID



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#646046: manual page still refers to /etc/zshenv

[Frank Terbeck]

Norbert Kiesel wrote:
 man zsh says Commands are first read from /etc/zshenv; this cannot be 
 overridden.,
 but this was changed to /etc/zsh/zshenv at some point.  Likewise for 
 zprofile, zlogin,
 and zshrc.

Hey Norbert,

This is actually a build-time option. `--enable-etcdir=' to be specific.

The manual used to present the wrong paths, since the package was build
from a release tarball, which had pre-built manual pages, so that people
didn't have to install yodl to build them for themselves.

I thought we started providing a tarball generated from upstream's
version control with the new package (starting from debian version
4.3.12-1). With that, the manuals are build when the package is built,
using the right values from the build-time options. That's why the new
package has a build-dependency on yodl now.

Upstream's build system is prepared to handle all of that automatically,
via the Docs/version.yo file, which is generated at build-time.

Since it's kind of hard to get a fixed up tarball onto the debian
servers, this will have to wait until upstream releases 4.3.13 - which
is not too far away, unless someone finds a grave bug in the current
code.

Thanks for reporting. Otherwise I may have never realised we were still
using release tarballs as the basis for the package, rather than
tarballs generated from the release's corresponding version control tag.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#645112: Full error message and a patch from Ubuntu

[Frank Terbeck]

Sven Joachim wrote:
 | checking for library containing tigetflag... no
 | checking for library containing tgetent... no
[...]
 Ubuntu has hit this bug as well, see [1].  The attached patch against
 git is stolen from [2], with the commit message edited to close the
 Debian bug for your convenience.

Full service bug report. Thanks! ;)

 Note that libtinfo is only available since ncurses 5.9-2, so you should
 probably bump the libncursesw5-dev build-dependency.  Or come up with
 something more sophisticated if you want the package to build unmodified
 in Squeeze.
[...]
 -CONFIGFLAGS += --with-tcsetpgrp --with-term-lib=ncursesw
 +CONFIGFLAGS += --with-tcsetpgrp --with-term-lib=ncursesw tinfo

Actually, that's exactly the right thing to do. `--with-term-lib='
should test all listed libraries for the required functions, but it'll
stop as soon as it finds a library that satisfies the needs. And if
that's `ncursesw', then the build system will be happy.

FWIW, I tested building the package with the altered setting on one of
my stable systems and it builds fine.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#176626: screen: mini-curses type of interface for screen -r w/ multiple screens?

[Frank Terbeck]

Axel Beckert wrote:
[...]
 zsh, at least with grml's zshrc, allows proper tab completion for
 screen sessions:

There is nothing special about this completion (because you mentioned a
certain setup file).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578466: Shouldn't correct to rm too easily

[Frank Terbeck]

A. N. Other wrote:
 You can use the variable CORRECT_IGNORE to exempt commands from
 correction. E.g.:

 CORRECT_IGNORE=_*|rm

I'm firmly against doing such configuration in the global configuration
file (which is doing too much already - but that's another problem).

It is something the user should decide for her/himself.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639176: fdm: FTBFS: unsatisfiable build-dependency: tdb-dev (= 1.1.1~svn26294-1.1) (versioned dep on a virtual pkg?)

[Frank Terbeck]

[...]
 The following packages have unmet dependencies:
  sbuild-build-depends-fdm-dummy : Depends: tdb-dev (= 1.1.1~svn26294-1.1)

Right.

That should be replaced with libtdb-dev nowadays, I guess. I'll be
preparing an updated package as soon as spare time permits.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#631689: fdm: FTBFS with ld --as-needed

[Frank Terbeck]

Ilya Barygin wrote:
[...]
 The package fails to build when --as-needed linker option is enabled,
 because of incorrect order of parameters passed to ld. Here's a log of
 failed build in Ubuntu:

 https://launchpadlibrarian.net/71869810/buildlog_ubuntu-oneiric-i386.fdm_1.6-4build1_FAILEDTOBUILD.txt.gz

 See also
 http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries

 The attached patch was used in Ubuntu to fix the problem.
 https://launchpad.net/ubuntu/+source/fdm/1.6-4ubuntu1

Oops. Sorry for taking forever. I was sure I already answered to this
one... Anyway, that patch looks right, and the upstream Makefile¹
handles it like that already.

I'll query upstream about a new release. ...the last one has been a
while. If that should not happen in due time, I'll include this patch in
the package.

Regards, Frank

http://fdm.cvs.sourceforge.net/viewvc/fdm/fdm/GNUmakefile?view=markup



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#634609: zsh: debian/control uses hardcoded list of non-Linux architectures

[Frank Terbeck]

Robert Millan wrote:
[...]
  Build-Depends: libfoo-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386]

vs.

  Build-Depends: libfoo-dev [linux-any]

 Please consider making this adjustment to make life easier for future
 porting efforts.

I guess

 
http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=7c61c9184e5dd3c88dc6c7757e580c74e82eaac2

should do the trick then. Thanks for pointing it out.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#634609: zsh: debian/control uses hardcoded list of non-Linux architectures

[Frank Terbeck]

 Robert Millan wrote:
  Build-Depends: libfoo-dev [linux-any]

Sorry, I read your mail way too quickly.

Using one positive architecture specification is definitely preferable
to several negated ones. So, here's a patch on top of the previous ones,
which should do the trick (really, this time):

 
http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=fbaba904b5374b3a8661d0fb02fd167ec9f5dc73



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#632140: PATCH: _aptitude: Completion for -F format specifiers

[Frank Terbeck]

From: Daniel Bolton d...@dbbo.us

Received via the Debian BTS: #632140

Thanks!
---
 Completion/Debian/Command/_aptitude |   35 ++-
 1 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/Completion/Debian/Command/_aptitude 
b/Completion/Debian/Command/_aptitude
index bfec497..2c462e4 100644
--- a/Completion/Debian/Command/_aptitude
+++ b/Completion/Debian/Command/_aptitude
@@ -13,6 +13,39 @@ ${${(M)${(f)$(/etc/apt/sources.list)}\
   #}}}
 }
 
+# Helper function for -F / --display-format
+function _aptitude_format_strings() {
+  _values -s , 'format string' \
+'%%[Literal %]' \
+'%#number[Parameter replacement]' \
+'%a[Action flag]' \
+'%A[Action]' \
+'%B[Broken count]' \
+'%c[Current state flag]' \
+'%C[Current state]' \
+'%d[Description]' \
+'%H[Hostname]' \
+'%i[Pin priority]' \
+'%I[Installed size]' \
+'%m[Maintainer]' \
+'%M[Automatic flag]' \
+'%n[Program version]' \
+'%N[Program name]' \
+'%o[Download size]' \
+'%p[Package name]' \
+'%P[Priority]' \
+'%r[Reverse depends count]' \
+'%R[Abbreviated priority]' \
+'%s[Section]' \
+'%S[Trust status]' \
+'%t[Archive]' \
+'%T[Tagged]' \
+'%u[Disk usage change]' \
+'%v[Current version]' \
+'%V[Candidate version]' \
+'%Z[Size change]'
+}
+
 _arguments -C \
   '(- 1 *)'{-h,--help}'[display help information]' \
   '(- 1 *)--version[display version information]' \
@@ -20,7 +53,7 @@ _arguments -C \
   '(-d --download-only)'{-d,--download-only}[just download packages - don\'t 
install] \
   '(-P --prompt)'{-P,--prompt}'[always display a prompt]' \
   '(-y --assume-yes)'{-y,--assume-yes}'[assume yes answer to questions]' \
-  '(-F --display-format)'{-F,--display-format}'[specify output format for 
search command]:format' \
+  '(-F --display-format)'{-F,--display-format}'[specify output format for 
search command]:format:_aptitude_format_strings' \
   '(-O --sort)'{-O,--sort}'[specify sort order]:sort order:()' \
   '(-w --width)'{-w,--width}'[specify output width]:width' \
   '-f[aggressivley try to fix dependencies of broken packages]' \
-- 
1.7.6




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630906: git-annex completion gone missing

[Frank Terbeck]

Joey Hess wrote:
 bash does not complete git antab, or git annex getab
 but it does complete git annex get somefiletab with filenames,
 which is all that's really needed.

Here is an update: Tonight I kicked the following series towards
zsh-workers:

  http://www.zsh.org/mla/workers/2011/msg00954.html


The first patch from that series pretty much gives you bash-like
behaviour out of the box, which should be enough to close this bug, once
it's included (I didn't commit any of the patches yet, but I will unless
someone complains loudly).


However, the second patch allows for a *lot* more: You can just drop a
`_git-annex' function file somewhere into `$fpath'. Then

  zsh% git atab

would suggest `annex' as one of the possibilities (if `git-annex' is
found in `$path'). The `_git-annex' function could then handle
completion for `annex' in depth.

  zsh% git annex --tab
  zsh% git annex tab
  zsh% git annex add tab

...could all be handled appropriately.

Such a file could be maintained with annex (in which case you'd have to
drop it into `$fpath' - since 4.3.12-1 that could be
`/usr/share/zsh/vendor-completions/'). Or it could be maintained
upstream like `_git-buildpackage' is.


In any case, here is a start for _git-annex:

[snip]
#compdef git-annex
#desc:managing files while ignoring their content

local state line context
local -A opt_args

local -a arguments
arguments=(
'--force[force something]'
'--fast[don'\''t be slow]'
'--verbose[tell me more]'
': :-command'
'*:: :-subcmd'
)

_arguments -C $arguments

case $state in
(command)
local -a cmds
cmds=(
add:'add files to the annex'
drop:'useful description after the colon'
get
map
move
status
)
_describe -t commands command cmds
;;
(subcmd)
case ${line[1]} in
(map|status)
_message 'No more arguments'
;;
(*)
_path_files
;;
esac
;;
esac
[snap]

I've got no idea of what git-annex does, so the above is just based on
skimming through http://git-annex.branchable.com/git-annex/. But I
think it already handles the vast majority of required cases. They just
need to be added by someone.

If you (or one of your contributors) wants to do that and run(s) into
problems, feel free to ask pkg-zsh-de...@lists.alioth.debian.org for
assistance. ;)

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#631795: PATCH: _apt: add markauto and unmarkauto sub-commands

[Frank Terbeck]

From: Sebastian Ramacher s.ramac...@gmx.at

Received via Debian BTS #631795:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631795

Thanks!
---
 Completion/Debian/Command/_apt |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Completion/Debian/Command/_apt b/Completion/Debian/Command/_apt
index 788fe31..3200fc9 100644
--- a/Completion/Debian/Command/_apt
+++ b/Completion/Debian/Command/_apt
@@ -438,7 +438,9 @@ _apt-get () {
 /$'build-dep\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages 
$expl_packages[@] avail' \# \| \
 /$'autoremove\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages 
$expl_packages[@] installed' \# \| \
 /$'help\0/' \| \
-/[]/ ':argument-1::compadd $expl_action[@] update upgrade install 
remove purge dist-upgrade dselect-upgrade clean autoclean check source 
build-dep autoremove help'
+/$'markauto\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages 
$expl_packages[@] installed' \# \| \
+/$'unmarkauto\0'/ /$'[^\0]#\0'/ ':packages::_deb_packages 
$expl_packages[@] installed' \# \| \
+/[]/ ':argument-1::compadd $expl_action[@] update upgrade install 
remove purge dist-upgrade dselect-upgrade clean autoclean check source 
build-dep autoremove help markauto unmarkauto'
 
   _apt-get () {
 local expl_action expl_packages
-- 
1.7.5




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630906: git-annex completion gone missing

[Frank Terbeck]

Joey Hess wrote:
 The basic git-annex completion that was added to partially fix #603503
 has gone missing, now zsh can neither complete git anntab, nor can it
 complete git annex foo somefiltab

Just to let you know this didn't fall through the cracks...

The 4.3.12 release of zsh includes a (more or less) rewrite of _git (the
completion function for git). I guess the guy who did it wasn't aware of
git-annex and therefore didn't re-add support for it.

I'm not sure what the plan is with respect to adding third-party
addons. I guess just adding the old code again would be a feasible
solution (and we can certainly do that with the debian package for the
time being), but for the long run I'd like to discuss this upstream.

Out of curiosity, is there a git-annex completion for bash? And if so,
how does the bash crowd handle such third-party addons?

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630906: git-annex completion gone missing

[Frank Terbeck]

Joey Hess wrote:
 Frank Terbeck wrote:
[...]
 Out of curiosity, is there a git-annex completion for bash? And if so,
 how does the bash crowd handle such third-party addons?

 bash does not complete git antab, or git annex getab
 but it does complete git annex get somefiletab with filenames,
 which is all that's really needed.

Yeah, falling back to file-name completion is probably something _git
should do out of the box.  I'll look into that.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630987: Bug#630987: Tab-completion is totally broken

[Frank Terbeck]

Axel Beckert wrote:
[...]
 http://iki.fi/juhtolv/configs/shellrc/

 Thanks. That may help later with debugging the issue.

Actually, what I'd be way more interested in, is if the zsh defaults
plus compsys trigger the problem, too:

% zsh -f
% autoload -Uz compinit
% compinit

...and then, in that fresh shell (after the compinit call), retry.

If that *still* yields the problem then the problem is not with your
setup and I'd bet on compcache being the culprit. Then you'd

% rm ~/.zcompdump

...and retry.

If the problem is caused by your configuration (which I doubt, if it
worked with 4.3.11), then we'd need a minimal example that triggers the
problem.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#623522: screen tab completion should allow /dev/ devices

[Frank Terbeck]

Joey Hess wrote:
 Screen supports being run like: screen /dev/ttyUSB0 [baud], so it would
 be nice if zsh would not block tab completion in /dev.

Agreed.  I'll be committing the following upstream in a minute (or
five):

-8

From f8337312651a496c7f16a1218fb276cc9439b6f7 Mon Sep 17 00:00:00 2001
From: Frank Terbeck f...@bewatermyfriend.org
Date: Thu, 21 Apr 2011 19:47:00 +0200
Subject: PATCH: _screen: support /dev/ttyUSB0 [baud] arguments

This fixes debian bug #623522:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623522

Regards, Frank
---
 Completion/Unix/Command/_screen |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/Completion/Unix/Command/_screen b/Completion/Unix/Command/_screen
index 4d3b089..931946c 100644
--- a/Completion/Unix/Command/_screen
+++ b/Completion/Unix/Command/_screen
@@ -3,6 +3,18 @@
 local curcontext=$curcontext state line expl
 local scr_cmds sessions
 
+function __screen_normal() {
+if (( CURRENT == 1 ))  [[ $PREFIX == /dev/* ]]; then
+_path_files -g '*(%)'
+elif (( CURRENT == 2 ))  [[ ${words[1]} == /dev/* ]]; then
+_message baud rate
+elif (( CURRENT  2 ))  [[ ${words[1]} == /dev/* ]]; then
+_message no more parameters
+else
+_normal $@
+fi
+}
+
 scr_cmds=(
   acladdaclchgacldelaclgrp
   aclumask  activity  addaclallpartial
@@ -91,7 +103,7 @@ _arguments -C \
   '-Dx: :-any-sessions' \
   '-dx: :-any-sessions' \
   '-X[execute command as a screen command in the specified 
session]:screencmd:(${scr_cmds[@]})' \
-  '*::arguments: _normal'
+  '*::arguments: __screen_normal'
 
 if [[ -n $state ]]; then
   case $state in
-- 
1.7.4.1.140.g89781




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#623522: screen tab completion should allow /dev/ devices

[Frank Terbeck]

Frank Terbeck wrote:
 Joey Hess wrote:
 Screen supports being run like: screen /dev/ttyUSB0 [baud], so it would
 be nice if zsh would not block tab completion in /dev.

 Agreed.  I'll be committing the following upstream in a minute (or
 five):

I've done that.  We're approaching a 4.3.12 release.  If that happens by
the beginning of next week I won't bother backporting the patch to the
current 4.3.11 package. If .12 takes longer, I'll bite the bullet.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#622933: zsh: Enable completions by default, unless skip_global_compinit is set

[Frank Terbeck]

Daniel Hahler wrote:
 In Ubuntu, the attached patch was applied to achieve the following:

 - debian/zshrc: Enable completions by default, unless
   skip_global_compinit is set

Daniel informed me of this patch on IRC. I think it's a reasonable thing
to have.  I'd just do it slightly different:

case $skip_global_compinit in
 ((#i)on|yes|enable|1) ;;
 (*)
autoload -Uz compinit
compinit
;;
esac
(( ${+parameters[skip_global_compinit]} ))  unset skip_global_compinit

On top of that, I want proper documentation of the behaviour and how to
trigger it in `README.debian'.

Comments?

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#622933: zsh: Enable completions by default, unless skip_global_compinit is set

[Frank Terbeck]

Frank Terbeck wrote:
 Daniel Hahler wrote:
[...]
  ((#i)on|yes|enable|1) ;;
[...]
 Comments?

(#i) requires `extended_glob' to be set, which may or may not be the
case. I could make it work properly but it's too much work. We should
drop the (#i) and live with the fact that the check is case
sensitive. :)

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#622933: zsh: Enable completions by default, unless skip_global_compinit is set

[Frank Terbeck]

Daniel Hahler wrote:
 (( ${+parameters[skip_global_compinit]} ))  unset skip_global_compinit

 I suggest leaving this variable set, instead of unsetting it.

 This way it could get used in a user's zshrc file for example, like
 when we're on Debian/Ubuntu and skip_global_compinit is not set, then I
 have to do it myself here.

Personally, I'd want the variable name space polluted as little as
possible. And there are numerous ways to check whether compsys is loaded
or not without yet another variable.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#620452: no place for packaged zsh libs

[Frank Terbeck]

marc chantreux wrote:
 I would like to make a zshlib-foo.deb file to install a zsh written
 library in a path handled by the default $fpath.

 /usr/local/share/zsh/site-functions is for the local admin stuff.
 /usr/share/zsh/functions/* are for stuff distributed with zsh. 

 i would really appreciate to see a /usr/lib/zsh/functions to put my stuff in.

This isn't as hard as I thought on IRC.

I think we could just

fpath+=( /foo/bar/baz )

in `/etc/zsh/zshenv'.

Because that file is sourced for *every* zsh instance that's ever
started (except if zsh is invoked in sh-mode - but then sh-mode is so
different that I don't care).

We just need to decide what /foo/bar/baz is acceptable in terms of
debian policy etc. So, any comments or suggestions? ...my knowledgeable
debian-certified pkg-zsh colleagues? :-)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Frank Terbeck wrote:
[...]
 Yes, I'll probably commit either this or (more likely) a shorter patch
 that uses emulate -L zsh on top of the function upstream tonight or
 sometime tomorrow.

http://zsh.cvs.sourceforge.net/viewvc/zsh/zsh/Functions/Misc/colors?r1=1.6r2=1.7view=patch



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Frank Terbeck wrote:
[...]
 My suspicion is that this is an effect of an option. Could it be, that
 you're setting the `ksharrays' option? I strongly suspect that you do.
[...]

This supports my claim:

zsh% zsh -fc 'autoload -U colors; colors'
zsh% zsh -f -o ksh_arrays -c 'autoload -U colors; colors'
colors:89: bad set of key/value pairs for associative array
zsh% _


Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
 Frank Terbeck wrote:
 [...]
 My suspicion is that this is an effect of an option. Could it be, that
 you're setting the `ksharrays' option? I strongly suspect that you do.
[...]
 # Arrays should start with zero!
 setopt KSH_ARRAYS

 :-)

 Thanks for your help of figuring my problem out.
[...]
 Anyways, would be cool if the system wide scripts

`colors' is actually a function not a script.

 would reset those kind of settings or set them individually as
 expected as you already suggested.

Yes, that is the general idea. But as you may know, zsh has a
bewildering set of options and other possible settings, that make it
hard to recognise, whether a chunk of code is sensitive to a certain set
of settings or not. So, occasionally issues such as this come up.


[...]
 Are you upstreaming your patch?

Yes, I'll probably commit either this or (more likely) a shorter patch
that uses emulate -L zsh on top of the function upstream tonight or
sometime tomorrow.

Patching the debian package may take a while longer, since we're still
working on a useful workflow for our VCS repository within the newly
formed debian zsh team.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
 $ autoload -U colors
 $ colors
 colors:89: bad set of key/value pairs for associative array

 Commenting out the following line helps:

 /usr/share/zsh/functions/Misc/colors
  89 colour=(${(kv)color}) # A case where ksh namerefs would be useful ...

 Any idea why this fails?

That should only happen if ${#color} is an odd number, which for an
associative array, shouldn't be possible. So, after running your fixed
function, do this:

% print ${(t)color}
% print ${#color}

The first command should print `association', the second should print
an *even* number (`76' for me). Also, a trace might be helpful:

% (set -x; colors;) 21 | cat -v

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
[...]
 (dedeibel@jet)(262/pts)(14:25:13.02.11)-
 (%:~)- print ${#color}
 4

Yeah. I was a little quick about this. This only prints the number of
key-value pairs in the associative array. What we're actually looking
for is this:

% print ${#${(kv)color}}

In any case, `4' is too low a value. what does this print?

% printf '%s = '\''%s'\''\n' ${(kv)color} | sort


 (dedeibel@jet)(263/pts)(14:25:13.02.11)-
 (%:~)- (set -x; colors;) 21 | cat -v
 +/bin/zsh:3 colors
 +colors:4 typeset -Ag color colour
 +colors:6 color=( 00 none 01 bold 02 faint 22 normal 03 standout 23
 no-standout 04 underline 24 no-underline 05 blink 25 no-blink 07
 reverse 27 no-reverse 08 conceal 28 no-conceal 30 black 40 bg-black 31
 red 41 bg-red 32 green 42 bg-green 33 yellow 43 bg-yellow 34 blue 44
 bg-blue 35 magenta 45 bg-magenta 36 cyan 46 bg-cyan 37 white 47
 bg-white 39 default 49 bg-default )
[...]
 Does this tell you anything?

Thanks, I'll take a look at it when I'm on the train.

 What exactly does ${(kv)color} access? Is kv a value?

Those flags are used to access the keys and values of an associative
array:

% foo=( bar baz beer booze zack zonk )
% print ${foo[zack]}
zonk
% print ${(k)foo}
zack bar beer
% print ${(v)foo}
zonk baz booze
% print ${(kv)foo}
zack zonk bar baz beer booze


The latter is used to initialise $colour (British) with the same values
as in $color (American).

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
[...]
 (%:~)- (set -x; colors;) 21 | cat -v
 +/bin/zsh:3 colors
 +colors:4 typeset -Ag color colour
 +colors:6 color=( 00 none 01 bold 02 faint 22 normal 03 standout 23
 no-standout 04 underline 24 no-underline 05 blink 25 no-blink 07
 reverse 27 no-reverse 08 conceal 28 no-conceal 30 black 40 bg-black 31
 red 41 bg-red 32 green 42 bg-green 33 yellow 43 bg-yellow 34 blue 44
 bg-blue 35 magenta 45 bg-magenta 36 cyan 46 bg-cyan 37 white 47
 bg-white 39 default 49 bg-default )

Initialisation looks good.

 +colors:74 local k
 +colors:75 k=bg-blue
 +colors:75 color[${color[$k]}]=bg-blue

This looks wrong already. The actual code is this:

for k in ${(k)color}; do
color[${color[$k]}]=$k
done

So this should iterate over all keys in `$color'. Those should be 00,
01, 02, etc. And not even bg-blue, which is the *value* to the key 44.

 +colors:79 k=30
 +colors:79 color[fg-${color[$k]}]=30
 +colors:79 k=31
 +colors:79 color[fg-${color[$k]}]=31
 +colors:79 k=32
 +colors:79 color[fg-${color[$k]}]=32
 +colors:79 k=33
 +colors:79 color[fg-${color[$k]}]=33
 +colors:79 k=34
 +colors:79 color[fg-${color[$k]}]=34
 +colors:79 k=35
 +colors:79 color[fg-${color[$k]}]=35
 +colors:79 k=36
 +colors:79 color[fg-${color[$k]}]=36
 +colors:79 k=37
 +colors:79 color[fg-${color[$k]}]=37
 +colors:79 k=39
 +colors:79 color[fg-${color[$k]}]=39

This is this loop:

for k in ${color[(I)3?]}; do
color[fg-${color[$k]}]=$k
done

Looks good.

 +colors:83 color[grey]=''
 +colors:84 color[fg-grey]=''
 +colors:85 color[bg-grey]=''

Just a few assignments.

After this, the colours= assignment follows, which is missing in here as
expected, since you commented to out..

 +colors:95 local 'lc=^[[' 'rc=m'
 +colors:97 typeset -Hg reset_color bold_color
 +colors:98 reset_color='^[[m'
 +colors:99 bold_color='^[[m'
 +colors:103 typeset -AHg fg fg_bold fg_no_bold

A few more assignments.

[...]

What follows is the construction of the `$fg[]' and `$bg[]' associative
arrays (and friends). It looks correct but a little short, which I blame
on the first loop from above screwing up.

My suspicion is that this is an effect of an option. Could it be, that
you're setting the `ksharrays' option? I strongly suspect that you do.

[[ -o ksharrays ]]  print option set || print option unset

If you do, a workaround would be to set the ksharrays option *after*
you're running the `colors' function.

A fix would be to either locally unset the `ksharrays' option in this
function, or to use an array expansion, that works independently of this
particular setting. Could you try if this patch fixes the issue even if
`ksharrays' is set?


diff --git a/Functions/Misc/colors b/Functions/Misc/colors
index bef93c8..dfa169a 100644
--- a/Functions/Misc/colors
+++ b/Functions/Misc/colors
@@ -72,7 +72,7 @@ color=(
 # but it's clearer to include them all both ways.
 
 local k
-for k in ${(k)color}; do color[${color[$k]}]=$k; done
+for k in ${(k)color[@]}; do color[${color[$k]}]=$k; done
 
 # Add fg- keys for all the text colors, for clarity.
 
@@ -86,7 +86,7 @@ color[bg-grey]=${color[bg-black]}
 
 # Assistance for the color-blind.
 
-colour=(${(kv)color})  # A case where ksh namerefs would be useful ...
+colour=( ${(kv)color[@]} )   # A case where ksh namerefs would be useful ...
 
 # The following are terminal escape sequences used by colored prompt themes.
 


I think that should fix the issue. However, the simpler fix is to just
say this in the first line of code in the `colors' file:

setopt localoption no_ksharrays

If you could verify my suspicion, that'd be swell.

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613162: zsh: Loading colors script fails, bad set of key/value pairs

[Frank Terbeck]

Benjamin Peter wrote:
 On 02/13/2011 04:50 PM, Frank Terbeck wrote:
[...]
 % printf '%s = '\''%s'\''\n' ${(kv)color} | sort


 Not sure if this does what it was inteded to.

 $ printf '%s = '\''%s'\''\n' ${(kv)color} | sort
  = ''
 ' ${(kv)color} | sortnone = ''

Yes, for you it doesn't, pretty much because of the ksh_arrays option I
mentioned in the other mail.

 When I just do the following I get

 $ print ${(kv)color}
 none

 But I think I figured what you wanted.

 Maybe this?

 printf '%s = %s\n' ${(kv)color[*]} | sort

Actually, I wanted @ and double-quotes rather than *, but for the
involved values, it doesn't make a difference. :)

 Anyway. I tried to to do some kind of single step printf debugging
 after your printf hints and added the files as an attachement.[...]
[...]

Thanks, I'm pretty sure I found the underlying cause by looking at the
xtrace you provided earlier today. See if my ideas around ksh_arrays
help with the problem (I'm fairly sure they will).

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#603503: numerous infelicities in git completion

[Frank Terbeck]

Joey Hess wrote:
 Michael Prokop wrote:
1. git log completes only branches, but not filenames. I try to do
   `git log Foo/Bartab` all the time.
2. git diff ditto

 Both seem to work now, although rather slowly in large repositories.

The guy who wrote large parts of the git completion did a major update,
that didn't make it upstream yet, because sf.net's CVS is still down.

If you want to give it a shot, it's at:

  https://github.com/now/zsh/blob/git/Completion/Unix/Command/_git

In terms of up-to-dateness, it should be quite a bit better than what's
currently shipped with zsh. Unfortunately, it doesn't improve
performance. We know fairly well, where the problem is located, but
fixing is would be a major undertaking.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611175: PATCH: Fix for vcs_info's svn detection

[Frank Terbeck]

Let's try this again, shall we? Apparently, it's harder to use an email
client than it looks. Also, as Mikael informs me on IRC, I screwed up
the patch in the first mail... *sigh*

...now that CVS is back...

Here's a fix for an issue with vcs_info's subversion detection, which
was reported in the debian BTS (issue #611175¹).

The fix was suggested by Lennart Weller.

¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D611175

Regards, Frank


Index: Functions/VCS_Info/Backends/VCS_INFO_detect_svn
===
RCS file: /cvsroot/zsh/zsh/Functions/VCS_Info/Backends/VCS_INFO_detect_svn,v
retrieving revision 1.2
diff -u -r1.2 VCS_INFO_detect_svn
--- Functions/VCS_Info/Backends/VCS_INFO_detect_svn 11 Dec 2008 09:53:13 
-  1.2
+++ Functions/VCS_Info/Backends/VCS_INFO_detect_svn 11 Feb 2011 06:44:51 
-
@@ -7,5 +7,5 @@
 [[ $1 == '--flavours' ]]  return 1
 
 VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
-[[ -d .svn ]]  return 0
+{ [[ -f .svn/entries ]] || [[ -f .svn/format ]] }  return 0
 return 1



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org