# Firefox build fails:  can't find Python-2.7.2.



## Anonymous (Feb 13, 2013)

```
[
===>   firefox-18.0.2,1 depends on package: nspr>=4.9.3 - found
===>   firefox-18.0.2,1 depends on package: nss>=3.14.1 - found
===>   firefox-18.0.2,1 depends on package: sqlite3>=3.7.14.1 - found
===>   firefox-18.0.2,1 depends on file: /usr/local/lib/python2.7/site-packages/_sqlite3.so - not found
===>    Verifying install for /usr/local/lib/python2.7/site-packages/_sqlite3.so in /usr/ports/databases/py-sqlite3
===>  Found saved configuration for sqlite3-3.7.14.1
===>   py27-sqlite3-2.7.2_2 depends on file: /usr/local/sbin/pkg - found
=> Python-2.7.2.tar.xz is not in /usr/ports/lang/python27/distinfo.
=> Either /usr/ports/lang/python27/distinfo is out of date, or
=> Python-2.7.2.tar.xz is spelled incorrectly.
*** Error code 1
```


This has been a problem for at least 2 releases now, and I don't understand why it hasn't been caught.  I've grepped exhaustively for the exact filename and for the root of the name without relevant result.  And I've mailed the maintainer without getting a response.  

Has anyone else run into this, or something similar enough to give me a clue where to find the fail point?


----------



## SirDice (Feb 13, 2013)

Update your ports tree.


----------



## Anonymous (Feb 13, 2013)

Regretably, that's not it.  It's been refreshed each time.


----------



## SirDice (Feb 13, 2013)

It most likely is. For starters databases/py-sqlite3 is at version 2.7.3_2. And has this commit message:


> - do not hardcode distfile extension for lang/python ports in bsd.python.mk
> (PYTHON_DISTFILE variable)


----------



## Anonymous (Feb 13, 2013)

Well, I know that I call 
	
	



```
portsnap fetch update
```
 routinely -even repeatedly (magical thinking)- so if that isn't enough to bring things current then I'm lost.

In fact, I just now called it again to be completely, totally sure that the tree is clean.  And I did a 
	
	



```
make rmconfig-recursive
```
 to be sure I would be doing a vanilla build.  But it didn't help: I got the same error.

Where did you find that commit message?  The times I've written a makefile have been few and none of them needed more than a page or two, so I get lost trying to find anything in FreeBSD's banyan-tree of makefiles and their includes.


----------



## SirDice (Feb 13, 2013)

Open the port on freshports and click on the CVSWeb link.

Looking at the port Makefile a little closer I see this:

```
PORTVERSION=    ${PYTHON_PORTVERSION}
```

Which leads me to think you need to update your python first, then update the python modules. Once those are up to date you can update firefox.


----------



## Anonymous (Feb 13, 2013)

SirDice said:
			
		

> Which leads me to think you need to update your python first, then update the python modules. Once those are up to date you can update firefox.



*sigh* Thanks, explicitly rebuilding Python and py-sqlite did indeed allow FF to compile.

Which brings up another question:  I've been presuming that FreeBSD makefiles operate like SCO, SysV, and even Solaris makefiles in that any stale dependencies are automagically rebuilt without needing anything done by hand.  Is that not so?  

Or was this just a case of the maintainer not doing a final build on a clean machine to make sure his makefile actually worked?


----------



## SirDice (Feb 14, 2013)

Auld_Besom said:
			
		

> Which brings up another question:  I've been presuming that FreeBSD makefiles operate like SCO, SysV, and even Solaris makefiles in that any stale dependencies are automagically rebuilt without needing anything done by hand.  Is that not so?


No, that is correct. 



> Or was this just a case of the maintainer not doing a final build on a clean machine to make sure his makefile actually worked?


The problem is, I think, the variable in the port's Makefile, it seems to refer to the _installed_ version of python and not to the new version. Hence it tries to build the module with the current version 2.7.2 instead of the new 2.7.3 one.


