Re: Alternatives to rsync

2016-10-12 Thread Peter Beckman
1. rsync IS open source: https://rsync.samba.org/ "rsync is an open source utility" 2. Why is GPL3 out of the question? Is the user going to resell the device as a service? If the user is simply "using" the software, no disclosure of other software is necessary. Only if your user is

Alternatives to rsync

2016-10-12 Thread reko.turja--- via freebsd-ports
One of my users is needing rsync like functionality to transfer changed contents of some directories between couple of machines. As rsync 3 isn't open source, but GPL3 it's out of question in order to keep the system untainted. The software should be relatively lightweight - no fullblown

Re: qa.sh stripped warning

2016-10-12 Thread Kyle Evans
Hi, On Wed, Oct 12, 2016 at 10:35 AM, Mathieu Arnold wrote: > The warning will never be turned into errors. Maybe add a comment to the > makefile saying that files must not be stripped. Maybe a bit like go > ports do it, something like: > > STRIP= # Elf firmwares, do not strip

Re: protobuf 3.1.0

2016-10-12 Thread Kurt Jaeger
Hi! > When I went to do a pull request they said the issue does not exist with > protobuf 3.1.0 > https://github.com/pstavirs/ostinato/issues/199 > > My poudriere server succfuly built net/ostinato > http://45.62.227.38/build.html?mastername=amd64-testing=2016-10-12_17h10m03s > and I have not

Re: protobuf 3.1.0

2016-10-12 Thread E.J. Bevenour
When I went to do a pull request they said the issue does not exist with protobuf 3.1.0 https://github.com/pstavirs/ostinato/issues/199 My poudriere server succfuly built net/ostinato http://45.62.227.38/build.html?mastername=amd64-testing=2016-10-12_17h10m03s and I have not applyed that patch

Re: protobuf 3.1.0

2016-10-12 Thread Kurt Jaeger
Hi! > Hi, I have submitted two patches to fix zbackup for protobuf 3.1.0 at > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212973 > > I am wondering if this can be resolved as soon as possible. I'm testbuilding net/ostinato with protobuf 3.1.0 and it fails to build. Your patch to

Re: protobuf 3.1.0

2016-10-12 Thread Kurt Jaeger
Hi! > Hi, I have submitted two patches to fix zbackup for protobuf 3.1.0 at > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212973 > > I am wondering if this can be resolved as soon as possible. I'll have a look, with 3.1.0, and I'll testbuild... It'll take a while. -- p...@opsec.eu

protobuf 3.1.0

2016-10-12 Thread E.J. Bevenour
Hi, I have submitted two patches to fix zbackup for protobuf 3.1.0 at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212973 I am wondering if this can be resolved as soon as possible. ___ freebsd-ports@freebsd.org mailing list

Re: qa.sh stripped warning

2016-10-12 Thread Mathieu Arnold
Le 12/10/2016 à 16:29, Kyle Evans a écrit : > Hello! > > I've got a port with a dozen+ ELF binaries for microcontroller > firmware that I don't think I should be stripping, but qa.sh does not > like this. They're *.elf and *.lib files, so I don't know that adding > these to the general exception

qa.sh stripped warning

2016-10-12 Thread Kyle Evans
Hello! I've got a port with a dozen+ ELF binaries for microcontroller firmware that I don't think I should be stripping, but qa.sh does not like this. They're *.elf and *.lib files, so I don't know that adding these to the general exception of `find` in stripped() is necessarily a good idea, but

install header files required for development with libzfs_core

2016-10-12 Thread Andriy Gapon
JFYI. I bumped __FreeBSD_version to 1200013 to mark this change. Forwarded Message Subject: svn commit: r307131 - head/include Date: Wed, 12 Oct 2016 07:08:32 + (UTC) From: Andriy Gapon To: src-committ...@freebsd.org, svn-src-...@freebsd.org,

Re: harder and harder to avoid pkg

2016-10-12 Thread Kubilay Kocak
On 12/10/2016 8:12 PM, Matthew Seaman wrote: > On 2016/10/12 09:43, Kubilay Kocak wrote: >>> You are describing the 'sub-packages' concept that has been >>> knocking around for some time. With sub-packages you'ld divide up the result of staging each port into various chunks: >> Yep,

Re: harder and harder to avoid pkg

2016-10-12 Thread Vlad K.
On 2016-10-12 10:27, Julian Elischer wrote: what I really need is a RUNTIME option that produces a package with only those files needed to satisfy external run-time depdencies, or the actual demands of the user itself. However since those files are Right. But then the question is how do you

Re: harder and harder to avoid pkg

2016-10-12 Thread Matthew Seaman
On 2016/10/12 09:43, Kubilay Kocak wrote: >> You are describing the 'sub-packages' concept that has been knocking >> > around for some time. With sub-packages you'ld divide up the result >> > of staging each port into various chunks: > Yep, like this: > > Mar 6 2016 -

Re: harder and harder to avoid pkg

2016-10-12 Thread Kubilay Kocak
On 12/10/2016 5:55 PM, Matthew Seaman wrote: > On 11/10/2016 19:59, Julian Elischer wrote: >> As the number of dependencies between packages get ever higher, it >> becomes more and more difficult to compile packages and the >> dependence on binary precompiled packages is increased. However >>

Re: harder and harder to avoid pkg

2016-10-12 Thread Kubilay Kocak
On 12/10/2016 5:55 PM, Matthew Seaman wrote: > On 11/10/2016 19:59, Julian Elischer wrote: >> As the number of dependencies between packages get ever higher, it >> becomes more and more difficult to compile packages and the >> dependence on binary precompiled packages is increased. However >>

FreeBSD ports you maintain which are out of date

2016-10-12 Thread portscout
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated,

Re: harder and harder to avoid pkg

2016-10-12 Thread Julian Elischer
On 12/10/2016 1:13 AM, Vlad K. wrote: On 2016-10-11 20:59, Julian Elischer wrote: are unsuitable for some situations. We really need to follow the lead of some of the Linux groups and have -runtime and -devel versions of packages, OR we what woudlbe smarter, woudl be to have several "sub

Re: harder and harder to avoid pkg

2016-10-12 Thread Vlad K.
On 2016-10-11 20:59, Julian Elischer wrote: are unsuitable for some situations. We really need to follow the lead of some of the Linux groups and have -runtime and -devel versions of packages, OR we what woudlbe smarter, woudl be to have several "sub manifests" to allow unpacking in different

Re: harder and harder to avoid pkg

2016-10-12 Thread Andrea Venturoli
On 10/12/16 09:24, Matthieu Volat wrote: And GNU/Linuxes can be a PITA when you have to track -dev(el) packages (which sometimes really requires -bin, -app or whatever), or worst, describe to people how they are supposed to build your software with weird subpackage names. I really like that

Re: harder and harder to avoid pkg

2016-10-12 Thread Matthieu Volat
On Tue, 11 Oct 2016 11:59:47 -0700 Julian Elischer wrote: > As the number of dependencies between packages get ever higher, it > becomes more and more difficult to compile packages and the dependence > on binary precompiled packages is increased. However binary packages >

Re: harder and harder to avoid pkg

2016-10-12 Thread Matthew Seaman
On 11/10/2016 19:59, Julian Elischer wrote: > As the number of dependencies between packages get ever higher, it > becomes more and more difficult to compile packages and the dependence > on binary precompiled packages is increased. However binary packages are > unsuitable for some situations. We