[tahoe-lafs-trac-stream] [tahoe-lafs] #1246: figure out why "FreeStorm Win7-amd64-mingw py2.6" is red on the "test-with-fake-pkg" step

[tahoe-lafs]

#1246: figure out why "FreeStorm Win7-amd64-mingw py2.6" is red on the "test-with-
fake-pkg" step
---------------------------+------------------------------------------------
     Reporter:  zooko      |       Owner:  zooko                          
         Type:  defect     |      Status:  closed                         
     Priority:  major      |   Milestone:  soon                           
    Component:  packaging  |     Version:  1.8.0                          
   Resolution:  duplicate  |    Keywords:  buildbot setuptools test-needed
Launchpad Bug:             |  
---------------------------+------------------------------------------------
Changes (by davidsarah):

  * status:  assigned => closed
  * resolution:  => duplicate


Old description:

> MM's buildslave "MM netbsd5 i386 warp" fails the test-from-egg step, like
> this:
> {{{
> Traceback (most recent call last):
>   File
> "/home/tahoe/buildslave/tahoe/netbsd5-i386/build/misc/build_helpers/run_trial.py",
> line 52, in <module>
>     __import__(modulename)
> ImportError: No module named allmydata.test
> }}}
> FS's buildslave "!FreeStorm Win7-amd64-mingw py2.6" fails the test-with-
> fake-pkg step, like this:
> {{{
> Traceback (most recent call last):
>   File
> "c:\buildbot_tahoe\FreeStorm_Win7-amd64-mingw_py2.6\build\src\..\misc\build_helpers\run_trial.py",
> line 98, in <module>
>     raise AssertionError(msg)
> AssertionError: We seem to be testing the code at 'c:\\python26\\lib'
> (according to the source filename 'c:\\python26\\lib\\site-
> packages\\allmydata\\test\\test_base62.pyc'),
> but expected to be testing the code at
> 'c:\\buildbot_tahoe\\freestorm_win7-amd64-mingw_py2.6\\build'.
> This script needs to be run from the source directory to be tested.
> }}}
> (In [http://tahoe-
> lafs.org/buildbot/builders/FreeStorm%20Win7-amd64-mingw%20py2.6/builds/149
> a subsequent build], this buildslave [http://tahoe-
> lafs.org/buildbot/builders/FreeStorm%20Win7-amd64-mingw%20py2.6/builds/149/steps/test/logs/stdio
> hung], and then in subsequent builds it was [http://tahoe-
> lafs.org/buildbot/builders/FreeStorm%20Win7-amd64-mingw%20py2.6/builds/150/steps/darcs/logs/stdio
> unable to start] due to a process holding a handle to the {{{build}}}
> directory.)

New description:

 (Note that the two failures here have different causes. From comment:4
 onwards, this ticket is about the second one.)

 MM's buildslave "MM netbsd5 i386 warp" fails the test-from-egg step, like
 this:
 {{{
 Traceback (most recent call last):
   File
 "/home/tahoe/buildslave/tahoe/netbsd5-i386/build/misc/build_helpers/run_trial.py",
 line 52, in <module>
     __import__(modulename)
 ImportError: No module named allmydata.test
 }}}
 FS's buildslave "!FreeStorm Win7-amd64-mingw py2.6" fails the test-with-
 fake-pkg step, like this:
 {{{
 Traceback (most recent call last):
   File
 "c:\buildbot_tahoe\FreeStorm_Win7-amd64-mingw_py2.6\build\src\..\misc\build_helpers\run_trial.py",
 line 98, in <module>
     raise AssertionError(msg)
 AssertionError: We seem to be testing the code at 'c:\\python26\\lib'
 (according to the source filename 'c:\\python26\\lib\\site-
 packages\\allmydata\\test\\test_base62.pyc'),
 but expected to be testing the code at
 'c:\\buildbot_tahoe\\freestorm_win7-amd64-mingw_py2.6\\build'.
 This script needs to be run from the source directory to be tested.
 }}}
 (In [http://tahoe-
 lafs.org/buildbot/builders/FreeStorm%20Win7-amd64-mingw%20py2.6/builds/149
 a subsequent build], this buildslave [http://tahoe-
 lafs.org/buildbot/builders/FreeStorm%20Win7-amd64-mingw%20py2.6/builds/149/steps/test/logs/stdio
 hung], and then in subsequent builds it was [http://tahoe-
 lafs.org/buildbot/builders/FreeStorm%20Win7-amd64-mingw%20py2.6/builds/150/steps/darcs/logs/stdio
 unable to start] due to a process holding a handle to the {{{build}}}
 directory.)

--

Comment:

 Replying to [comment:20 davidsarah]:
 > My conclusion at this point is that we need to know why the problem is
 only occurring in subprocesses, before we can write a reliable test.

 This is due to a different order for entries in {{{__requires__}}}. With
 help from abadger1999 (Toshio Kuratomi), we worked out a reliable test,
 using only three dists (two versions of one package and one of another),
 that will be independent of any globally installed packages. I'll prepare
 a patch for that.

 I'm now sure that this is the same issue as #1258, so I'm marking it as a
 duplicate (but all of the discussion in this ticket from comment:4 on is
 still relevant).

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1246#comment:23>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage