Hi Folks,

On Tue, Jan 21, 2014 at 4:18 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 21 January 2014 00:58, David T. Lewis <lewis at mail.msen.com> wrote:
> > On Mon, Jan 20, 2014 at 05:32:51PM -0700, Jeff Gonis wrote:
> >> Hi Folks,
> >
> > Hi Jeff,
> >
> > Thanks for looking into this, I think it is important to maintain this
> > server and keep it producing meaningful tests.
> >
> >>
> >> I was taking a look at the build.squeak.org server and it seemed like
> there
> >> was a lot more red than green and I thought that I should at least start
> >> contributing to trying to fix that. I added a project a while back to
> show
> >> performance data from the image and it seemed to putting out some decent
> >> data, at least from a trendline perspective, for the last little while.
> >> Squeak was getting quite a bit faster from about the ~200 run of the
> >> project to #380 before it popped back up.  I'll investigate the change
> in
> >> speed and see if I can figure out the regression.
> >>
> >> In the meantime however, the console output is showing that the actual
> >> tests ran fine, but the "bundle install" command is failing because we
> >> apparently don't have the appropriate ruby gem installed to run this
> >> command.  Is this something I can fix via the Hudson web console or
> would I
> >> need access to the build server to do so? Does anyone with more ruby
> >> experience have a suggestion for this?
>
> It doesn't fail, it just warns about libyaml. And since we don't use
> any YAML stuff, I didn't bother "fixing" the problem. But I'm very
> happy that someone other than me actually reads the console output!
> Thanks!
>
> (The relevant warning is this:
>
> + bundle install
> /var/lib/jenkins/.rvm/rubies/ruby-1.9.3-p392/lib/ruby/1.9.1/yaml.rb:56:in
> `<top (required)>':
> It seems your ruby installation is missing psych (for YAML output).
> To eliminate this warning, please install libyaml and reinstall your ruby.
> )
>
> Oh. No, you're talking about SqueakTrunkPerformance. I missed that, in
> the sea of red :( That was just because the build wasn't configured to
> use rvm. Fixed, and apologies for not fixing sooner.
>
>
Thank you for looking into this Frank.  I will attempt to be more proactive
about this job in the future and also get up to date on the latest
configuration of the build server so that in the future I can take care of
these issues myself.  In the meantime your fix is greatly appreciated.


> >> Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing
> on
> >> the basis of being unable to use Git to checkout Frank's squeakci
> >> repository. I am not sure if that can be remedied by updating the
> installed
> >> software on the FreeBSD build slaves.
>
> See below.
>
> > The CogVM build job is maintained by me (independently of the actual Cog
> > VM development). Is intended to verify code generation only, and the
> errors
> > that you see there reflect an actual error in the code generation.
> Possibly
> > the current error condition reflects some method that needs to be
> checked in
> > to VMMaker for oscog. This is useful information, and the error messages
> in
> > the workspace are real, so this is a good thing.
> >
> > The FreeBSD Interpreter job has never worked. It is apparently owned by
> > nobody, and it seems to serve no useful purpose. I recall that it used to
> > be failing due to an improperly configured slave server (a FreeBSD
> machine
> > with duplicate and conflicting installations of UUID libraries I think)
> > but now it fails for no reason that I can understand. If anyone feels any
> > ownership for or interest in this job please speak up, otherwise I would
> > be happy to have the job disabled.
>
> All the FreeBSD jobs are owned by me :) They _do_ serve a useful
> purpose, which is to say "it doesn't work on FreeBSD". The machine on
> which those jobs run is being retired by its owner (I was but a
> guest), so until I find a new FreeBSD node (volunteers welcome! No,
> really!), I'll disable the jobs. I've already marked the sole node
> (havnor) as offline.
>
> >> Finally I wanted to ask about build machine coverage.  Do we still need
> a
> >> mac osx build machine to use remotely with Hudson and what about a
> windows
> >> machine?  I have recently come into some machines and I was wondering if
> >> donating time on those two operating systems would be worthwhile? They
> are
> >> respectively running the latest version of OSX and Windows 8.1. I am
> >> assuming that our linux coverage is good.
>
> I would love a Windows machine. LOVE. The current mac osx node (norst)
> runs, er, Snow Leopard, I think. It would be very useful to have a
> latest-and-greatest OSX because I don't plan on upgrading from Snow
> Leopard.
>
> The mac machine is a stand alone machine and as long as apple lets me keep
it up to date I will.  For the windows machine I was thinking I would get
it setup inside of a VM because I remember you mentioning something about
having to give Hudson the ability to run remote jobs and that really this
could allow it to pwn the machine if it were ever malicious. I figured a vm
I just keep up and running would help mitigate some of this risk. Does this
ring any alarm bells for you?

If not, then I don't see any reason why I could not work to also get a
FreeBSD vm up and running as well and then use that as the new machine.

If I don't hear any warnings of dire consequences I will go about
sanitizing the mac machine and getting  the windows VM set up this weekend.
I'll get to the FreeBSD machine later but I think promising all 3 for the
weekend would be overly optimistic.


> > I would think that test coverage for the Squeak unit tests on Windows and
> > Mac OS X is very important indeed, and it would be great if you are able
> > to provide that.
>
> Test coverage is... _inadequate_, I think would be the polite way of
> putting it, both in the sense of our code having very low coverage,
> and in the sense of the tooling. TestCoverage tells you nothing more
> than that a method was run: there's no indication, for instance, that
> anything _inside_ that method ran. Also, you can't run coverage over
> anything in Kernel or a bunch of other places, because we always
> perform self-brain-surgery.
>
> frank
>
> > Thanks,
> > Dave
> >
> >
> >>
> >> Thanks for your help and time,
> >> Jeff
>
>
Thanks again for all of your feedback and hard work,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140121/075ceca4/attachment.htm