----------



## kpa (Feb 14, 2013)

Auld_Besom said:
			
		

> *sigh* Thanks, explicitly rebuilding Python and py-sqlite did indeed allow FF to compile.
> 
> Which brings up another question:  I've been presuming that FreeBSD makefiles operate like SCO, SysV, and even Solaris makefiles in that any stale dependencies are automagically rebuilt without needing anything done by hand.  Is that not so?
> 
> Or was this just a case of the maintainer not doing a final build on a clean machine to make sure his makefile actually worked?



The relationships of kind "newer/uptodate/older version of a port" can not be expressed as simple make(1) rules because it looks just at the modification dates of  files.


----------



## borsti007 (Feb 21, 2013)

Hi, 

I've the same problem with Firefox 19 and FF 17-esr. Don't know what to do.

Any suggestion. 

Thanks, 
Jens


----------



## SirDice (Feb 21, 2013)

Read post #6.


----------



## Anonymous (Mar 7, 2013)

SirDice said:
			
		

> The problem is, I think, the variable in the port's Makefile, it seems to refer to the _installed_ version of python and not to the new version. Hence it tries to build the module with the current version 2.7.2 instead of the new 2.7.3 one.



Okay, but how could you tell?  Is there some naming convention that told you it refers specifically to the current rather than latest and greatest version?  If so, I would _never_ have spotted it because it looked like a perfectly reasonable identifier.


----------



## wblock@ (Mar 7, 2013)

A big clue is that even though Python was already installed, it wanted to install it again.  That means something is wrong.

As far as how that happened, I'd guess it's from updating only some ports.  That does not work for long, dependencies become impossible.  If you plan to install new ports or new versions of existing ones, update all your ports.  That means all the installed ones, not just the ports tree.  A vital step is reading /usr/ports/UPDATING and following any required new steps in there since the last upgrade.  For reference: Upgrading FreeBSD Ports.


----------



## Anonymous (Mar 7, 2013)

wblock@ said:
			
		

> As far as how that happened, I'd guess it's from updating only some ports.  That does not work for long, dependencies become impossible.  If you plan to install new ports or new versions of existing ones, update all your ports.  That means all the installed ones, not just the ports tree.  A vital step is reading /usr/ports/UPDATING and following any required new steps in there since the last upgrade.  For reference: Upgrading FreeBSD Ports.



Okay, this is where my experience steers me wrong:  I'm used to the _makefile_ deciding whether to update.  The idea that I have to thumb through the ports and do it by hand every time I want to add something seems to contradict the very purpose of a makefile -- which, in every bit of documentation I've ever seen, including FreeBSD's, says the purpose of a makefile is to avoid doing things by hand each time!  Of course I accept that you know what you're talking about, but it suggests to me that the system is more broken than I thought.


----------



## wblock@ (Mar 7, 2013)

Your perception of how ports work may be inaccurate.  The ports system of Makefiles handles dependencies, not updates.


----------



## Anonymous (Mar 7, 2013)

wblock@ said:
			
		

> Your perception of how ports work may be inaccurate.  The ports system of Makefiles handles dependencies, not updates.



Okay, now you're confusing me (I know: easy peasy).  That's why I asked of SirDice whether FreeBSD makefiles work the same way as SCO, SysV, and Solaris makefiles: automagically handling the rebuilding of stale dependencies.  Are you saying that's _not_ the case?


----------



## wblock@ (Mar 8, 2013)

make(1) is one piece of ports, but not all of it.  Just realize that the ports system does not automatically upgrade or rebuild ports.  It is geared towards making sure needed dependencies are installed.  If you keep all ports updated, it works.

Run `% pkg_info` and look through the output.  There are probably more than a few duplicate packages with multiple versions installed.  The easiest way to fix that is to rebuild everything with the procedure shown at the end of the portmaster(8) man page.  It will take some time, but will fix things that your other thread shows are broken.


----------

