Package Details: cjson-git 1.7.18.r11.g12c4bf1-2

Git Clone URL: https://aur.archlinux.org/cjson-git.git (read-only, click to copy)
Package Base: cjson-git
Description: Ultralightweight JSON parser in ANSI C
Upstream URL: https://github.com/DaveGamble/cJSON
Keywords: json
Licenses: MIT
Conflicts: cjson
Provides: cjson
Submitter: None
Maintainer: a821
Last Packager: a821
Votes: 2
Popularity: 0.000000
First Submitted: 2012-09-19 07:13 (UTC)
Last Updated: 2025-04-02 17:37 (UTC)

Dependencies (3)

Required by (63)

Sources (1)

Latest Comments

1 2 Next › Last »

FSMaxB commented on 2017-03-27 21:15 (UTC) (edited on 2017-03-27 21:21 (UTC) by FSMaxB)

> You only have to update the build steps whenever the build process changes (or the tests as I reported in an issue on GH). You do not need to touch the PKGBUILD upon new releases because this PKGBUILD will pull master and compile it. People won't receive updates if the package is not updated with a new release. This is especially problematic if there are security updates. EDIT: They will receive updates only if they manually install it, but won't get notified by AUR helpers that there is a new release.

<deleted-account> commented on 2017-03-27 20:35 (UTC)

Added you as a co-maintainer. > Using your own fork or using it to bisect bugs seems useful (at least in theory). But other than that it's kind of pointless. I am the maintainer of upstream cJSON and the master branch will always contain the same commits as the latest release. A lot of packages on AUR follow this scheme. You cannot garantee that you will always have the latest commit on the regular package, or only if you have some kind of CI that will push latest releases to the PKGBUILD on each commit. > I can update the the package when I release a new version and keep the PKGBUILD in sync with the cjson package. You only have to update the build steps whenever the build process changes (or the tests as I reported in an issue on GH). You do not need to touch the PKGBUILD upon new releases because this PKGBUILD will pull master and compile it.

FSMaxB commented on 2017-03-25 09:55 (UTC)

Using your own fork or using it to bisect bugs seems useful (at least in theory). But other than that it's kind of pointless. I am the maintainer of upstream cJSON and the master branch will always contain the same commits as the latest release. If you want to add me as comaintainer, go ahead, I can update the the package when I release a new version and keep the PKGBUILD in sync with the cjson package.

<deleted-account> commented on 2017-03-24 21:42 (UTC)

I can keep the ownership but I would feel better if the creator of the stable version have the control of the rolling release one too. I think you should not delete this package nonetheless, it allows users to compile against latest commits or their own fork if they tweak the Github URL in the PKGBUILD. It is common to both have mypackage and mypackage-git on AUR. Maybe the solution is to add you as a co-maintainer (never saw that option before, should be quite recent).

FSMaxB commented on 2017-03-22 10:10 (UTC)

Sorry for not responding, I didn't enable email notifications for this package. If you still want me to take over, I can do it. Although I would just try to get openresty-lua-libcjson to switch over to the other cjson package and then delete this one.

<deleted-account> commented on 2016-12-27 10:39 (UTC)

New release using upstream after FSMaxB's comment

<deleted-account> commented on 2016-11-24 15:35 (UTC)

Also I see that you use tags on Git so you should also provide cjson apart from cjson-git using latest tag instead of master

<deleted-account> commented on 2016-11-24 15:34 (UTC)

Sorry for this outdated packaging, the build was failing so I took ownership in order to make it build again from Sourceforge. If you use Archlinux often, you may want to take ownership of this package and tune it for using the new repo? (I don't know how to change ownership, maybe I should disown and you take it back) Please reply so that I can disown and give you access to this, it is not a very difficult task imo (just create script that poll from github/master and done)

FSMaxB commented on 2016-11-24 15:27 (UTC)

This is horribly outdated and contains security flaws. Also the license is MIT, not LGPL (yes, pohuguet put a GPL in the fork on GitHub, but the C Source files still contain the MIT license). cJSON now has it's official home on GitHub (https://github.com/DaveGamble/cJSON) and I made an official release since I took over as a maintainer. Note that a lot of bugs have been fixed sind 2013, some of them quite relevant for security.

<deleted-account> commented on 2015-03-03 19:01 (UTC)

Took this package ownership as it was marked as orphan and updated it (fix from last comment + using git commit in pkgver()).

1 2 Next › Last »