Package Details: zsh-zim-git r588.de7d2b1-1

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: carbolymer
Votes: 19
Popularity: 0.000000
First Submitted: 2015-12-28 02:13
Last Updated: 2021-09-30 06:55

Pinned Comments

carbolymer commented on 2021-01-11 21:41

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

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

eschwartz commented on 2021-01-06 02:11

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

Rhinoceros commented on 2021-01-03 22:44

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

Anonymous comment on 2021-01-03 16:51

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

carbolymer commented on 2021-01-03 12:25

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

Rhinoceros commented on 2020-02-22 22:44

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

ishitatsuyuki commented on 2020-02-19 14:26

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.

bus commented on 2020-02-19 14:18

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

ishitatsuyuki commented on 2020-02-19 13:34

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

Rhinoceros commented on 2020-01-10 12:15

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.

ishitatsuyuki commented on 2020-01-10 12:12

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.