ScienceTools: (Jim) There is a bug affecting Mac; see JIRA STGEN-100 for details. Jim can't look into it himself without access to the platform. (Heather) bldmac01 at SLAC might serve. [update from Jim: I tried the test script that Jeremy Perkins provided on bldmac01, using both Debug and Optimized builds, and the script worked fine; i.e., the failure mode may be restricted to FSSC builds for the Mac platform]
FSSC: (Eric) is also working on Mac bugs, not necessarily related to the above.
(Richard) heard something about new IRFs. (Anders) That is a C & A issue. See details in the report for May 31
Pisa Pass8 Workshop: (Tracy) See the agenda for links to the individual presentations and also to Luca's per-day discussion notes. The timeline is aggressive, but fortunately several qualified people have stepped up to help. Among critical pieces to be completed early on (by Collaboration Meeting) are the following:
Gaudi upgrade: (Heather) GlastSvc is done. Next on the list, and nearly complete, is dealing with the disappearance of the ITime interface in favor of a new concrete class to represent time. This affects calibration data classes and services in CalibSvc. Finally, HepRepSvc will need some refurbishing, but it is expected to be similar to work already done on GlastSvc, hence should go quickly.
(Tracy) There has been a request for the Gaudi python module. (Heather) will consider it, but not before the initial release of GR with the new Gaudi.
CLHEP upgrade: The chief difference, as far as anyone can recall, is use of namespaces. (Jim) would like an installation of the new version for one of the supported platforms on SLAC Linux so he can try it with ScienceTools. (Heather) will do.
Snow Leopard: (Heather) Kim is working through building externals. No roadblocks encountered to date.
u09: (Heather) It's still close to full. There are some CHS builds which can be deleted; that will help a little.
ROOT 5.26 and L1 (Heather) wonders whether we could move L1proc to ROOT v5.26 now that monitoring apps are happy. (Warren) Still testing.
SCons topics (Joanne) has brought SCons workbook pages further up to date. The very latest versions will not be available from the Workbook until Chuck returns; until that time use these links: Introduction, Building with Scons, SCons for Developers. Each of the pages contains links to the other two. The Intro page is essentially the same as the Workbook version. "Building with SCons" has some additional information but is otherwise the same as the corresponding Workbook page. The Developer page is radically different; avoid the Workbook version for now.
(Joanne) met with Nicola last week to learn more about the rootcint problem he had encountered: his package contains include files which reference CLHEP and possibly other externals, but the external include directories do not appear in the rootcint command. She can now reproduce the problem and has some ideas on how to fix it. When Nicola issues the rootcint command by hand, adding the extra include paths, the build completes successfully and produces a library which can be loaded from ROOT.
It turns out the other apparent problem last week — inability to load the rootIrfLoader library from ROOT — is not a problem after all. (Jim) there was a bug in the SConscript file which Joanne had fixed a while back, but the fixed version of the package has not yet made it into a tagged ST release. It works correctly for sufficiently recent LATEST builds.
(Tom) The crash in opt builds on rhel5 turned out to be due to uninitialized variables. When they were copied in a constructor, being NANs, they caused a floating point exception. Fix, to be made preferably by the package owner (astro), is still pending.
(Tom) continues to investigate creating distributions as part of Windows builds, as is already the case for Linux. It's not working and he doesn't know why.
(Tom) has fixed the bug he found in the code which was trying to send email notifications of build failures. The list of parties to be notified comes from package owners in the SConscript file. Be consistent about how you identify yourself there to avoid duplicate emails about the same build. Notifications are currently going out for rhel4 32-bit builds only. For what other build types should they be sent? He suggests at a minimum 64-bit, one Mac type and one Windows type. (Heather) We have seen failures afflicting practically any build type while others build successfully. However, sending messages individually for absolutely every build type could lead to unacceptable rates.
Beamtest: (Heather) It will be needed for Pass8, so will have to be SConsified. That could involve patching a lot of old packages. (Tracy) We want to upgrade it to GR v18. (Joanne) In that case it's probably just a matter of writing SConscripts and so forth for the 5 or so extra packages which are in Beamtest but not in GR.
previous | minutes index | next |