Thus said "Andy Bradford" on 07 Jul 2014 14:40:51 -0600:
> I'm not sure that this is what is happening in this case. The
> --httptrace output only showed 3 gimme cards requested and none of them
> are on the SHUN list.
Ok, apparently the --httptrace that was sent was not representat
On Mon, Jul 7, 2014 at 5:03 PM, Joe Mistachkin wrote:
>
> Joe Prostko wrote:
>>
>> Is there any chance those two files can be updated?
>>
>> They are available at the following links:
>>
>> config.guess:
> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
> ;hb=HEAD
>> c
Joe Prostko wrote:
>
> Is there any chance those two files can be updated?
>
> They are available at the following links:
>
> config.guess:
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
;hb=HEAD
> config.sub:
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_pl
Thus said Donny Ward on Mon, 07 Jul 2014 12:56:03 -0700:
> His reponse in that link:
>
> > The pull and sync are requesting and receiving all SHUN records.
I'm not sure that this is what is happening in this case. The
--httptrace output only showed 3 gimme cards requested and none of
On Sat, Jun 21, 2014 at 9:11 PM, Joe Prostko wrote:
> I was just trying to build Fossil on the x86-64 version of Haiku, and
> it didn't get far since the platform failed to be identified. I
> replaced the versions of config.guess and config.sub shipped with
> Fossil and then configure worked, as
Good catch: you're correct.
-bch
On 7/7/14, Stephan Beal wrote:
> On Mon, Jul 7, 2014 at 10:10 PM, B Harder wrote:
>
>> Fossil insures that no remote user will ever be able to remove
>>
>
> Shouldn't that be "ensures"? i always confuse the two.
>
> --
> - stephan beal
> http://wanderinghors
On Mon, Jul 7, 2014 at 10:10 PM, B Harder wrote:
> Fossil insures that no remote user will ever be able to remove
>
Shouldn't that be "ensures"? i always confuse the two.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny'
That looks to be the end of this mystery. For those wondering why do
we request the same shun artifacts over and over and over and...:
==
The fact that the shunning list does not propagate is a security
feature. If the shunning list propagated then a malicious user (or a
bug in the fossil code
Richard Hipp wrote about this before:
https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg11761.html
His reponse in that link:
> The pull and sync are requesting and receiving all SHUN >records. You can
>disable this using
>
> "fossil setting auto-shun off"
On Sun, Jul 6
9 matches
Mail list logo
