> "BP" == Bob Proulx writes:
BP> Using gzip is much less stressful on the cpu. It only takes 1m30s to
BP> create and download a tar.gz file. The gz is a larger file than the
BP> xz but the overall impact of the gz is less.
Yes. It is possible something like varnish in
> > I sync'd the file attachments from the old to the new. [...]
> > frontend:/var/lib/savane/trackers_attachments# rsync -av
> > /var/lib/savane/trackers_attachments/
> > frontend0:/var/lib/savane/trackers_attachments/
> If it helps,
> I have a script to do this (and also copy the "new
> On Feb 8, 2017, at 15:59, Bob Proulx wrote:
> I sync'd the file attachments from the old to the new. [...]
> frontend:/var/lib/savane/trackers_attachments# rsync -av
> On Feb 8, 2017, at 23:32, Bob Proulx wrote:
>> If the files are truncated, they are truncated by just a tiny little bit.
> we have a recent report of the same problem for the cgit interface.
> [...]However note that at that time git and cgit were on vcs not vcs0.
> On Feb 9, 2017, at 00:39, Bob Proulx wrote:
> Do you know how hook scripts with bzr work? Perhaps you can help me
> help you.
Not sure if that's helpful, but last month I installed a missing 'email'
carl hansen wrote:
> still still not working
Sorry there has been delays. We have been overwhelmed trying to
juggle too many things.
I would love to help fix your hook problem. But I enter this knowing
nothing about bzr. I've never used bzr before. I poke into your bzr
Eli Zaretskii wrote:
> James Cloos wrote:
> > It looks like there is a 60 second limit.
Yes. There appeared to be a 60 second limit.
> > And the transmission is unnaturally slow. My test averaged only 154KB/s
> > even though I ran it on a machine in a very well connected data center
> > near
Assaf Gordon wrote:
> If the files are truncated, they are truncated by just a tiny little bit.
I don't know if this is somehow related or if it will be noise. But
we have a recent report of the same problem for the cgit interface.
> On Feb 8, 2017, at 22:31, Assaf Gordon wrote:
> Few more observations:
> These consistently fail (truncated file):
> On Feb 8, 2017, at 15:13, Bob Proulx wrote:
>> in the following Bug report someone tried to download a specific octave
>> revision from the hgweb interface, but got a corrupted file(files in the
>> archive were missing).
On Wed, Feb 8, 2017 at 2:15 PM, Bob Proulx wrote:
> Hi Jim, Paul,
> Jim Meyering wrote:
>> Savannah is undergoing some changes as it switches to new hardware, so
>> forwarding your message to savannah-hackers-public, where the guys
>> (Bob and Assaf) doing all the work hang
Hi Jim, Paul,
Jim Meyering wrote:
> Savannah is undergoing some changes as it switches to new hardware, so
> forwarding your message to savannah-hackers-public, where the guys
> (Bob and Assaf) doing all the work hang out.
Eventually we will either wack-a-mole all of these or we will have a
Bob Proulx wrote:
> Which means I want to say that all of the version control systems from
> vcs are migrated now. (Since tla arch is hosted on download.)
> Therefore I think I will set up an iptables block for other services
> in order to force finding any unknown issues.
Which I have done just
> in the following Bug report someone tried to download a specific octave
> revision from the hgweb interface, but got a corrupted file(files in the
> archive were missing).
> I tried it, too, with .gz and .bz2 and got both times an ~6MB file
Bob Proulx wrote:
> But the cgit web server was returning a proxy error. In order to
> avoid needing to debug that on the spot I proxied it over to the old
> server temporarily. That is running okay this way for the moment.
> Can debug the local native server at our leisure.
Thanks to Assaf for
Anyone know why "Chef Client" is repeatedly hitting this? (I know
that Chef is a Puppet like tool.)
I have been staring at the activity and for some reason I am seeing a
lot of "Chef Client" accessing two particular emacs cgit
Bob Proulx wrote:
> This isn't the final configuration though since this uses the package
> installed git, which should be fine but doesn't support shallow clones
> with --depth 1 yet as of the OS Trisquel 7 release with git 1.9.1.
> Therefore we are using git from a Debian Jessie Stable chroot
Mail list logo