[regression] Are tests not running?
Hi, Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?
AMDG On 11/30/2016 03:49 AM, Andrey Semashev wrote:
Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?
The last report build was Saturday. http://www.boost.org/development/tests/develop/developer/index.html In Christ, Steven Watanabe
On 11/30/16 19:06, Steven Watanabe wrote:
AMDG
On 11/30/2016 03:49 AM, Andrey Semashev wrote:
Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?
The last report build was Saturday. http://www.boost.org/development/tests/develop/developer/index.html
Yes, but why are there no builds since Saturday? Have testers not cycled since then, not even one of them?
Rene, Looks like we’ve run out of disk space. develop.zip.kbelco.uploading rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) rsync: write failed on "/home/grafik/www.boost.org/testing/incoming/develop.zip.kbelco.uploading": No space left on device (28) rsync error: error in file IO (code 11) at receiver.c(301) [receiver=3.0.6] rsync: connection unexpectedly closed (639956 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6] Perhaps wipe everything in develop and master and then let the normal test cycling repopulate the results? — Noel
On Nov 30, 2016, at 9:06 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 11/30/2016 03:49 AM, Andrey Semashev wrote:
Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?
The last report build was Saturday. http://www.boost.org/development/tests/develop/developer/index.html
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Nov 30, 2016 at 12:09 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
Rene,
Looks like we’ve run out of disk space.
develop.zip.kbelco.uploading rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) rsync: write failed on "/home/grafik/www.boost.org/ testing/incoming/develop.zip.kbelco.uploading": No space left on device (28) rsync error: error in file IO (code 11) at receiver.c(301) [receiver=3.0.6] rsync: connection unexpectedly closed (639956 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
Perhaps wipe everything in develop and master and then let the normal test cycling repopulate the results?
I'll investigate tonight. Although I doubt the results are the ones taking up much room. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Wed, Nov 30, 2016 at 12:13 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Wed, Nov 30, 2016 at 12:09 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
Rene,
Looks like we’ve run out of disk space.
develop.zip.kbelco.uploading rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) rsync: write failed on "/home/grafik/www.boost.org/te sting/incoming/develop.zip.kbelco.uploading": No space left on device (28) rsync error: error in file IO (code 11) at receiver.c(301) [receiver=3.0.6] rsync: connection unexpectedly closed (639956 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
Perhaps wipe everything in develop and master and then let the normal test cycling repopulate the results?
I'll investigate tonight. Although I doubt the results are the ones taking up much room.
OK. Some cleanup of really old files. And removed the incoming results so that they get redone on the next uploads. For curiosity.. And so that people get an idea of resources.. The results for develop+master take up 14G *compressed*. And that doesn't count the intermediate upload ZIPs which would be another 28G. The drive now has 39G free, so hopefully it's OK for some time. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 12/01/16 06:05, Rene Rivera wrote:
OK. Some cleanup of really old files. And removed the incoming results so that they get redone on the next uploads.
Thanks.
For curiosity.. And so that people get an idea of resources.. The results for develop+master take up 14G *compressed*. And that doesn't count the intermediate upload ZIPs which would be another 28G. The drive now has 39G free, so hopefully it's OK for some time.
Maybe something stronger than zip could be used.
AMDG On 12/01/2016 01:38 AM, Andrey Semashev wrote:
On 12/01/16 06:05, Rene Rivera wrote:
OK. Some cleanup of really old files. And removed the incoming results so that they get redone on the next uploads.
Thanks.
For curiosity.. And so that people get an idea of resources.. The results for develop+master take up 14G *compressed*. And that doesn't count the intermediate upload ZIPs which would be another 28G. The drive now has 39G free, so hopefully it's OK for some time.
Maybe something stronger than zip could be used.
That would be a poor choice, since the main cause of zip's inefficiency is that it compresses files individually, which is something that we absolutely do need. In Christ, Steven Watanabe
AMDG On 11/30/2016 08:05 PM, Rene Rivera wrote:
OK. Some cleanup of really old files. And removed the incoming results so that they get redone on the next uploads. For curiosity.. And so that people get an idea of resources.. The results for develop+master take up 14G *compressed*.
If you're measuring the size of the zip file, it isn't compressed. (unless someone changed the implementation.) The reason for this is that I found that rsync handles the uncompressed zip much better. (zip compresses files individually and there are a lot of very similar small files). At the time, the archive was less than 1 GB, so I prioritized network usage over disk space. To change this you should be able to replace the nocompression_sink with deflate_sink in html_writer.
And that doesn't count the intermediate upload ZIPs which would be another 28G. The drive now has 39G free, so hopefully it's OK for some time.
In Christ, Steven Watanabe
On Thu, Dec 1, 2016 at 8:03 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 11/30/2016 08:05 PM, Rene Rivera wrote:
OK. Some cleanup of really old files. And removed the incoming results
so
that they get redone on the next uploads. For curiosity.. And so that people get an idea of resources.. The results for develop+master take up 14G *compressed*.
If you're measuring the size of the zip file, it isn't compressed. (unless someone changed the implementation.) The reason for this is that I found that rsync handles the uncompressed zip much better. (zip compresses files individually and there are a lot of very similar small files).
Re rsync.. Really? When I first implemented this it seemed rsync did fine with the compressed files. It correctly sent small chunks over on the spots that changed only. Now the chunks contained more than just the small file segments.. But it seemed that it was still sending over a small overall change. What I do remember is that using uncompressed made the server use less CPU. At one point it became a problem though. As the server was bogged down other operations the server was doing. So I can understand wanting to reduce that. At the time, the archive was less than 1 GB, so
I prioritized network usage over disk space. To change this you should be able to replace the nocompression_sink with deflate_sink in html_writer.
Perhaps we can use minimal compression, so that decompression is still low CPU, but we still see some disk space savings? After all it's all text which compressed well even at low compression levels. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
AMDG On 12/01/2016 08:17 AM, Rene Rivera wrote:
Re rsync.. Really? When I first implemented this it seemed rsync did fine with the compressed files. It correctly sent small chunks over on the spots that changed only. Now the chunks contained more than just the small file segments.. But it seemed that it was still sending over a small overall change.
rsync did work with the compressed files. It just worked better with uncompressed. My guess was that the main reason for the improvement is that rsync's own compression is ineffective on files that have already been compressed. Since disk space is becoming an issue, turning on compression should be fine. In Christ, Steven Watanabe
On 11/30/16 13:49, Andrey Semashev wrote:
Hi,
Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?
Is there a problem with the tests again? The report has not been updated since Wed Jan 25.
On Sun, Jan 29, 2017 at 9:08 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 11/30/16 13:49, Andrey Semashev wrote:
Hi,
Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?
Is there a problem with the tests again? The report has not been updated since Wed Jan 25.
It's likely we are running out of disk space again :-( Can't do anything immediate about it now though as there isn't anything else to delete on the boost account. Problem should be resolved when we move to new server though. Which should be some time this coming week. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 29 January 2017 at 16:53, Rene Rivera <grafikrobot@gmail.com> wrote:
It's likely we are running out of disk space again :-( Can't do anything immediate about it now though as there isn't anything else to delete on the boost account.
About a week ago, I freed up some space on the server by deleting old beta documentation and replacing duplicate files with hardlinks, so there should be more space.
Problem should be resolved when we move to new server though. Which should be some time this coming week.
Is the website and my cron stuff moving as well?
On Sun, Jan 29, 2017 at 11:17 AM, Daniel James <dnljms@gmail.com> wrote:
On 29 January 2017 at 16:53, Rene Rivera <grafikrobot@gmail.com> wrote:
It's likely we are running out of disk space again :-( Can't do anything immediate about it now though as there isn't anything else to delete on
the
boost account.
About a week ago, I freed up some space on the server by deleting old beta documentation and replacing duplicate files with hardlinks, so there should be more space.
Problem should be resolved when we move to new server though. Which should be some time this coming week.
Is the website and my cron stuff moving as well?
Web site and email are moving. I don't know about cron stuff. You'll need to tell Michael Caisse about it. So that they take it into account. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 1/29/17 09:35, Rene Rivera wrote:
On Sun, Jan 29, 2017 at 11:17 AM, Daniel James <dnljms@gmail.com> wrote:
On 29 January 2017 at 16:53, Rene Rivera <grafikrobot@gmail.com> wrote:
It's likely we are running out of disk space again :-( Can't do anything immediate about it now though as there isn't anything else to delete on
the
boost account.
About a week ago, I freed up some space on the server by deleting old beta documentation and replacing duplicate files with hardlinks, so there should be more space.
Problem should be resolved when we move to new server though. Which should be some time this coming week.
Is the website and my cron stuff moving as well?
Web site and email are moving. I don't know about cron stuff. You'll need to tell Michael Caisse about it. So that they take it into account.
Hi Daniel - I suspect your "cron stuff" has moved also. I'll email you directly so that you are in the loop. Take care - michael -- Michael Caisse Ciere Consulting ciere.com
On Sun, Jan 29, 2017 at 11:17 AM, Daniel James <dnljms@gmail.com> wrote:
On 29 January 2017 at 16:53, Rene Rivera <grafikrobot@gmail.com> wrote:
It's likely we are running out of disk space again :-( Can't do anything immediate about it now though as there isn't anything else to delete on
the
boost account.
About a week ago, I freed up some space on the server by deleting old beta documentation and replacing duplicate files with hardlinks, so there should be more space.
Hmm.. Yeah, just looked and there is 17G left in the drive and the test uploads look like they are under 7G. I guess the problem is something else :-( -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
participants (6)
-
Andrey Semashev -
Belcourt, Kenneth -
Daniel James -
Michael Caisse -
Rene Rivera -
Steven Watanabe