Package Details: parcimonie-sh-git 78.529e2fa-1

Git Clone URL: https://aur.archlinux.org/parcimonie-sh-git.git (read-only, click to copy)
Package Base: parcimonie-sh-git
Description: Bash reimplementation of parcimonie
Upstream URL: https://github.com/EtiennePerot/parcimonie.sh
Licenses: custom:WTFPL
Submitter: EtiennePerot
Maintainer: freswa (EtiennePerot)
Last Packager: EtiennePerot
Votes: 21
Popularity: 0.000003
First Submitted: 2013-07-10 04:53 (UTC)
Last Updated: 2023-02-26 07:09 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

EtiennePerot commented on 2017-08-08 02:17 (UTC)

That's one of a number of issues with the perot.me URL that have been posted here so far, so I finally caved in and switched it to use the GitHub URL now.

nirnakinho commented on 2017-08-07 16:16 (UTC)

The git://perot.me/ url does not work for me, the git pull (ipv6) times out. Pinging perot.me via ipv4 works, pings via ipv6 do not return anything. This might be a problem on my side, as I don't have native ipv6 but have to use a tunnel. However, accessing the repository forcing to use ipv4 (git clone -4), git returns with an error saying the connection was reset. An IPv6 traceroute shows the path like this: 3.|-- 10ge2-20.core1.ber1.he.ne 10.0% 10 15.8 16.6 15.5 21.6 2.0 4.|-- 100ge3-1.core1.ams1.he.ne 10.0% 10 35.1 31.7 29.2 37.4 3.1 5.|-- 100ge9-1.core1.lon2.he.ne 10.0% 10 42.9 45.1 37.3 58.2 5.8 6.|-- 100ge4-1.core1.nyc4.he.ne 70.0% 10 105.4 105.6 105.4 105.8 0.2 7.|-- 100ge10-1.core1.nyc6.he.n 10.0% 10 105.4 106.2 105.4 107.8 1.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 (done with mtr -r -6 perot.me, the percentages are packet loss) Regards,

EtiennePerot commented on 2017-08-05 02:02 (UTC)

Fixed.

respiranto commented on 2017-08-04 17:24 (UTC)

The license is not properly set and there is no license file being installed as per the Arch Wiki [0]. [0] https://wiki.archlinux.org/index.php/PKGBUILD#license

EtiennePerot commented on 2017-05-31 03:20 (UTC)

Seems to work for me: $ git clone git://perot.me/parcimonie.sh Cloning into 'parcimonie.sh'... remote: Counting objects: 197, done. remote: Compressing objects: 100% (195/195), done. remote: Total 197 (delta 104), reused 0 (delta 0) Receiving objects: 100% (197/197), 60.99 KiB | 0 bytes/s, done. Resolving deltas: 100% (104/104), done.

pigmonkey commented on 2017-05-31 03:18 (UTC)

The source in the pkgbuild refers to git://perot.me/parcimonie.sh

EtiennePerot commented on 2017-05-31 03:11 (UTC)

jackrandom: This package's upstream URL already points there. What old URL are you referring to?

niv commented on 2017-05-30 21:18 (UTC)

use https://github.com/EtiennePerot/parcimonie.sh, as old one returns 404.

lamarpavel commented on 2016-11-01 11:11 (UTC)

I just stumbled upon this piece on the manpage of makepkg.conf: >BUILDDIR="/path/to/directory" > If this value is not set, packages will, by default, be built in subdirectories of the directory that > makepkg is called from. This option allows setting the build location to another directory. Incorrect use > of $startdir in a PKGBUILD may cause building with this option to fail. And then from man PKGBUILD(5): >startdir > This contains the absolute path to the directory where the PKGBUILD is located, which is usually the output of $(pwd) when makepkg is > started. Use of this variable is deprecated and strongly discouraged. This might help you fix the PKGBUILD to properly build with AUR-helpers that set BUILDDIR. However, this will not yet fix the problem with packages always recognized as outdated due to a different pkgver from the version in the AUR.

lamarpavel commented on 2016-07-30 10:08 (UTC)

I don't know, sorry. I haven't spent much time writing PKGBUILDs so far, I just had this problem and tried to figure out how to get it working. I'm not sure about sourcing the pkgver from the last git commit though, as it also causes a discrepancy between the locally installed version and the one in the AUR (which currently has 48.9344ede-1, compared to the installed 1.7093957-1) and thus confuses automated update-checks. I have seen this behaviour with other *-git packages as well, not sure what to do. Maybe add a release-tag to the repo and then have this package refer to the release version rather than the newest commit?

« First ‹ Previous 1 2 3 4 Next › Last »