Package Details: cjdns-git 22.r7.g2faa4c83-1

Git Clone URL: https://aur.archlinux.org/cjdns-git.git (read-only, click to copy)
Package Base: cjdns-git
Description: A routing engine designed for security, scalability, speed and ease of use
Upstream URL: https://github.com/cjdelisle/cjdns
Licenses: GPL3
Conflicts: cjdns
Provides: cjdns
Submitter: prurigro
Maintainer: prurigro
Last Packager: prurigro
Votes: 38
Popularity: 0.000000
First Submitted: 2012-02-06 04:01 (UTC)
Last Updated: 2023-11-28 16:44 (UTC)

Dependencies (9)

Required by (2)

Sources (1)

Latest Comments

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

prurigro commented on 2013-09-17 02:42 (UTC)

Updated to remove cjdns.install, which ran the command "systemctl --system daemon-reload" on systems with systemd when the package was updated so that systemd wouldn't complain when using systemctl. This turned out to be bad practice, and could have potentially caused issues since all services get reloaded when this is run, so you'll need to run it on your own if you want to skip the warning after a reinstall.

prurigro commented on 2013-09-16 18:54 (UTC)

Updated to remove the pointless python->python2 find/replace in prepare()

prurigro commented on 2013-09-16 06:00 (UTC)

New version of the package! Updates include: - Contrib scripts (the ones that mostly require python2) are no longer included in this package, and to take their place I've created a new package called 'cjdscript' (included in the optional deps) that provides a utility to install and run those scripts from a local installation it maintains. - The /etc/default/cjdns configuration file, used by cjdns.sh for control over a non-system (systemd) cjdns process, is now included in this package rather than the cjdns-git-sysvinit one. @elasticdog: I came up with a solution for providing scripts without including them in this package, let me know what you think if you give it a shot (cjdscript package, or https://github.com/prurigro/cjdscript if don't necessarily want it installed at the system level.) As far as the cmake issue is concerned; the final decision not to use it as a makedep was based on the responses I got when I asked a bunch of the folks on IRC who use the package. I do hear you in respect to not having the PKGBUILD pulling in its own deps though, and I don't consider the debate over (I've just been focusing more on your initial suggestion to remove the scripts untill now.) Fauno filled me in on the logic behind not having installation scripts pull in anything external, and I do agree, though I want to run things by others on the network to make sure there are no excellent arguments in other directions. In respect to libnacl, the cjdns package already includes a compressed file containing libnacl when you run 'git pull', so it's not quite the same situation either. I will follow up in any case. If anyone else has comments on the above discussion, please share them! :)

elasticdog commented on 2013-08-28 20:18 (UTC)

FYI, it looks like the libnacl check wasn't working before [1] (aside from on OpenWrt). I do see where you're coming from regarding the space on your particular machine, but that seems like an edge case...python2 alone is twice the size of cmake. I'd assume that people running on similar platforms would know enough to provide their own workarounds for the space constraints. Anyway, it's mostly a philosophical debate at this point with me preferring to let the package manager explicitly handle dependencies rather than the build process. I could understand leaving libnacl as an optdepends, as it's only available in the AUR, so leaving it optional lowers the barrier to entry. Either way, I'm fine maintaining my own PKGBUILD, but was just offering suggestions on how it would be easiest for the widest audience (I was a TU for 4 years). [1] https://github.com/cjdelisle/cjdns/commit/ba41d71d99f07ab17e3b856fe4e3b6637cb15ce8

prurigro commented on 2013-08-23 07:43 (UTC)

@elasticdog: Hrm, libnacl worked for me last time I tried it, you should give it another shot. The space argument is simple; I have room in my /tmp ramdisk to build cmake but not on my disk to install it, and since cjdns compiles properly both ways, why not allow people to choose whether or not they want to speed up the compile based on their system? In respect to the python2 issue; I've been giving it some thought and agree with you now that makepkg complains about missing deps when the requirements for a script are missing. I plan to see if I can get a package made without pulling the entire sources, and then there's maintenance to consider too... Something will come of this issue in the near future anyway. As far as cherry picking goes though; I've added every utility that I tested successfully, and the ones I didn't were either examples or non-working in one way or another, so it wasn't completely at random.

