[M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines

Wed Aug 11 18:10:24 CEST 2010

Olaf I think we should do a bit more research here, but I also think we have a few easy options.

 - build our own cvs, put it in $HOME/bin. 
 - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin 
 - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how 
   we convince Hudson that our java -version is ok. 

 - Jay

> Date: Wed, 11 Aug 2010 09:26:35 +0200
> From: wagner at elegosoft.com
> To: dabenavidesd at yahoo.es
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Short status of CM3 Hudson regression testing	on	opencsw.org machines
> 
> Quoting "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>:
> 
> > Hi all:
> > I was rethinking but it seems you caught a bug either inside   
> > opencsw.org or elego system (incompatible versions).
> 
> There are no incompatible CVS versions. Birch is running 1.12.13,
> and current9s.opencsw.org is running both that and 1.11.23. Should
> all work fine theoretically.
> 
> It may be a problem with the proxy we need to use to get out from
> opencsw.org, too.
> 
> Olaf
> 
> PS: I don't think cool user space file systems from Linux will help
> us on Solaris systems, nor will opencsw.org change their general
> setup and policies for us.
> 
> > Probably will be a lot easier with some special techniques like this ones
> > I assume you're not able to do that but just in case you do sshfs:
> > http://www.linux-mag.com/id/7820
> > How critical is this process for it? see suggestions for it see   
> > pages 34 and 42 about centralizing control over files in contrast of  
> >  distributed and the efficiency in I/O transmission and suggestions   
> > for improving it in a white "paper" book of "The Shortcut guide to   
> > Eliminating Insecure
> > and Unreliable File Transfer Methods" if that might help (again just  
> >  accept the security domain error and add the security exception)
> > https://168.176.86.16/~danielb/SGEIU-complete.pdf
> > downloaded from
> > http://nexus.realtimepublishers.com/sgeiu.php
> > you will need an account and take a survey on the topic if you might
> > In such a case where you are allowed sshfs might be an interesting   
> > option it requires user space file system but if the performance is   
> > not critical perhaps we can think about it, can we, might be   
> > interesting for a windows setting, etc?
> >
> > Thanks in advance, hope it helps
> >
> > --- El mar, 10/8/10, Olaf Wagner <wagner at elegosoft.com> escribió:
> >
> >> De: Olaf Wagner <wagner at elegosoft.com>
> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing  
> >>  on opencsw.org machines
> >> Para: m3devel at elegosoft.com
> >> Fecha: martes, 10 de agosto, 2010 08:33
> >> Quoting Olaf Wagner <wagner at elegosoft.com>:
> >>
> >> > Quoting Dagobert Michelsen <dam at opencsw.org>:
> >> >
> >> >> Hi Olaf,
> >> >>
> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner:
> >> >>> Quoting Dagobert Michelsen <dam at opencsw.org>:
> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf
> >> Wagner:
> >> >>>>> Currently I know of two other problems
> >> running our builds and tests
> >> >>>>> on the opencsw machines.
> >> >>>>>
> >> >>>>> 1. cvs update does not work on
> >> current10x (Solaris on x86) when run from
> >> >>>>> Hudson.
> >> >>>>> It does work on current10s and
> >> current9s.
> >> >>>>
> >> >>>> Interesting. current*s are all running on
> >> the same physical
> >> >>>> machine as zones,
> >> >>>> whereas current*x are located on a vSphere
> >> farm. Do you have a specific
> >> >>>> command sequence which I can try to
> >> reproduce the problem?
> >> >>>
> >> >>> I'm not yet able to reproduce it manually; I
> >> only see it in the
> >> >>> Hudson jobs (failing right away when computing
> >> the changelog).
> >> >>>
> >> >>> If you want, I can setup a job for test
> >> purposes and you can get
> >> >>> Hudson access.
> >> >>
> >> >> I can't promise I can fix this but if you set
> >> something up I may look
> >> >> in the next few days.
> >> >
> >> > I finally managed to reproduce the problem in the
> >> build step of
> >> > a Hudson job, and got this after enabling tracing:
> >> >
> >> >  -> rename(CVS/Entries.Backup,CVS/Entries)
> >> >  -> unlink_file(CVS/Entries.Log)
> >> > cvs update: inflate: unknown compression method
> >> > cvs [update aborted]: reading from server: I/O error
> >> >  -> Lock_Cleanup()
> >> > Finished: FAILURE
> >> >
> >> > Is there a different/an older gzip library on
> >> current10x?
> >> >
> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console
> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console
> >> >
> >> >>>> Are you using cvs stable (1.11.23) or
> >> feature (1.12.13)?
> >> >>>
> >> >>> Stable. I'll try with 1.12.13, too (haven't
> >> seen that around).
> >> >>> Is it installed anywhere??
> >> >>
> >> >> That is here:
> >> >> /opt/csw/cvs-feature/bin/cvs
> >>
> >> 1.12.13 says
> >>
> >> cvs update: inflate: invalid distance too far back cvs
> >> [update
> >> aborted]: reading from server: I/O error
> >> Finished: FAILURE
> >>
> >> Any ideas?
> >>
> >> Olaf
> >> --
> >> Olaf Wagner -- elego Software Solutions GmbH
> >>
> >> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> >> phone: +49 30 23 45 86 96  mobile: +49 177 2345
> >> 869  fax: +49 30 23 45 86 95
> >>     http://www.elegosoft.com |
> >> Geschäftsführer: Olaf Wagner | Sitz: Berlin
> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> >> USt-IdNr: DE163214194
> >>
> >>
> >
> >
> >
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100811/3584d8c0/attachment-0002.html>