D0 Release Manager Frequently Asked Questions

Below I have collected a number of questions frequently asked of the D0 release managers and the answers given by them. Most of these questions and answers are based on e-mails sent to the D0 Release Managers at D0 Release Manager <d0-release-mgr@fnal.gov>.

At the present time, the format is that of an unordered list.  Over time as categories become obvious, I will group the questions and answers.

Both the questions and answers are provided as verbatim as possible in order to minimize the work of preparing this list and keep the more subtle aspects of content.  I have, however, removed as much as possible the names and e-mail addresses of those asking the questions as well as those answering them so as to make it possible to include dumb questions and, for that matter, dumb answers -- albeit with a bit less anonymity.

David J. Ritchie
ritchie@fnal.gov

FAQ-001.0: No Rule To Make Target

Question: What is behind the "No Rule To Make Target" message?

Presumably this is a simple one... I was building Exe's just fine and the I mucked around w/ my LIBRARIES/OBJECTS files only to get the following ( I don't think I changed anything else ): 
gmake[3]: *** No rule to make target
`/prj_root/828/jetid_1/JoeUser/p1013/bin/IRIX6.5-KCC_4_0/l2gbl_analyze_x',
needed by `single_bin'.  Stop.
gmake[2]: *** [bin.bin] Error 2
gmake[1]: *** [l2gbl_analyze.bin] Error 2
gmake: *** [all] Error 2
Any ideas on how to gleam information from the above would be much appreciated.

Answer 1: Check for missing libraries.

I don't know about the l2gbl_analyze package but this looks to me as youre missing a library for your binary. Look into l2gbl_analyze/bin/LIBRARIES file, there is where the library should be listed.

Answer 2: Make a dummy .cpp file.

It looks like you are trying to make a binary called l2gbl_analyze_x but have not created the necessary dummy .cpp file. So, create a file in your bin directory called l2gbl_analyze_x.cpp which contains:

// there is nothing in this file

...or whatever... and you should be ok (now your BINARIES file has a real "something" to point to).

FAQ-002.0: Installing A Release On A Remote Machine

Question: Can you help me with the messages I get on trying to install the release on a remote machine?

I'm installing ups/upd/perl.

In executing the following command yesterday (Jan 10, 2002):

*************************************************
upd install -h www-d0.fnal.gov D0RunII-bin p10.12.00 -q Linux2-KCC_4_0 -f Linux+2.2
***********************************************

it ended after installing many files with the following message:

****************************************************
gunzip: stdin: unexpected end of file
error: ftp transfer failed: rel-p10.12.00-NULL.tar.gz: No such file or directory.

error: can't transfer /d0dist/dist/tarfiles/rel-p10.12.00-NULL
         from www-d0.fnal.gov to
        /d0dist/dist/releases/p10.12.00
upd install failed.
*****************************************************

Any help you provide in resolving this error will be greatly appreciated.

Answer:  The release you are trying to download has been deleted.

First, you say you are installing ups/upd/perl.  Actually, you're installing D0RunII, ie the D0 code development system. You must have already installed ups/upd/perl (which is the base piece of the entire system) before you could have gotten to the point where you got this error.

Now for the error itself.

Good timing! We don't have infinite disk space, so we remove releases & tar files that have been superceded by newer versions.

In this case, you hit a window between the removal of the tar file and the release itself. p10.12.00 was superceded by p10.13.00 some weeks ago--just before Christmas.

Please install the latter. If for some (unknown) reason you *must* have p10.12.00, let me know.
I can restore the tar files, but I *really* don't want to.
 

Follow up #1: I'll load a more recent version.

Ok, I'll attempt to load p10.13.00.  Do I need to delete the directories/files created from p10.12.00 or are they updated automatically when p10.13.00 is loaded?

Response concerning previously loaded directories and files.

The large number of installs done first are all the packages. They are all still there. Most, however are being used in p10.13.00. So do *not* delete them all.

After you have p10.13.00 installed, then do:

  setup D0RunII p10.13.00
  cleanPkgVer.sh

The latter will look through all the package/versions installed and check if it is used. If/when it finds one that's no longer used, it'll ask if you want to remove it. Answering "y" will remove it. You might want to try it as typed above once (answering "y" a *lot* of times).

Eventually you'll probably want to do the equivalent of "yes | cut -c1 | cleanPkgVer.sh" if your system supports the "yes" command. This will automatically answer "y" for you.

This is all explained plus how to get rid of the binary pieces as well at:

http://www-d0.fnal.gov/software/cmgt/del-old-ver.html

linked from the D0 Code Management page.

Follow Up #2:

