On 21 January 2014 15:23, Jeff Gonis <jeff.gonis at gmail.com> wrote:
> 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?

I think it's a very good idea to run the build slave as a VM for a
couple of reasons:
* Windows 8.1 ships with Hyper-V, so it's easy (he says not having tried it...)
* If the VM is owned you can kill it without worrying about the host machine
* Being in a VM makes it easier to keep the Jenkins stuff separate
from your host machine

> 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 you're up for it, I'd love to hear if you can get a FreeBSD VM
running in Hyper-V. You certainly can in VirtualBox.

> 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.

Great to hear! Thanks!

frank

>> > 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