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

Thanks @carbolymer. That seems to work perfectly now. Thank you so much for the quick fix (again!). Very much appreciated!

(I just pushed a fix for the zim.install checksum.)

Package should be fixed now.

No worries @carbolymer. Thanks for keeping at it!

Thanks @Rhinoceros for the information. I haven't had much time recently, I'll get back to the issue in a few days.

FWIW I previously installed r601.90de91a-1 perfectly fine, and the latest r606.bd765df-1 now fails to build.

It looks like upstream made some changes to the compilation process in the latest version 1.7.0. From the changelog, I'm not sure if some existing files also need to be removed.

It looks like upstream has changed the structure again, preventing this package from being built. ${srcdir}/install/src/templates now contains only zimrc and zshrc, so line 42–45 of the PKGBUILD fails:

  rcfiles=('zshenv' 'zshrc' 'zlogin' 'zimrc')
  for entry in "${rcfiles[@]}"; do
    cp -L "${srcdir}/install/src/templates/${entry}" $ZIM_TPL_DIR
  done

with zshenv and zlogin now missing. I'm don't understand the installation process enough to know how this changes things, and I can see that zlogin is used later in the PKGBUILD.

@carbolymer you likely saw it already, but just in case, upstream made some changes that might need this PKGBUILD to be modified.

Very strange. Originally it built fine on one of my systems, and another had the problem. However, when I tried to rebuild on the original system, it failed the second time. I also realised my minimal example was in zsh, but even testing with a clean bash shell using env -i bash --norc --noprofile, I still get the 1 exit code.

Thanks for the fix and the add.

@Rhinoceros, that's weird. I don't have this error, nor your minimal example with chmod and foo give me an error. I'm getting return code 0 even in bash. I've included your alternative chmod for the sake of compatibility.

Thanks for the fix.

I've run into another problem, which prevents the package from building:

patching file zimfw.zsh
Hunk #2 succeeded at 62 (offset 1 line).
Hunk #3 succeeded at 95 (offset 1 line).
==> ERROR: A failure occurred in package().
    Aborting...

It seems that the final chmod command has a non-zero exit code because of the symlinks at pkg/zsh-zim-git/usr/lib/zim/modules/zsh-syntax-highlighting/highlighters/*/README.md. Apparently chmod -R with symlinks fails!

$ mkdir dir
$ touch dir/foo
$ ln -s foo dir/bar
$ chmod -R u+rX,g+rX,o+rX dir
mode of 'dir' retained as 0755 (rwxr-xr-x)
neither symbolic link 'dir/bar' nor referent has been changed
mode of 'dir/foo' retained as 0644 (rw-r--r--)
$ echo $?
1

Weirdly I don't think this occurred all the time when building the package. Anyway, I managed to fix it by replacing the final chmod line with a command to ignore symlinks:

find "${ZIM_HOME}" ! -type l -execdir chmod u+rX,g+rX,o+rX {} \;

Upstream changed surrounding lines again. Here is an updated zimfw.zsh.patch.

--- zimfw.zsh   2021-09-21 16:26:34.034179638 +1000
+++ zimfw.zsh   2021-09-21 16:30:58.546504098 +1000
@@ -53,10 +53,6 @@

 _zimfw_build_init() {
   local -r ztarget=${ZIM_HOME}/init.zsh
-  # Force update of init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -R "zimfw() { source ${ZIM_HOME}/zimfw.zsh \"\${@}\" }"
     print -R "zmodule() { source ${ZIM_HOME}/zimfw.zsh \"\${@}\" }"
@@ -65,16 +61,13 @@
     if (( ${#_zfunctions} )) print -R 'autoload -Uz '${_zfunctions#${~zpre}}
     print -R ${(F)_zcmds#${~zpre}}
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build_login_init() {
   # Array with unique dirs. ${ZIM_HOME} or any subdirectory should only occur once.
   local -Ur zscriptdirs=(${ZIM_HOME} ${${_zdirs##${ZIM_HOME}/*}:A})
   local -r zscriptglob=("${^zscriptdirs[@]}/(^*test*/)#*.zsh(|-theme)(N-.)") ztarget=${ZIM_HOME}/login_init.zsh
-  # Force update of login_init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -Rn "() {
   setopt LOCAL_OPTIONS CASE_GLOB EXTENDED_GLOB