Ok, thanks for the help.  I deleted the created files before receiving your help email.  However, this will help us in the future. I'm presently loading p10.13.00.

FAQ-002.1: Difficulties Installing D0RunII on Linux

Question: What do these messages about Geant mean?

I have installed the package cern 200 with:
upd install cern 2000 -f Linux+2
It is the cernlib package as far as I can check.

Now, I tried to install GEANT and I got the response:

upd install geant v3_21_13 -f Linux+2
informational: cernsource 2000 already exists on local node, skipping.
Unknown statement type at line 24 in updconfig
Unknown statement type at line 25 in updconfig
error: product cern directory /d0/fermi/products/cern/2000
already exists -- will not overwrite
But GEANT is not in the cern 2000 subdirectory.

Another thing: root has only flavor Linux+2.2 and my upd flavor says I have Linux+2.4. The installation succeeded but I got a warning message. Am I not going to have problems once I use root?

Answer: Geant isn't in CERN any longer

Geant isn't in cern any longer. Cern changed that a long time ago. It's in it's own package. You'd see it at <base-of-products-area>/geant/... if the download succeeded. But I don't believe that it succeeded.

In your download, the "informational:" message is normal. The two "Unknown statment" errors aren't fatal. They are just annoying.

The "error:" however, *is* a problem. It says that upd thought that you needed to redownload cern 2000 (from what it reads in the ups database), but the subdirectory it would put it into already exists, so it won't overwrite. At this point, I believe that the download would fail, but maybe not.

Please do the following and send me the results:

ups list -aK+:db:prod_dir cern
ups list -aK+:db:prod_dir geant
cat <base-of-products-db-area>/.updfiles/updconfig
and send me the results.

I'm guessing that you don't have enough levels in your products directory trees and that cern 2000's flavor and the flavor of cern 2000 asked for by geant don't match. Normally there'd be a subdirectory containing the flavor so the two would install into different directories in which case you'd have no problem. But without the flavor subdirectory they'd try to go into the same place, which upd won't do.

What versions of ups and upd do you have? I'd suggest making sure you have the latest of both.

The older versions of ups/upd would have done flavor matching by looking in:

Linux+2.4<something>:Linux+2.4:Linux+2:Linux:NULL

which is apparently what your system still believes.

The newer versions, between the Linux+2.4 and Linux+2 tries will also try:

Linux+2.3:Linux+2.2:Linux+2.1:Linux+2.0

They do this because *most* of the time a Linux+2.2 exe, and libraries etc will work just fine on a Linux+2.4 machine. Thus "geant -f Linux+2.4" (if it existed) could happily work with "cern -f Linux+2.2" and downloading geant ..2.4 above could also download the cern ..2.2 and be OK.

In those cases where this is *not* true, the maintainers will need to supply both 2.2 and 2.4 versions. Then
the appropriate one will be downloaded.

In your case, you downloaded cern -f Linux+2. OK, fine. Then you downloaded geant -f Linux+2. Fine, one would think. HOWEVER. geant depends on cern and there are *both* Linux+2 and Linux+2.2 versions of it. Since geant -f Linux+2 doesn't specify the precise flavor of cern to download, it'll download the Linux+2.2 one since it's earlier in the search list.

A quick fix would be to "ups undeclare -y cern 2000 -f Linux+2", then redownload geant. I wouldn't put any flavor spec on the download. Most of the time it's not needed and can get you into trouble as it did here. You'd then get cern -f Linux+2.2 and geant -f Linux+2.2. Both will work fine on a 2.4 machine.

However: you really need to modify your updconfig file so that *both* the flavor and qualifiers as well as the version are included in the directory name.You might not think that either are needed, but believe me there are cases where *both* are necessary. See http://www-d0.fnal.gov/d0dist/usr/products/upsdb/.updfiles/updconfig for the one we use here.

The explanation above also addresses your other question. If you have a recent version of ups, a Linux+2.4 machine will find a Linux+2.2 product. Assuming that there is no Linux+2.4 version in fnkits, one can then assume that this will work happily.

NOTE: don't use our machines as examples of which of these one should have. A lot of our products predate the change in ups. So we have some products that are "double declared". That is the *same* real version of a 2.2 product is declaredas 2.4 as well.

Look in fnkits instead.

FAQ-003.0: Executable In Test Phase Crashes

Question:  Why does my executable crash in the test phase on every build after the first?

I looked at the cause for this crash. It's due to the fact that the executable tries to write to an already existing root-tuple file.

This is peculiar, as that can happen *only* if that root-tuple file was created in an earlier attempt to run the integrated test (which must then have been successful to the extent that it managed to open this root-tuple file).

I thought that upon a rebuild, the tmp/.../itest directory was thrown away -- am I wrong?

