If you want block efficient, then zfs is your friend
1) make the 'dir' be a distinct zfs filestore in the zpool
2) run zfssnap on some duty cycle
3) profit
seriously: as long as the copy can be maintained readonly, in sync
with the source, the block level copy of zfs snapshots under some
serial/t
> On 13 Oct 2016, at 6:39 AM, reko.turja--- via freebsd-ports
> wrote:
>
> The software should be relatively lightweight - no fullblown mirroring/backup
> is needed. Also hints how to achieve similar ends using maybe tar/ssh might
> do.
Try cpdup(1).
Cheers,
Franco
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 att
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
mirr
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
Thanks for the sug
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&build=2016-10-12_17h10m03s
> and I have
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&build=2016-10-12_17h10m03s
and I have not applyed that
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 net/ost
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
https://lists.freebsd.o
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 of
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 i
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,
svn-src-h...@freebsd.org
Aut
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, like
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 def
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 - https://reviews.freebsd.org
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
>> bina
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
>> bina
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, you
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
mani
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 p
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
> are unsuitable for so
23 matches
Mail list logo
