Hello all,
I say that just new joined OpenBSD family. I have used different operating
systems for a long time. Now, I have a new notebook on this notebook hand to
i7-2630QM Intel processor.
I've tested it with many different distributions and I've observed overheating
problems in all of them. I
GPL rsync allows tunneling an rsync:// connection to a daemon through
an explicitly given -e command. Specifically, you can rsync the
repository from sthen@'s mirror through ssh this way:
$ rsync -av --del -e 'ssh -W localhost:rsync -lanoncvs' \
rsync://anoncvs.spacehopper.org/OpenBSD-CVS/ /c
Hi,
Ingo Schwarze wrote on Sat, Mar 30, 2019 at 02:14:43PM +0100:
> Christian Weisgerber wrote on Sat, Mar 30, 2019 at 10:34:59AM -:
>> I think that if openrsync ever grows anywhere near the number of options
>> that the GPL rsync has, listing them all in usage/synopsis will be
>> unfeasible.
+1 for adding ID 31
Maybe add the proper one but also keep the old to give people some time
to update their stuff if this is a problem.
There should be more than enough reserved IDs.
On 3/30/19 8:35 PM, Reyk Floeter wrote:
> I like the idea of switching it to the proper ID.
>
> Reyk
>
>> Am 30.
I think we should switch, waiting doesn't help.
Reyk Floeter wrote:
> I like the idea of switching it to the proper ID.
>
> Reyk
>
> > Am 30.03.2019 um 20:31 schrieb Stuart Henderson :
> >
> > curve25519 had a proper ID (31) assigned in 2016 but we still have
> > the draft private-use ID in i
I like the idea of switching it to the proper ID.
Reyk
> Am 30.03.2019 um 20:31 schrieb Stuart Henderson :
>
> curve25519 had a proper ID (31) assigned in 2016 but we still have
> the draft private-use ID in iked. Any thoughts on whether we can just
> cut across to the proper ID, or whether that
curve25519 had a proper ID (31) assigned in 2016 but we still have
the draft private-use ID in iked. Any thoughts on whether we can just
cut across to the proper ID, or whether that will be too painful?
Are many people using this already?
Hi Stuart,
I'm glad to see people are using this.
There's some smaller fixes that I haven't sent to the list yet, so
probably I'll send an updated diff on monday.
Regards,
Tobias
On 3/30/19 6:43 PM, Stuart Henderson wrote:
> This diff hasn't gone anywhere recently - I've been using it since
> To
This diff hasn't gone anywhere recently - I've been using it since
Tobias posted it with no problems. Any comments on whether it should
go in, and if so, before/after 6.5? The feature is disabled by default.
Index: config.c
===
RCS fi
Hi,
Christian Weisgerber wrote on Sat, Mar 30, 2019 at 10:34:59AM -:
> On 2019-03-30, Jason McIntyre wrote:
>> we could use: [--del[ete]]
>> that looks ugly, but is short and clear. kind of vi(1) style.
>>
>> we could just note in the description of --delete that it can be
>> abbreviated to
On 2019-03-30, Jason McIntyre wrote:
> we could use: [--del[ete]]
> that looks ugly, but is short and clear. kind of vi(1) style.
>
> we could just note in the description of --delete that it can be
> abbreviated to --del. that would add the least amount of text, but not
> show up in usage/synops
On Tue, Mar 26, 2019 at 03:52:47PM +0100, Michał Koc wrote:
> W dniu 25.03.2019 o 15:08, Otto Moerbeek pisze:
> > On Sat, Mar 23, 2019 at 06:07:02PM +0100, Michał Koc wrote:
> >
> > > ... [snip]
> > This is almost good. You might fold host_ip() into net_set_sa(). the
> > double malloc and copy is
On Sat, Mar 30, 2019 at 08:15:11AM -, Christian Weisgerber wrote:
> Oops, I guess I should document --del.
>
hi.
i'm ok with this, but i wonder if it's the best way to do it? this way,
neither usage() or SYNOPSIS provide a hint that --del and --delete are
the same. and the size of both is in
Oops, I guess I should document --del.
Index: main.c
===
RCS file: /cvs/src/usr.bin/rsync/main.c,v
retrieving revision 1.37
diff -u -p -r1.37 main.c
--- main.c 30 Mar 2019 07:24:42 - 1.37
+++ main.c 30 Mar 2019 08:1
14 matches
Mail list logo