I could protect this by removing the tuple file right before running the executable in the itest.

--Joe User

Answer: The contents of test directories are not deleted between builds and your tests are expecting the test directories to be empty.

We do not delete the itest directory on the rebuilds.

If we did that we would have to redo all the tests in the build every night. That takes 6-8 hours. We will not run a test a second time if it exits with a status of zero. In other words, once a test succeeds, we do not run it again.

Could it be that your test runs and fails and your test script does not cleanup the output file before trying to run it again?

That sounds like what you are describing.

> Your package has problems in the latest build of D0RunII.
>
...
>
> #
> #-----</tmp/PACKAGE_vVERSION_tRELEASE_build-BUILD_OS-COMPILER-uniqueUNIQUE_NAME.tmp>-----
> #
> ERROR: (ctest_rules.mk ; __PACKAGE__ ) Integrated test failed.
> ***
> *** Test output:
> ***
> Termination Summary
> Process
...
> type message id Examples: run/evt run/evt run/evt
> ---- -------------------- ---------------- --------------------------------
> 1 Initializing impTagR impTagReco:impt
...
> Severity # Occurrences Total Occurrences
> -------- ------------- -----------------
> Info 28 28
> C++ runtime abort: terminate() called by the exception handling mechanism
> ***
> *** End of test output.
> ***

FAQ-004.0: Versions Of All Packages For A Given Release

Question: is there a command that shows the versions for all packages (or a specified package) for a given test or production release?

Answer #1: Look at the soft link in the releases area.

For example, what tag is used in p11.04.00 for tsim_l1muo?

ls -al /d0dist/dist/releases/p11.04.00/tsim_l1muo

... Mar 28 17:39 /d0dist/dist/releases/p11.04.00/tsim_l1muo -> ../../packages/tsim_l1muo/p11-03-00b

p11-03-00b is the answer.

Answer #2: Do a 'cat' of the inventory file in the release area for the package

Actually,

cat /d0dist/dist/releases/p11.04.00/D0reldb/inventory

is what you want.

You can also do:

cd /d0dist/dist/releases/p11.04.00/
ls -l | grep '^l'

to get the same information (more than one way to skin the cat).

FAQ-004.1: Dates On Version Directories

Question: Why have the dates on the version directories changed?

I thought you are building p11.04.00 these days. But I see p11.01.00 has the most recent date, Mar. 27, and p11.01.01 has date of Mar. 26. Are you rebuilding the p11.01 releases?  E.g.:

drwxrwxr-x 16 d0relmgr d0_cdist 24576 Mar 27 13:48 p11.01.00
drwxrwxr-x 11 d0relmgr d0_cdist 24576 Mar 26 16:17 p11.01.01
drwxrwxr-x 16 d0relmgr d0_cdist 24576 Mar 8 16:11 p11.02.00
drwxrwxr-x 17 d0relmgr d0_cdist 24576 Mar 22 20:18 p11.03.00
lrwxrwxr-x 1 d0relmgr d0_cdist 25 Mar 26 13:45 p11.04.00

Thank you,

Answer: It's just that a file changed in the directory.

That just means that some file was changed in that directory. NO, we are not rebuilding those old versions. In fact we can't.

I think that it is probably lxr (the code browser) doing that.

FAQ-005: Picking Out Certain Events

Question: How do I pick out a specific reconstructed event?

I'm having trouble using pick_events. I would like to retrieve two specific events for the purpose of using an event display. In order to do this, I need the reconstructed events rather than the raw, obviously.

When I follow the instructions on the pick_events page, I get no events back. Looking at my dataset definition via the SAM pages, I see that it has no files in it. When I remove the "datatier reco" constraint, I get two raw files, one for each event. Without much trouble, I'm able to find the reco files that correspond to those raw files. (But, when I try to use getroot.py to grab the entire file, my job goes into PSUSP mode)

Is it not possible to use the EVENT_NUMBER constraint on reconstructed files? It must be possible, because how otherwise could one use pick_events to get a reco'd file out of SAM?

Answer: You can't -- pick_events can not currently (as of 2/27/02) access reconstructed events

pick_events can not currently access reconstructed events. The problem is being worked on by the SAM team, and an announcement will be made when the problem is resolved.

By the way, you can search d0rug archives to find out this sort of information via:

http://listserv.fnal.gov/scripts/wa.exe?S1=d0rug

I used this search and looked for "pick_events" to get:

http://listserv.fnal.gov/scripts/wa.exe?A2=ind0202&L=d0rug&P=R10991


 
 
Last modified: Wed Apr 23, 2002
Security, Privacy, Legal Notices
 Maintained by: David J. Ritchie