Summary: | app-shells/zsh-completion-20091203-r1 is broken because =sys-apps/portage-2.2.0_alpha121 does not install /etc/make.globals symlink | ||
---|---|---|---|
Product: | Portage Development | Reporter: | P Purkayastha <ppurka> |
Component: | Unclassified | Assignee: | Gentoo Shell Tools project <shell-tools> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ave, commando2004, lukas, mackal.cook, magnus.lidbom, martin, mva, poncho, skrattaren |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Fixed zsh-completion |
Description
P Purkayastha
2012-08-19 09:40:25 UTC
Just chiming in to say I'm experiencing broken completion for emerge in alpha121 as well. It only showed a small subset of packages for completion. It may well have been only packages from overlays. Downgrading to alpha120 fixed it for me as well. It probably broke because portage-2.2.0_alpha121 no longer installs the /etc/make.globals symlink. If so, then zsh-completion needs to be updated to use /usr/share/portage/config/make.globals directly. As a temporary workaround, you can create a compatibility symlink like this: ln -s /usr/share/portage/config/make.globals /etc/make.globals Actually, not only /etc/make.globals is hardcoded on many places, but also /etc/make.conf is hardcoded, although /etc/portage/make.conf should be used instead if available. A perhaps faster and certainly cleaner solution, which however requires an additional dependency, is to use `eix --print VAR`. To avoid unnecessary calls and to avoid cutting off trailing newlines through `...` one could use this in a function like this: ReadVar() { [[ -n ${(P)1} ]] && return eval $1'=${$(PRINT_APPEND=X eix --print $1)%X}' } Example usage: ReadVar PORTDIR_OVERLAY || echo "PORTDIR_OVERLAY is not defined" fixed in zsh-completions trunk and I've also created 0.6.1 tag. So, you can bump ebuild to use 0.6.1 and be happy.
Also,
> A perhaps faster and certainly cleaner solution, which however requires an additional dependency, is to use `eix --print VAR`.
I have not sure if it is acceptable to require eix for completions... Maybe, when eix will be portage's part — I'll rewrite completion, but now — I've not best idea than sourcing.
(In reply to comment #4) > fixed in zsh-completions trunk and I've also created 0.6.1 tag. So, you can > bump ebuild to use 0.6.1 and be happy. zsh-completions is not the same as app-shells/zsh-completion. (In reply to comment #5) > (In reply to comment #4) > > fixed in zsh-completions trunk and I've also created 0.6.1 tag. So, you can > > bump ebuild to use 0.6.1 and be happy. > > zsh-completions is not the same as app-shells/zsh-completion. it is. I just misspelled in package name (and don't know before. that someone created double-package). And I talked about https://github.com/zsh-users/zsh-completions/issues/98 (and also app-shells/zsh-completion-99999999 ebuild in my overlay, that currently using this repo (previously it was just fork of app-shells/zsh-completion with my fixes (since it looked like dead), but then I merged gentoo-completions to zsh-users organization on GH)), since repo [for a long time] includes [commited and already fixed by me] completions from last app-shells/zsh-completion. And, as I said before, repo has non-date version tags (0.6.1, currently), so it is possible to change version numeration to human-readable. Or, did you mean, that app-shells/zsh-completion MUST contain ONLY gentoo-related zsh's completions? I installed zsh-completion-0.7.0 using the ebuild from here: http://gpo.zugaina.org/app-shells/zsh-completions and then deleted ~/.zcompdump* and still it couldn't complete package names. I removed this package and restored make.globals and completion worked. Created attachment 329902 [details, diff]
Fixed zsh-completion
Fixed _gentoo_packages and _portage_utils for changes to location of make.conf and lack of /etc/make.globals symlink
Basically what mva did, but their files appear to be very different from the ones in the official repo.
(In reply to comment #7) > I installed zsh-completion-0.7.0 using the ebuild from here: > http://gpo.zugaina.org/app-shells/zsh-completions and then deleted > ~/.zcompdump* and still it couldn't complete package names. I removed this > package and restored make.globals and completion worked. Yes, because this ebuild uses the completions delivered by zsh-completion (without s) and drops the one from zsh-completions (with s) to avoid collisions. I thought they were just copied over, but apparently they weren't. Is zsh-completions on gh the successor of gentoo's zsh-completion? (In reply to comment #9) > Is zsh-completions on gh the successor of gentoo's zsh-completion? Partially. Firstly it was just 9999 version from gentoo-projects (to use up-to-date completion). Then it becomes my own fork of that (since original zsh-comp-9999 became orphaned (no commits for few years). At this time I already added few completions, that not currently included in gentoo's zsh-comp. And then guys from gh://zsh-users organization suggest me to merge my gentoo completions to their featured completions repo. And some time after that I've migrated completions in gh://zsh-completions to fix this, #431958, bug. I'm confirming this bug too, on all my machines. The make.globals symlink improves things. Is there an ebuild that fixes this in an overlay? (In reply to comment #11) > I'm confirming this bug too, on all my machines. The make.globals symlink > improves things. > Is there an ebuild that fixes this in an overlay? my zsh-completion (from mva repo) is fixed, but it (as mentioned above) installs not only gentoo-related zsh-completions. (In reply to comment #12) > my zsh-completion (from mva repo) is fixed, but it (as mentioned above) > installs not only gentoo-related zsh-completions. Thanks, I added the mva overlay, unmasked and installed zsh-completion-99999999, and it seems to work. First it didn't work for some names (e.g. alsa), but after I re-logged in, it was fine. Hope it gets fixed in portage soon. Any ETA on when the fix will be in portage? I set up a new system and was again bitten by this. This bug seems to have been fixed upstream: http://git.overlays.gentoo.org/gitweb/?p=proj/zsh-completion.git;a=commitdiff;h=d9a4597e38afe9cafd90683e75cc87a837e3cbab Only requires packaging now IMHO. Fixed in 20130808. |