<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I propose this is the next thing to try:<br><br> - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how <br> we convince Hudson that our java -version is ok. <br><br><br>thereby removing -z3 from any jobs on this node, leaving all the rest unchanged.<br>I realize $HOME/bin might not be it, but like $HOME/$(uname -n)/bin or such.<br><br><br> - Jay<br><br><br><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: wagner@elegosoft.com; dabenavidesd@yahoo.es<br>Date: Wed, 11 Aug 2010 23:42:39 +0000<br>CC: m3devel@elegosoft.com; dam@baltic-online.de<br>Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
Hm, that this means by the way, I think, is the compressed data is<br>not recognized as valid. e.g. it isn't -z3 being rejected, but the data from the server.<br>Maybe the network is flaky and corrupting the data?<br><br>That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc.<br><br>ay@xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */*<br>zlib/inflate.c: strm->msg = (char *)"unknown compression method";<br>zlib/inflate.c: strm->msg = (char *)"unknown compression method";<br><br><br> if (BITS(4) != Z_DEFLATED) {<br> strm->msg = (char *)"unknown compression method";<br> state->mode = BAD;<br> break;<br> }<br>...<br>#ifdef GUNZIP<br> case FLAGS:<br> NEEDBITS(16);<br> state->flags = (int)(hold);<br> if ((state->flags & 0xff) != Z_DEFLATED) {<br> strm->msg = (char *)"unknown compression method";<br> state->mode = BAD;<br> break;<br> }<br> <br><br><br> - Jay<br><br><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: wagner@elegosoft.com; dabenavidesd@yahoo.es<br>Date: Wed, 11 Aug 2010 16:10:24 +0000<br>CC: m3devel@elegosoft.com; dam@baltic-online.de<br>Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines<br><br>
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
Olaf I think we should do a bit more research here, but I also think we have a few easy options.<br><br> - build our own cvs, put it in $HOME/bin. <br> - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin <br> - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how <br> we convince Hudson that our java -version is ok. <br><br> - Jay<br><br>> Date: Wed, 11 Aug 2010 09:26:35 +0200<br>> From: wagner@elegosoft.com<br>> To: dabenavidesd@yahoo.es<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines<br>> <br>> Quoting "Daniel Alejandro Benavides D." <dabenavidesd@yahoo.es>:<br>> <br>> > Hi all:<br>> > I was rethinking but it seems you caught a bug either inside <br>> > opencsw.org or elego system (incompatible versions).<br>> <br>> There are no incompatible CVS versions. Birch is running 1.12.13,<br>> and current9s.opencsw.org is running both that and 1.11.23. Should<br>> all work fine theoretically.<br>> <br>> It may be a problem with the proxy we need to use to get out from<br>> opencsw.org, too.<br>> <br>> Olaf<br>> <br>> PS: I don't think cool user space file systems from Linux will help<br>> us on Solaris systems, nor will opencsw.org change their general<br>> setup and policies for us.<br>> <br>> > Probably will be a lot easier with some special techniques like this ones<br>> > I assume you're not able to do that but just in case you do sshfs:<br>> > http://www.linux-mag.com/id/7820<br>> > How critical is this process for it? see suggestions for it see <br>> > pages 34 and 42 about centralizing control over files in contrast of <br>> > distributed and the efficiency in I/O transmission and suggestions <br>> > for improving it in a white "paper" book of "The Shortcut guide to <br>> > Eliminating Insecure<br>> > and Unreliable File Transfer Methods" if that might help (again just <br>> > accept the security domain error and add the security exception)<br>> > https://168.176.86.16/~danielb/SGEIU-complete.pdf<br>> > downloaded from<br>> > http://nexus.realtimepublishers.com/sgeiu.php<br>> > you will need an account and take a survey on the topic if you might<br>> > In such a case where you are allowed sshfs might be an interesting <br>> > option it requires user space file system but if the performance is <br>> > not critical perhaps we can think about it, can we, might be <br>> > interesting for a windows setting, etc?<br>> ><br>> > Thanks in advance, hope it helps<br>> ><br>> > --- El mar, 10/8/10, Olaf Wagner <wagner@elegosoft.com> escribió:<br>> ><br>> >> De: Olaf Wagner <wagner@elegosoft.com><br>> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing <br>> >> on opencsw.org machines<br>> >> Para: m3devel@elegosoft.com<br>> >> Fecha: martes, 10 de agosto, 2010 08:33<br>> >> Quoting Olaf Wagner <wagner@elegosoft.com>:<br>> >><br>> >> > Quoting Dagobert Michelsen <dam@opencsw.org>:<br>> >> ><br>> >> >> Hi Olaf,<br>> >> >><br>> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner:<br>> >> >>> Quoting Dagobert Michelsen <dam@opencsw.org>:<br>> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf<br>> >> Wagner:<br>> >> >>>>> Currently I know of two other problems<br>> >> running our builds and tests<br>> >> >>>>> on the opencsw machines.<br>> >> >>>>><br>> >> >>>>> 1. cvs update does not work on<br>> >> current10x (Solaris on x86) when run from<br>> >> >>>>> Hudson.<br>> >> >>>>> It does work on current10s and<br>> >> current9s.<br>> >> >>>><br>> >> >>>> Interesting. current*s are all running on<br>> >> the same physical<br>> >> >>>> machine as zones,<br>> >> >>>> whereas current*x are located on a vSphere<br>> >> farm. Do you have a specific<br>> >> >>>> command sequence which I can try to<br>> >> reproduce the problem?<br>> >> >>><br>> >> >>> I'm not yet able to reproduce it manually; I<br>> >> only see it in the<br>> >> >>> Hudson jobs (failing right away when computing<br>> >> the changelog).<br>> >> >>><br>> >> >>> If you want, I can setup a job for test<br>> >> purposes and you can get<br>> >> >>> Hudson access.<br>> >> >><br>> >> >> I can't promise I can fix this but if you set<br>> >> something up I may look<br>> >> >> in the next few days.<br>> >> ><br>> >> > I finally managed to reproduce the problem in the<br>> >> build step of<br>> >> > a Hudson job, and got this after enabling tracing:<br>> >> ><br>> >> > -> rename(CVS/Entries.Backup,CVS/Entries)<br>> >> > -> unlink_file(CVS/Entries.Log)<br>> >> > cvs update: inflate: unknown compression method<br>> >> > cvs [update aborted]: reading from server: I/O error<br>> >> > -> Lock_Cleanup()<br>> >> > Finished: FAILURE<br>> >> ><br>> >> > Is there a different/an older gzip library on<br>> >> current10x?<br>> >> ><br>> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console<br>> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console<br>> >> ><br>> >> >>>> Are you using cvs stable (1.11.23) or<br>> >> feature (1.12.13)?<br>> >> >>><br>> >> >>> Stable. I'll try with 1.12.13, too (haven't<br>> >> seen that around).<br>> >> >>> Is it installed anywhere??<br>> >> >><br>> >> >> That is here:<br>> >> >> /opt/csw/cvs-feature/bin/cvs<br>> >><br>> >> 1.12.13 says<br>> >><br>> >> cvs update: inflate: invalid distance too far back cvs<br>> >> [update<br>> >> aborted]: reading from server: I/O error<br>> >> Finished: FAILURE<br>> >><br>> >> Any ideas?<br>> >><br>> >> Olaf<br>> >> --<br>> >> Olaf Wagner -- elego Software Solutions GmbH<br>> >><br>> >> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345<br>> >> 869 fax: +49 30 23 45 86 95<br>> >> http://www.elegosoft.com |<br>> >> Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 |<br>> >> USt-IdNr: DE163214194<br>> >><br>> >><br>> ><br>> ><br>> ><br>> ><br>> <br>> <br>> <br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br> </body>
</html>