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.)
Git Clone URL: | https://aur.archlinux.org/zsh-zim-git.git (read-only, click to copy) |
---|---|
Package Base: | zsh-zim-git |
Description: | ZIM - Zsh IMproved |
Upstream URL: | https://github.com/zimfw/zimfw |
Keywords: | improved plugin theme vim zim zsh |
Licenses: | MIT |
Submitter: | ishitatsuyuki |
Maintainer: | carbolymer (Rhinoceros) |
Last Packager: | Rhinoceros |
Votes: | 19 |
Popularity: | 0.000000 |
First Submitted: | 2015-12-28 02:13 (UTC) |
Last Updated: | 2022-01-18 13:11 (UTC) |
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 source
ing 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:
zmodule
in /etc/zsh/zimrc
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.
Pinned Comments
carbolymer commented on 2021-01-11 21:41 (UTC) (edited on 2021-01-22 07:46 (UTC) by carbolymer)
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=5a378e94d516c57d39629de545b78b0f020d86a4I 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:
zmodule
in/etc/zsh/zimrc
zimfw install && zsh