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 »

fauno commented on 2013-08-20 19:40 (UTC)

it needs cmake on makedepends :) (it also wants "python2-config" but it continues without it)

prurigro commented on 2013-08-09 06:58 (UTC)

Package Update: PKGBUILD now unsets $MAKEFLAGS to avoid issues like elasticdog had when non-default values are set elasticdog: rather than specify -j1, I simply unset the variable from makepkg.conf so whatever cjd sets is used instead- let me know if you continue to have issues, and thanks for reporting!

elasticdog commented on 2013-08-08 06:15 (UTC)

I think you'll want to add `export MAKEFLAGS="-j1"` to the build() section in order to prevent issues with compilation (re: https://wiki.archlinux.org/index.php/Makepkg.conf#MAKEFLAGS). I had my MAKEFLAGS set to -j8 in /etc/makepkg.conf on and kept having trouble compiling the package due to odd failures.

prurigro commented on 2013-08-05 17:27 (UTC)

CJD fixed the cmake stuff for >=2.8.11, so I've updated the package to remove my conditional hack since it works regardless of the conditions now.

prurigro commented on 2013-08-01 06:34 (UTC)

Package Update! * The PKGBUILD has been cleaned up a bit more, and I fixed a few small things with the help of namecap (good call facecool) * The install script now warns a user when they don't have python2 installed, and explains that certain scripts won't work without it (to reduce confusion) * A new patch has been included that sets the 'do' script to allow the current archlinux version of cmake rather than compiling 2.8.8 itself, and it's applied when libnacl is installed. (The 'do' script fails when cmake 2.8.11 tries to build nacl) I think that's all for now- cheers!

prurigro commented on 2013-08-01 01:29 (UTC)

facecool: Hey there! I double checked and can confirm that I'm also running cmake 2.8.11.2 on my system, and running ./do to build cjdns definitely still downloads cmake 2.8.8 to use instead of the system one. To confirm that 2.8.11.2 is indeed still broken (since it was my patch that removed it from the whitelist originally: https://github.com/cjdelisle/cjdns/commit/ed439b48943443d84e947347c10d5dbc6e76f078), I temporarily whitelisted 2.8.11* in ./do and ran the script, which promptly failed during the nacl portion of the build. I decided to see what would happen if I installed libnacl to bypass its portion of the build process, and this time everything builds successfully! Apparently only the nacl portion is broken. Now that said, I've weighed the pros and cons of setting nacl as a dependency, and I feel like explicitly setting it makes some assumptions about the user's needs. It also means that if an updated libnacl is released that breaks compatibility with cjdns, everyone on arch is going to break until this can be resolved, rather than only those with libnacl installed... That said, I do like the idea of making fast compile times possible again for those with a compatible configuration, so I'm going to try and make it so the internal cmake will be used when libnacl is installed along with the next release. As for the python2 stuff- I've asked around to see how others using the package feel, and everyone I've talked to so far has wanted to keep python2 as an optional dependency. In respect to a split package solution to make everyone happy, I've actually been maintaining one on gitboria alongside this (hence the package() function being split into functions by category.) Now you might have more up to date information than me regarding some workaround using $PKGBASE, but last I'd checked the AUR wasn't able to parse split packages to have them included (they'd fail on attempted upload). I haven't attempted to try again quite yet, but I did check back at the (now infamous) bug thread on the matter though (https://bugs.archlinux.org/task/16394) and it seems like people are suggesting solutions that take advantage of $PKGBASE, but there's been no followup about an attempt at implementing one of these ideas, and the bug is still marked open. If you have some information I haven't been able to find on the matter though, that would preferably work without any ugly hacks, I'd love to hear it- a single split package would definitely be preferable to maintain :) Are you available on IRC (preferably efnet, freenode or hypeirc) or xmpp? I feel like discussing this in real time might be beneficial if it's possible :)

facecool commented on 2013-07-29 13:18 (UTC)

Namcap (pacman -Si namcap) is a pacman package analyzer which aims to find errors made during package building. In order to satisfy various set of systems you may use pkgbase (https://wiki.archlinux.org/index.php/PKGBUILD#pkgbase) to build a split set of packages. This will help to build lightweight packages aside of full versions. But you will need python2 as makedepends anyway. As for my system arch's native cmake (2.8.11.2) was able to build a cjdns binaries. Currently testing them on virtual machine.

prurigro commented on 2013-07-29 12:31 (UTC)

Also, what do you mean in regards to namecap?

prurigro commented on 2013-07-29 12:29 (UTC)

Hi facecool, thanks for the patch! The reason cmake isn't included in the makedepends is because the current version included in arch (2.8.11) uses different syntax than the cmake cjdns was written for (>2.8.10 iirc), and while cjd is rewriting the build process using node because of this, you'd need an older version of cmake installed or the package will simply build one on it's own anyway at the moment. On a side note, you can skip building nacl if you install a compatible version of that, too. As for the python2 stuff... The python2 package is pretty big for smaller systems (~65 megs), so while I wanted to provide the python2 scripts, I didn't want to make python2 a requirement either. I figured I'd make it simple for people to comment support out completely if they didn't want the scripts built into the package at all (by commenting out the function that includes them in the package function), and I made python2 an optional dependency so it could be added at any time after to enable support for those scripts (or even temporarily at a point when they're needed), but your right about this being a bit confusing when you install and find they don't work... Thoughts on how this might be done better? Also, do you think it's worth using python2 to set the path? Do people use different directories that would make this a worthwhile thing to do?

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