Re: Packaging Go Libs

2017-05-13 Thread Christian Schwarz
Side note: There is an ongoing effort to build a dependency manager
that aims at becoming part of the official Golang toolchain:

https://github.com/golang/dep

Cheers,

  Christian


signature.asc
Description: This is a digitally signed message part


Re: archivers/py-borgbackup

2017-02-04 Thread Christian Schwarz
On Sat, Feb 04, 2017 at 12:56:02PM -0700, Russell L. Carter wrote:
> So... how do I build archivers/py-borgbackup with poudriere on a
> system that needs 2.7 as default?

You can use poudriere's '-z' flag to build a new SET, with python 3 as
the default version of Python.

The target system can then manually install py3-borgbackup and its
dependencies from that SET repository.

Checkout the CUSTOMISATION section of the poudriere man page for details
on how to use a different make.conf for a SET.

Hope this helps,

  Christian

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


net-im/prosody update commit request

2017-01-24 Thread Christian Schwarz
net-im/prosody is at version 0.9.10 and thus two patch versions behind
upstream [0]

There has been a patch in Bugzilla but the maintainer does not respond:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214487

Could someone please commit this?

Thanks,

  Christian

[0] https://prosody.im/doc/release/0.9.12


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Mumble in pkg

2017-01-24 Thread Christian Schwarz
On Mon, Jan 23, 2017 at 10:33:26PM +0100, Greg Byshenk wrote:
> Ok, so I think what's going on here is that:
> 
> The pkg version of mumble uses the default system OpenSSL, but
> you've installed the OpenSSL port (via the package). This means
> that the port builds fine - using the non-system OpenSSL that 
> you've installed. But the pkg conflicts, because it wants the
> system OpenSSL -- and /usr/local/lib/* is found first.
> 
> There are probably other ways to fix this, but the easiest is
> to either a) remove the OpenSSL pkg, or b) build mumble as a
> port.
> 
> [Corrections welcome if I have something wrong.]

Shouldn't ports migrate away from using base's OpenSSL?

I would consider reporting this as a bug to the port maintainer...

--
Christian
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Preferred directory for server data (/var/db/pkgname?)

2017-01-12 Thread Christian Schwarz
What is the correct directory for storing the state of a server application?

That might be

 - the data directory of a database server
   (MySQL uses /var/db/mysql
Postgres uses /var/db/postgres)
 - Configuration managed by the application, not the admin
   (Quassel uses /var/db/quasselcore)
 - net-im/prosody curiously uses /usr/local/var/lib/prosody
   to store application-managed state data [1]

I am writing this because I stumbled over the net-im/prosody path,
which I think is not intuitive given the behavior of other ports.

But before I submit my patch for this, I would like to know if there is an
actual policy in place.

Taking a look at hier(7):

>/var/  multi-purpose log, temporary, transient, and spool files
>
>   [...]
>
>db/miscellaneous automatically generated
>   system-specific database files

Doesn't seem like the above cases match this description.

Interestingly, the Arch Linux hier(7) has an entry for this kind of data:

> /var/lib/
>State data for packages and subsystems (optional).

What do you think?

--
Christian Schwarz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: mail/p5-Net-SMTP-SSL Deprecated Message.

2017-01-08 Thread Christian Schwarz
On Wed, Dec 14, 2016 at 05:22:08PM +, Matthew Seaman wrote:
> Net::SMTP is a core perl module, or you can install the p5-Net-3.10_1,1
> package to get a slightly newer version of it.
> 
> Net::SMTP has had SSL support capability since version 1.28 way back in
> 2014.  You just need to have IO::Socket::SSL installed too.
> 
> In the intervening 3 or so years, applications are meant to have been
> re-written to use Net::SMTP rather than Net::SMTP::SSL, but clearly this
> has not happened universally.
> 

Is there a plan for ports where upstream doesn't move to Net::SMTP?

Patch them until upstream catches up?

--
Christian Schwarz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

2016-12-20 Thread Christian Schwarz
On Tue, Dec 20, 2016 at 10:12:04AM +0100, Franco Fichtner wrote:
> And lastly... if we have the automatic "default" flavour that is
> defined by the OPTIONS_DEFAULT knobs, we could finally avoid pkg
> upgrading custom builds by knowing that somebody built a "custom"
> version of their port and that there is no equivalent to upgrade
> to.
> 
> This is exciting!

While it is exciting, I would be sad to see flavours be the solution to
pkg not recognizing build OPTIONS_ as part of a package's identity
right now[1].

What is not entirely clear to me:

  Are flavours always a tuple of values for OPTIONS_ defined by their
  master port?

The reason I bring this up: a binary package is identified by the
following information:

  - pkg name (the master's name, unique over ports tree)
  - version & revision
  - the artifacts used to build the binary
(tarballs, but also build dependencies, ...)
  - a vector of available options
  - a vector of values for the available options
  - (other stuff you could probably find in a talk on reproducible
 builds)

It is obvious that a master port will have *many* binary incarnations.
To my understanding, flavours are a comfortable way to write down some
commonly used incarnations.

Reducing the package manager's job to checking that some incarnation of
the package is present is surely better than no support for this.

However, I think the logical next step is to have ports declare that
they depend on a subset of specific configuration values being used in
their dependencies.

In this scenario, flavours are no different to pkg than self-built
ports with custom-picked non-(flavour|standard)ized options.
This, I would very much prefer.

Either way: big thanks to bapt and those who contributed so far!

-- Christian

[1] Please continue reading for what I understand as 'package identity'.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Split irc/quassel into irc/quassel-client and irc/quassel-core

2016-09-06 Thread Christian Schwarz
> May I suggest just having a slave port for quassel-core?  The client and
> mono appear to have the heaviest dependencies.
> 
> Example at https://www.bayofrum.net/~crees/patches/quassel-core.diff (It's
> ready to commit, so if you're happy Max it can go in)
> 

Has anything happened about this?

--
Christian
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: poudriere: howto build ports with 'make -j x'?

2016-08-06 Thread Christian Schwarz
>From my poudriere.conf:

  # By default MAKE_JOBS is disabled to allow only one process per cpu
  # Use the following to allow it anyway
  ALLOW_MAKE_JOBS=no
  
  # List of packages that will always be allowed to use MAKE_JOBS
  # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports
  # which holdup the rest of the queue to build more quickly.
  ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* perl5.20"

Hope this helps!

--
Christian Schwarz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"