Arch Linux User Repository

Ugh, it was a PITA to create this package. Please note that errors are silenced, so if you have any issues with zim, remove &>/dev/null from your /etc/zshrc - https://aur.archlinux.org/cgit/aur.git/tree/zshrc?h=zsh-zim-git&id=5a378e94d516c57d39629de545b78b0f020d86a4

I had to do it this way: $ZIM_HOME is only writable by root and zim constantly tries to update & recompile itself (=write to $ZIM_HOME), which results in permission errors when starting zsh as a normal user.

If you want to add/remove a module:

1. Add a respective zmodule in /etc/zsh/zimrc
2. Run as root: zimfw install && zsh

@Rhinoceros, thanks for the hint. I've added it to the package.

I've checked powerlevel10k, and it works fine without zim interaction i.e. I've installed aur package and added

source /usr/share/zsh-theme-powerlevel10k/powerlevel10k.zsh-theme

to /etc/zsh/zshrc below lines sourcing zim.

If you would like to use zim, this also works for me: https://github.com/zimfw/zimfw/issues/368#issuecomment-631520836 but you need to add this zmodule to /etc/zsh/zimrc (which is symlinked by ~root/.zimrc) and then do zimfw install

Thanks so much @carbolymer! This seems to work well, although I had some problems with my old ~/.zimrc. I had to remove the error suppression in /etc/zsh/zshrc to figure out the problem.

Do you know what the syntax is now to use pacman-installed modules? In the past I linked the files, e.g.

# ln -s /usr/share/zsh-theme-powerlevel10k /usr/lib/zim/modules/prompt/external-themes/powerlevel10k
# ln -s /usr/share/zsh-theme-powerlevel10k/powerlevel10k.zsh-theme /usr/lib/zim/modules/prompt/functions/prompt_powerlevel10k_setup

then put zprompt_theme='powerlevel10k' into ~/.zimrc, but this now fails silently. I tried zmodule powerlevel10k instead, but this fails with

x /home/rhinoceros/.zimrc:34:powerlevel10k: Not installed. Run zimfw install to install.
Failed to source /home/rhinoceros/.zimrc

I also had one minor suggestion. Instead of using + as a sed delimiter, which will break if this character is in filenames, you could instead use parameter expansion to prevent this limitation.

(Also, there was some discussion here regarding packaging that you might like to contribute to.) Thanks again!

Ugh, it was a PITA to create this package. Please note that errors are silenced, so if you have any issues with zim, remove &>/dev/null from your /etc/zshrc - https://aur.archlinux.org/cgit/aur.git/tree/zshrc?h=zsh-zim-git&id=5a378e94d516c57d39629de545b78b0f020d86a4

I had to do it this way: $ZIM_HOME is only writable by root and zim constantly tries to update & recompile itself (=write to $ZIM_HOME), which results in permission errors when starting zsh as a normal user.

If you want to add/remove a module:

1. Add a respective zmodule in /etc/zsh/zimrc
2. Run as root: zimfw install && zsh

@mattia,

I can't even call these changes anything other than outright malware. Force reverting and purging from history, disowning, do not do this sudo curl | zsh nonsense ever again, do not rewrite PKGBUILDs to not actually package anything, do not download unchecksummed sources outside of source=() and mysteriously execute them like this.

@mattia makepkg really shouldn't require sudo. It should be capable of creating a package in a user-owned location. In any case, I'm not sure what the purpose of this sudo is in the PKGBUILD. It's just for the curl right? Why would that need sudo? Finally, it looks like the PKGBUILD attempts to directly run install.zsh from upstream. Doesn't that immediately attempt to install zim rather than place it into the pkgdir? Running makepkg certainly shouldn't be creating anything at /usr/lib/zim!

FWIW there's been an extensive discussion upstream on how to fix this broken package, but there was no resolution.

@carbolymer now it should go, I forgot a sudo. Thanks so much for the warning

this package is broken

mkdir: cannot create directory ‘/usr/lib/zim’: Permission denied

x Could not download the Zim script to /usr/lib/zim/zimfw.zsh

FWIW I agree with @bus. If I no longer have an interest in maintaining a package, I orphan it. This shows users that there is no one actively maintaining it, and may inspire others to adopt it. Hence the previous adoption drives. If we don't know which are unmaintained, then we can't adopt them. I also don't view it as my responsibility to protect against future "malicious intents". (Also, despite your earlier response, you aren't exactly responding to the "request" to update the package! And the fix is certainly actionable, at least in theory.)

Well, I could say either way, but the out-of-date flagging isn't really actionable. If you're not going to contribute, then I don't really see any point on discussing this meta-issue.

@ishitatsuyuki I suggest you read the flagging page: "Flagging this package should only be done if the sources moved or changes in the PKGBUILD are required because of recent upstream changes". The package does not build because upstream changed, it's literally out of date by definition.

Also, I don't think that's a correct interpretation of orphaning. It's very commonly done voluntarily when people have no desire to work on their packages, which you said you don't. You're thinking of assisted orphaning via requests, which is performed when the maintainer is not responding.