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

  • Thread starter Thread starter Anonymous
  • Start date Start date
A

Anonymous

Guest
Code: 
[
===>   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?
 
Regretably, that's not it. It's been refreshed each time.
 
Well, I know that I call
Code: 
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
Code: 
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.
 
Open the port on freshports and click on the CVSWeb link.

Looking at the port Makefile a little closer I see this:
Code: 
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.
 
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.
Click to expand...

*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?
 
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?
Click to expand...
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?
Click to expand...
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.
 
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?
Click to expand...

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.
 
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.
Click to expand...

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.
 
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.
 
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.
Click to expand...

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.
 
Your perception of how ports work may be inaccurate. The ports system of Makefiles handles dependencies, not updates.
 
wblock@ said:
Your perception of how ports work may be inaccurate. The ports system of Makefiles handles dependencies, not updates.
Click to expand...

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?
 
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.
 
You must log in or register to reply here.
Back
Top