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
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
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
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
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
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
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
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
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
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
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,
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,
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
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 -
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
>>
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
>>
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,
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
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
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
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
>
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
22 matches
Mail list logo