Steve> Just had a look at your smoketest log page... eww, lots of Steve> red. :-( True. Steve> I can't reproduce the 21.4 and 21.5 failures here OK. Steve> What version of GNU/make you are using to build the packages Steve> with? It looks to me like your make doesn't grok the $(value Steve> foo) that I put into the Mule-UCS Makefile. I'm using GNU Make version 3.79.1. Yours -- %% Mats

Steve> That should work. Fine. Steve> Now I'm waiting for it to update again. Mats, how often is it Steve> supposed to update, I can't see any sequence to it... [...] Steve> One run on the 4th, one on the 9th, two on the 10th, one on the Steve> 11th. I don't understand. The idea is that after a change in CVS you would see an updated web-page in an hour (or two ;-) But the data is really confusing (because I have had problems with the automatic build.) You are entitled to an explanation. Here goes: It works like this. Once an hour the build is started if there isn't a job going on already. The build starts with a check out from CVS. If there are no new files the build stops at that point. No need to build anything if there are no new files. After the build completes the web-page is generated from the log- and tail-files. So when there is nothing new in CVS the "updated" time on the web-page will be e few minutes past. When the packages are built the "updated" time will indicate how many minutes the complete build took. So by just looking at the web-page you can normally see if the smoketest is feeling good or not. Now this is when everything goes well. As you might remember I'm having problems with the cronjob hanging. This occurs sometimes when there are build errors. Not all errors cause the job to hang and not for all xemacsen. I haven't found a good way to avoid this so at times I must manually kill hanging xemacs-processes etc. I normally try though to run the build again, this time from a shell, to generate the "real" log. This always work and there is no hanging processes when running the smoketest this way. (Actually this gave me an idea of an alternative way of running the build that would avoid the cron-job-hanging thing.) I also run the build manually at times when I change the build scripts that could cause a new build even though there are no new files in CVS. Steve> Also, Mats, what is you local time in relation to GMT? GMT+1. Server is located in Stockholm. (As of this writing I'm having the first four builds OK so I'm looking forward now to seeing the first all-six-green-builds coming up in a few minutes.) Yours -- %% Mats

|--==> "ML" == Mats Lidell <matsl(a)contactor.se&gt; writes: ML> Well it is time for celebration. The first all-green-build was ML> just seen. Now lets keep it that way! It's just a pity that it is wrong. Your 21.5 and 21.4 Mule builds are not building Latin-Unity or Mule-UCS. :-( Could you do me a favour, Mats? Try building those two packages manually with 21.5 and 21.4 Mule and let me know what happens. Just do a 'make distclean' & 'make' in the Latin-Unity & Mule-UCS directories. If they don't build (you get a message saying the package isn't supported in XEmacs < 21.4), could you do the make again and this time use the '-d' option to make and send me the output. Thanks, Mats. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

Steve> Doesn't happen. Well my idea to use a script didn't cut it either. The build hung today again. Steve> Shouldn't that be "if there are no *changed* files"? oops! That is what I meant with "new" files. If files are updated during cvs update the build is started. (There are some files that are ignored because they are generated _and_ in CVS which causes cvs update to always think that they are updated.) Steve> Cool, thanks. Maybe you could state that in the "Last Updated" Steve> line on the web page, something line: OK. Yours -- %% Mats