Re: [ros-dev] Problem with dbgwin revisions from Windows builder

[Pierre Schweitzer]

Hi,

this is a mistake I did when switching server for ISOs upload, in order
to get more reliable server (previous one was often crashing during the
upload). I forgot to deploy rsync on the new upload server.
This is now fixed.

No need to blame Colin nor its upload method. I am all faulty here.

With my best regards,
Pierre

Le dimanche 02 septembre 2012 à 21:47 +0200, caemyr(a)myopera.com a
écrit :
>   Hiya
>  
>  R3ddr4g0n reported to me that all recent revisions uploaded to
>  iso.reactos.org are not correct. Instead of given revision, all the
>  builds are reporting to be rev 57150. After a quick check, i downloaded
>  bootcd-57221-dbgwin.iso and checked its SHA1: should be
>  56d2190610e8a1f650faa3c6a6a8348f89d1fa1b but happened to be:
>  f97ac4aba0e5ceed3b5beae3d7ab2bc2c7600fab - which is indeed the same
>  checksum as for x86_CMake-57150
>  
>  The possible clue from the upload script:
>  bash: rsync: command not found
>  rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>  rsync error: error in rsync protocol data stream (code 12) at
>  /home/lapo/package/rsync-3.0.8-1/src/rsync-3.0.8/io.c(601)
>  [sender=3.0.8]
>  * Done.
>  * Remotely compressing bootcd-57219-dbgwin...
>  
>  Now, Colin may recall that i was strongly against using fancy tricks for
>  sending the revs instead of simply archiving them locally and uploading
>  afterwards. This way with rsync was supposed to be saving bit of
>  bandwidth.
>  
>  Now we have to reupload at least all since 57150, unless you can use the
>  fancy tricks to spot the same iso files. Great thing we can save a
>  little bit of bandwidth but waste time to fix it afterwards. 
>  
>  Accoring to the reporter:
>  [21:45:37] <r3ddr4g0n> for sure from 57115 to 57221
>  
>  If you still think this methode is saving us anything, please reckon
>  that a single view of testbot log means downloading a few megabytes of
>  text at least.
>  
>  I`m stopping the uploads until the problem is resolved in a way to
>  prevent it from happening again.
>   
-- 
Pierre Schweitzer &lt;pierre(a)reactos.org&gt;
Systems Administrator
ReactOS Foundation