@@ -101,6 +94,7 @@
 } \"\${@}\"
 "
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build() {

@Rhinoceros, thanks for the fix! I've updated the package (I've also removed patch file copying as it's really not needed).

Oops, my mistake; I got confused. Upstream just modified surrounding lines. Here is an updated zimfw.zsh.patch that works.

--- zimfw.zsh   2021-07-28 16:45:25.000000000 +1000
+++ zimfw.zsh   2021-07-28 16:45:25.000000000 +1000
@@ -52,26 +52,19 @@

 _zimfw_build_init() {
   local -r ztarget=${ZIM_HOME}/init.zsh
-  # Force update of init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -R "zimfw() { source ${ZIM_HOME}/zimfw.zsh \"\${@}\" }"
     if (( ${#_zfpaths} )) print -R 'fpath=('${_zfpaths:A}' ${fpath})'
     if (( ${#_zfunctions} )) print -R 'autoload -Uz '${_zfunctions}
     print -R ${(F)_zcmds}
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build_login_init() {
   # Array with unique dirs. ${ZIM_HOME} or any subdirectory should only occur once.
   local -Ur zscriptdirs=(${ZIM_HOME} ${${_zdirs##${ZIM_HOME}/*}:A})
   local -r zscriptglob=("${^zscriptdirs[@]}/(^*test*/)#*.zsh(|-theme)(N-.)") ztarget=${ZIM_HOME}/login_init.zsh
-  # Force update of login_init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi
   _zimfw_mv =(
     print -Rn "() {
   setopt LOCAL_OPTIONS CASE_GLOB EXTENDED_GLOB
@@ -98,6 +91,7 @@
 } \"\${@}\"
 "
   ) ${ztarget}
+  chmod -R u+rX,g+rX,o+rX "${ZIM_HOME}" &>/dev/null
 }

 _zimfw_build() {

package() is failing for me.

patching file zimfw.zsh
Hunk #2 FAILED at 66.
Hunk #3 succeeded at 95 (offset -1 lines).
1 out of 3 hunks FAILED -- saving rejects to file zimfw.zsh.rej

Looks like this part of zimfw.zsh.patch is no longer needed, as upstream has already incorporated it:

-  # Force update of init.zsh if it's older than .zimrc
-  if [[ ${ztarget} -ot ${ZDOTDIR:-${HOME}}/.zimrc ]]; then
-    command mv -f ${ztarget}{,.old} || return 1
-  fi

(Also, out of interest, why do you copy the patch before applying it, then delete it? You could always just apply it where it is.)

@Rhinoceros, thanks for debugging and reporting it here! You're right, it is imported twice. I've removed unnecessary line from zshrc:

source ${ZIM_HOME}/init.zsh &>/dev/null

In my opinion this /usr/lib/zim/templates/zshrc works fine, I took it from zimfw repo (which recommends it for enabling zim).

Ah, so modules are being sourced twice because /etc/zsh/zshrc contains two lines

source ${ZIM_HOME}/templates/zshrc &>/dev/null
source ${ZIM_HOME}/init.zsh &>/dev/null

but /usr/lib/zim/templates/zshrc also contains source ${ZIM_HOME}/init.zsh. I'm not sure if this is an error from upstream? I also had a look through /usr/lib/zim/templates/zshrc, and it had a bunch of options in there that I overwrite in ~/.zshrc anyway. It also contained the very nasty HIST_IGNORE_ALL_DUPS, which wrecked my history file! I just removed the first line in /etc/zsh/zshrc and replaced it with

source ${ZIM_HOME}/zimfw.zsh init -q &>/dev/null

This seems to work fine.

No worries @carbolymer. Thanks for the hint. That works great! One other thing is still bugging me… any idea how to stop (e.g.) /usr/lib/zim/modules/environment/init.zsh being sourced twice with each new terminal?

@Rhinoceros Sorry, I've made a mistake in the patch, I forgot to make chmod run recursively. Now the rights should be correct. Regarding adding/removing modules, you can add/remove them to /etc/zsh/zimrc. I've added steps to my pinned comment.

Ugh… I've spent another few hours trying to figure out how to specify what modules are loaded. At the moment, some are loaded twice. e.g. edit /usr/lib/zim/modules/environment/init.zsh and put echo foo at the top, and a new terminal will show foo twice. I also want to disable some, e.g. git. I couldn't see zmodule git in any of the installed files, but there are a few references to git in /usr/lib/zim/init.zsh. Just to test, I removed these references, then did the mandatory touch ~/.zimrc as before. I also noticed that /usr/lib/zim/init.zsh is owned by root:root with 600 permissions, so to avoid errors I had to make it 644 instead (is that a bug?). This seemed to work, in that the git module was no longer active.

1) What is the best way to load/unload modules?

2) Is the fact that /usr/lib/zim/init.zsh is not user-readable correct?

Thanks again @carbolymer for your continued assistance. I can appreciate that this is a very fiddly package, so thanks for staying with it.

Your suggestion for zshmarks works perfectly. This command modifies /usr/lib/zim/init.zsh. I feel like it may be better to modify a user-owned file, but I think by default there is only one init.zsh. I can see /usr/lib/zim/init.zsh is sourced by /etc/zsh/zshrc. I wonder if a better solution is for users to copy init.zsh to somewhere in their home directory, with /etc/zsh/zshrc sourcing this file instead? I guess since /etc/zsh/zshrc is in the PKGBUILD's backup array, users can always do this themselves. Or is it better for the PKGBUILD to do this? I haven't delved too deeply in it, but a possible positive of making init.zsh (and other things?) is that there will be no errors? But a possible negative is that zimfw might try to automatically update (although this could be disabled by default).

I've cloned zshmarks to /usr/lib/zim/modules then added zmodule zshmarks to /etc/zsh/zimrc, then sudo zsh then zimfw install && zsh and it works.

The command which causes

mv: cannot move '/usr/lib/zim/init.zsh' to '/usr/lib/zim/init.zsh.old': Permission denied

is zrecompile which is necessary I think. The only workaround is to silence this error.

I've added a patch for part of force update you suggested though, thanks for the hint!

Another bit of weirdness. After updating the package, I have to touch ~/.zimrc in order for it to be sourced in the future at all. It might be related to line 55 of /usr/lib/zim/zimfw.zsh?

  # Force update of init.zsh if it's older than .zimrc

This might need to be patched for installation by a package manager.

Also, regarding the general suppression of error messages, I wonder if a cleaner way would be to patch out the specific command that causes the error

mv: cannot move '/usr/lib/zim/init.zsh' to '/usr/lib/zim/init.zsh.old': Permission denied

FWIW I only ever get this one error. I had a brief look, and I think the command might also be in /usr/lib/zim/zimfw.zsh.

Thanks again @carbolymer! Manually sourceing powerlevel10k works perfectly. By your GitHub link, did you mean this alternative would require installing powerlevel10k without pacman? I'd much prefer for the package manager to keep everything updated, so if so I'll just use the manual way instead.

On a related note, might you have any suggestions for how to get zshmarks working? I'm the maintainer. Previously I just symlinked the entire project directory into /usr/lib/zim/modules/zshmarks, then edited ~/.zimrc to add zshmarks to the zmodules array, but this no longer works. I tried zmodule zshmarks instead, but this also fails.

Actually, the post after your link suggests this should work, but it doesn't seem to be working for me.

@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.

@bus Do not flag packages out-of-date for any reasons other than versions (which means that you should never flag a VCS package)!

I'm not going to let some random person take over this package without verifying they don't have malicious intents. Orphaning is only required when the maintainer (is intending to) no longer responds to any comments or requests.

Ah yes true. Thanks for the reply. I'll have a bit of a play and see if I can work out how to install it at a system level first, but yes, I might end up the same way.

I just switched to a user level install and I'm fine with that since I'm the only one using the computer anyway.

And using a package is not the only way to update, you could just set up a cron job or whatever.

Fair enough. TBH I thought about creating the stable zsh-zim package, but a brief look at upstream confused me. Out of interest, will you continue to use zsh-zim? And if so, will you just install it at a user-level?

EDIT: that's not my preference because I'd never remember to update it.

Since the upstream doesn't like zimfw getting packaged for global installation, and porting seems to be harder with the latest template changes, I'm going to stop maintaining this package. Contributions are still welcome.

This no longer builds for me.

==> Starting package()...
cp: cannot create regular file '/tmp/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/templates/zshrc': No such file or directory

It looks like the subdirectory templates is no longer present upstream.

Also, regarding the previous comments, there's now a stable release out: https://github.com/zimfw/zimfw/releases

Since zimfw does not have any releases at this point, I don't see any point in doing that.

As a git package, I believe the proper way of doing this package is have it conflict and replace zsh-zim; so when there is a stable release there can be a git package and a release package.

I don’t think that helps in any way. I already do that in the install file, and all you need is a rebuild and install of zsh-zim-git.

After each update, zsh floods the console with following error message: https://pastebin.com/A91n9eBR. The solution is to invoke:

sudo find /usr/lib/zim/modules -iname "*.zwc" -exec rm -f {} \;

and reinstal zsh-zim-git. I think this should be added to the prepare() in PKGBUILD.