elasticdog commented on 2013-08-23 06:30 (UTC)

I'm not understanding the space argument. Having cmake as a makedepends ensures that the package is installed, which is the already-compiled binary and should take up less space than having the ./do script download the cmake source and compile those same binaries. Plus, it can be removed after building the package if you don't want it taking up space on your system. Admittedly, I never got the ./do script to properly utilize libnacl when it was installed, but that was a while ago, so perhaps I should try again and take a look at the actual logic in the build script. I still think the python2 utilities should be split out...yes the code is technically in the cjdns repo, but the contrib files are explicitly "not officially part of cjdns but [are] useful as a complement". It just seems like arbitrary cherry picking of certain utilities and ignoring all of the others...none of which are required. Personally, I prefer using cjdcmd and none of the tools from contrib.

fauno commented on 2013-08-21 13:19 (UTC)

I've uploaded a modified version of your PKGBUILD to Parabola's repos. This version builds correctly on a clean chroot. I added python2 and cmake to the makedepends array and didn't remove the CFLAGS, there's a bundled lib that complains about building without optimizations but the rest is ok. Thanks! https://projects.parabolagnulinux.org/abslibre/abslibre.git/tree/pcr/cjdns-git/PKGBUILD

prurigro commented on 2013-08-21 07:10 (UTC)

The package has been updated! Changes include moving sysvinit support into a separate package and adding numerous optional dependencies. @elasticdog: The problem with adding cmake to the makedepends is that people are then required to have cmake installed, which some systems don't have the space for (my tinykvm node for example) In respect to nacl; cnacl is simply upstream nacl with a cmake build script written by cjd, so if you have the upstream nacl installed (provided by the libnacl package in the AUR), you can skip the cnacl build step too. Neither of these packages are required, but they're both useful if you can afford the space to install them, and you've raised a good point about people not being aware that they can speed things up by having them, so I've thrown them into the optional dependencies array with explanations :) As for sysvinit support; despite deprecation (I actually believe it's been made obsolete if I'm not mistaken), people using Arch as a chroot environment (which is done as one of the methods for running cjdns on an Android phone, for example) don't have systemd running in the background, and having an init script is useful. Now that said, you've made me realize that it's a pretty fringe case at this point, and I've opted to move support into a different package which I've added to the optional dependencies array as well. The pythons junk is a bit different since those scripts come from within the cjdns repo itself, and therefore moving support into another package would mean having everyone who wants them installed to download cjdns twice each update... If split packages were compatible with the AUR I'd switch cjdns-git over in a heartbeat (you might notice that the PKGBUILD is already configured to make the transition), but in the meantime, if you don't want support for those scripts you can simply comment out the line in the package() function that calls the function that adds them.

elasticdog commented on 2013-08-20 20:46 (UTC)

My $0.02 would be to have the package include cmake for the makedepends so you can utilize the regular Arch package and bypass downloading it via the ./do install script. I'd hope that long-term, the ./do install script would get away from downloading and installing any dependencies and just let the package manager deal with them. Perhaps a package for 'cnacl' should be made. Anyway, I'd also suggest dropping the sysvinit stuff altogether as it has been deprecated since November of last year and the final official warning about its removal went out over six months ago. You could then split out the other utilities into their own 'cjdns-contrib-python' or whatever package so people wouldn't have to do any manual editing of the PKGBUILD.

prurigro commented on 2013-08-20 20:18 (UTC)

@fauno: Ahoy there! The build should work without cmake, does it not for you? Also, python2 is an optional dep to support certain scripts, and it was done like this on purpose after some debate (though the debate is still open), but is there a point in the actual build process that requires python2-config, or is script support what you were referring to? I just ran some tests and wasn't able to find it if there is... Cheers!

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