Package Details: zsh-zim-git r458.1ab110c-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
Licenses: MIT
Submitter: ishitatsuyuki
Maintainer: ishitatsuyuki (Eriner)
Last Packager: ishitatsuyuki
Votes: 20
Popularity: 0.098056
First Submitted: 2015-12-28 02:13
Last Updated: 2018-12-31 10:46

Dependencies (4)

Required by (4)

Sources (3)

Pinned Comments

ishitatsuyuki commented on 2020-01-10 06:36

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.

Latest Comments

1 2 3 4 5 6 Next › Last »

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.

Rhinoceros commented on 2020-01-10 12:09

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.

ishitatsuyuki commented on 2020-01-10 06:36

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.

Rhinoceros commented on 2020-01-08 06:17

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

ishitatsuyuki commented on 2019-09-29 12:00

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

bbaserdem commented on 2019-09-28 17:29

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.