1. 14 Oct, 2017 1 commit
  2. 12 Oct, 2017 2 commits
  3. 08 Oct, 2017 2 commits
  4. 03 Oct, 2017 3 commits
  5. 30 Sep, 2017 7 commits
  6. 28 Sep, 2017 2 commits
  7. 27 Sep, 2017 1 commit
  8. 26 Sep, 2017 2 commits
    • girgen's avatar
      Add libght to the ports tree · 96f0cfcf
      girgen authored
      PR:	221577
    • rodrigc's avatar
      devel/buildbot*: Update to 0.9.11, Add buildbot-grid-view · 0cd42e5c
      rodrigc authored
      * Update to buildbot 0.9.11
      * Add required devel/py-buildbot-grid-view dependency
      * Clean up stuff from individual Makefiles that was copy/pasted from the main buildbot Makefile
      * buildbot-www, buildbot-grid-view, buildbot-console-view, buildbot-waterfall-view cannot be tested outside
         of buildbot, so remove stuff from their Makefiles to simplify.
      Reviewed_by: koobs, asomers, sunpoet
      Approved by: grembo
      Differential_Revision: https://reviews.freebsd.org/D12479
  9. 24 Sep, 2017 3 commits
  10. 22 Sep, 2017 3 commits
  11. 21 Sep, 2017 2 commits
  12. 20 Sep, 2017 1 commit
  13. 17 Sep, 2017 2 commits
    • cs's avatar
      Pijul is a version control system based on patches, that can mimic the · 936678d3
      cs authored
      behaviour and workflows of both Git and Darcs, but contrarily to those systems,
      Pijul is based on a mathematically sound theory of patches.
      Pijul was started out of frustration that no version control system was at the
      same time fast and sound:
      - Git has non-associative merges, which might lead to security problems.
        Concretely, this means that the commits you merge might not be the same as
        the ones you review and test.
      - Handling of conflicts: Pijul has an explicit internal representation of
        conflicts, a rock-solid theory of how they behave, and super-fast data
        structures to handle them.
      - Speed! The complexity of Pijul is low in all cases, whereas previous attempts
        to build a mathematically sound distributed version control system had huge
        worst-case complexities. The use of Rust additionally yields a blazingly fast
      WWW: https://pijul.org/
    • dbaio's avatar
      Add devel/py-pytest-cov, pytest plugin for measuring coverage · d3299b17
      dbaio authored
      This plugin produces coverage reports. It supports centralised testing and
      distributed testing in both load and each modes. It also supports coverage of
      All features offered by the coverage package should be available, either through
      pytest-cov or through coverage's config file.
      WWW: https://github.com/pytest-dev/pytest-cov
      Reviewed by:	koobs
      Differential Revision:	D12394
  14. 15 Sep, 2017 1 commit
    • dumbbell's avatar
      lang/rust: Install Cargo + use bundled crates · 0b663e6d
      dumbbell authored
      This port now provides Cargo. This is the recommended now because Cargo
      won't be provided separately in the future.
      To build Cargo, we set `extended = true` in `config.toml`. As a side
      effect, this flag also installs Rust source code. The port has a new
      `SOURCES` option (disabled by default) to keep those sources.
      As a consequence of this, `devel/cargo` is removed. Several ports
      and Makefiles in Mk were updated to depend on `lang/rust` instead of
      The other big change in this patch is the use of the bundled crates,
      instead of relying on Cargo's registry (which was part of the distfiles,
      in order to allow offline builds). So now, we don't need to prepare the
      registry when updating this port.
      This has several other benefits:
          * It fixes the build with sudo(8).
          * It fixes the use of the ino-64 patch (it was not applied to the
            registry, thus not used).
      Compilation errors were fixed in the ino-64 patch.
      Various `.cargo-checksum.json` files are updated after the sources are
      patched (FBSD10_FIX, ino-64, and so on). This fixes builds which were
      failing with errors such as:
          error: the listed checksum of `.../rustc-1.19.0-src/src/vendor/lzma-sys/xz-5.2.3/build-aux/config.rpath` has changed:
          expected: c8b4c017079da9dfb3086a0583e60ffe736184d89005dc5973f0bb0fd17c04bb
          actual:   561b00eb30ecaef2c9da17bc195e7d2a7ea63facea38ea9849fbb0ed340bebba
      PR:		221088
      Reported by:	joneum@, nwhitehorn@, romain@,
      		Ekaterina Vaartis <vaartis@cock.li>,
      Differential Revision:	https://reviews.freebsd.org/D11783
  15. 14 Sep, 2017 3 commits
  16. 11 Sep, 2017 2 commits
  17. 10 Sep, 2017 2 commits
    • tota's avatar
      - Add new port: devel/R-cran-withr · f9fabbd9
      tota authored
        A set of functions to run code 'with' safely and temporarily modified
        global state. Many of these functions were originally a part of the
        'devtools' package, this provides a simple package with limited
        dependencies to provide access to these functions.
        WWW: https://cran.r-project.org/web/packages/withr/
    • tota's avatar
      - Add new port: devel/R-cran-lubridate · 537bab66
      tota authored
        Functions to work with date-times and time-spans: fast and user
        friendly parsing of date-time data, extraction and updating of
        components of a date-time (years, months, days, hours, minutes, and
        seconds), algebraic manipulation on date-time and time-span objects.
        The 'lubridate' package has a consistent and memorable syntax that
        makes working with dates easy and fun.
        WWW: https://cran.r-project.org/web/packages/lubridate/
  18. 07 Sep, 2017 1 commit
    • ed's avatar
      Add a package for ARPC. · 2e775f00
      ed authored
      ARPC is an RPC library similar to GRPC. Though a lot simpler than GRPC
      featurewise, it has transparent support for file descriptor passing.
      ARPC is used by some applications related to CloudABI, like Flower
      (CloudABI's networking daemon).
      Reviewed by:	riggs
      Differential Revision:	https://reviews.freebsd.org/D12103