Re: selfupdate fails

[Ryan Schmidt]

On Aug 17, 2015, at 8:35 PM, Michael David Crawford wrote:

> On Monday, August 17, 2015, Ryan Schmidt wrote:
> 
>> Yes, you can change what servers MacPorts uses:
>> 
>> https://trac.macports.org/wiki/Mirrors
>> 
>> If you can set up an rsync server on your network, and that server can 
>> connect to our master server via rsync to mirror its contents, then that 
>> could work.
> 
> The people who maintain the firewall or would set up the server may not have 
> a clue about the Macintosh, let alone MacPorts.
> 
> The required managerial sign-off may not have a clue about computers of any 
> sort.  I have even seen this at Apple and Microsoft.  You could facilitate 
> their sign-off by providing a PDF with an executive summart;  MacPorts fans 
> could send them via Internal snail mail to corporate.

Note that no understanding of MacPorts or OS X is required. I don't think any 
of the MacPorts servers (except the buildbot builders), nor any of the mirrors, 
are running on OS X. All that's required is the ability to set up an rsync 
server, configure it to allow your internal users to access it using the rsync 
protocol, and allow it to access our server using the rsync protocol, and 
configure a recurring task (i.e. cron job) to periodically mirror the 
information from whichever categories of our server are desired (MacPorts base 
source code; portfiles source code; source distfiles; precompiled binary 
archives). There is an email we've prepared in response to questions about how 
to set up mirror servers, which I can send to you, if you want to go that 
route. Ideally we would put this information in the public wiki, we just 
haven't done that yet.

If setting up an internal server is not desired, it's not necessary, you just 
won't be able to use the selfupdate command, because the selfupdate command 
requires the ability to connect to an rsync server. In the absence of that 
ability, you can do both of the following:

1. configure MacPorts to sync from http or https tarball or Subversion 
repository and periodically run "sudo port sync" to update the portfiles; and
2. whenever a new version of MacPorts is released, download it from our web 
site and install it.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Michael David Crawford]

On Monday, August 17, 2015, Ryan Schmidt  wrote:
>
> On Aug 17, 2015, at 8:01 PM, Michael David Crawford wrote:
> Yes, you can change what servers MacPorts uses:
>
> https://trac.macports.org/wiki/Mirrors
>
> If you can set up an rsync server on your network, and that server can
> connect to our master server via rsync to mirror its contents, then that
> could work.


The people who maintain the firewall or would set up the server may not
have a clue about the Macintosh, let alone MacPorts.

The required managerial sign-off may not have a clue about computers of any
sort.  I have even seen this at Apple and Microsoft.  You could facilitate
their sign-off by providing a PDF with an executive summart;  MacPorts fans
could send them via Internal snail mail to corporate.

Thine In Eternal Torment,

Mike

53n7 fr0m my 1p4d.


-- 
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

Every Deity Hath the Insight to Foretell the Future
Yet G-d Almighty Himself Possesseth Not the Power to Undo the Past.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Aug 17, 2015, at 8:01 PM, Michael David Crawford wrote:

> Can one configure the port command to use a local - intranet - server for 
> selfupdate?

Yes, you can change what servers MacPorts uses:

https://trac.macports.org/wiki/Mirrors

If you can set up an rsync server on your network, and that server can connect 
to our master server via rsync to mirror its contents, then that could work.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Michael David Crawford]

Can one configure the port command to use a local - intranet - server for
selfupdate?

On Monday, August 17, 2015, Ryan Schmidt  wrote:
>
> Yes, you'll need to troubleshoot with your network administrator why
> you're not able to access rsync servers. If it cannot be fixed, you can
> configure MacPorts to sync using a different method, such as by getting the
> daily tarball via http or by getting the sources directly from our
> Subversion repository.
>

  Sent from the vast empty reaches of intergalactic space.


-- 
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

Every Deity Hath the Insight to Foretell the Future
Yet G-d Almighty Himself Possesseth Not the Power to Undo the Past.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Aug 17, 2015, at 8:04 AM, Fred Lahuis wrote:

> Seems to be a firewall issue, works on home network.

Yes, you'll need to troubleshoot with your network administrator why you're not 
able to access rsync servers. If it cannot be fixed, you can configure MacPorts 
to sync using a different method, such as by getting the daily tarball via http 
or by getting the sources directly from our Subversion repository.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Fred Lahuis]

Seems to be a firewall issue, works on home network.
Fred


> On 17 Aug 2015, at 13:10, Fred Lahuis  wrote:
> 
> 
> OSX 10.10.4
> port version 2.3.3
> 
> “port selfupdate” fails on connecting to rsync server, see output below. In 
> the browser 
> there is no problem connecting to rsync.macports.org and the connection is 
> instant.
> Anything I can do / I should (not) do
> 
> sudo port -d selfupdate 
> 
> DEBUG: Copying /Users/freddy/Library/Preferences/com.apple.dt.Xcode.plist to 
> /opt/local/var/macports/home/Library/Preferences
> DEBUG: MacPorts sources location: 
> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
> --->  Updating MacPorts base sources using rsync
> rsync: failed to connect to rsync.macports.org: Operation timed out (60)
> rsync error: error in socket IO (code 10) at 
> /SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzv --delete-after 
> rsync://rsync.macports.org/release/tarballs/base.tar/opt/local/var/macports/sources/rsync.macports.org/release/tarballs
> Exit code: 10
> DEBUG: Error synchronizing MacPorts sources: command execution failed
>   while executing
> "macports::selfupdate [array get global_options] base_updated"
> Error: Error synchronizing MacPorts sources: command execution failed
> To report a bug, follow the instructions in the guide:
>   http://guide.macports.org/#project.tickets
> Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
> MacPorts sources: command execution failed
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

selfupdate fails

[Fred Lahuis]

OSX 10.10.4
port version 2.3.3

“port selfupdate” fails on connecting to rsync server, see output below. In the 
browser 
there is no problem connecting to rsync.macports.org and the connection is 
instant.
Anything I can do / I should (not) do

sudo port -d selfupdate 

DEBUG: Copying /Users/freddy/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: MacPorts sources location: 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs
--->  Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org: Operation timed out (60)
rsync error: error in socket IO (code 10) at 
/SourceCache/rsync/rsync-45/rsync/clientserver.c(105) [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzv --delete-after 
rsync://rsync.macports.org/release/tarballs/base.tar/opt/local/var/macports/sources/rsync.macports.org/release/tarballs
Exit code: 10
DEBUG: Error synchronizing MacPorts sources: command execution failed
   while executing
"macports::selfupdate [array get global_options] base_updated"
Error: Error synchronizing MacPorts sources: command execution failed
To report a bug, follow the instructions in the guide:
   http://guide.macports.org/#project.tickets
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
MacPorts sources: command execution failed

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Jerry]

On Jul 10, 2014, at 2:37 PM, Adam Dershowitz Ph.D., P.E.  
wrote:

> 
> 
> On Jul 10, 2014, at 5:20 PM, Jerry  wrote:
> 
>> 
>> On Jul 10, 2014, at 6:08 AM, Adam Dershowitz Ph.D., P.E. 
>>  wrote:
>> 
>>> 
>>> 
>>> On Jul 10, 2014, at 1:41 AM, Ryan Schmidt  wrote:
>>> 
 
 On Jul 9, 2014, at 11:01 PM, Adam Dershowitz  wrote:
> 
> No. They do use existing standard ports. So openmodelica does require 
> certain macporys dependencies, not its own separate copies. I don't know 
> about Qt, and don't have access to check at the moment. But, my guess is 
> that they are using the standard macport Qt, not a redundant one. I know 
> that for a bunch of other things they just use the macport port so there 
> is no redundancy. They have even worked on some ports to get them 
> upgraded to get things to work together. The only reason that I could see 
> any redundant versions is if they require some specific version that 
> macports doesn't have. And doing that would be tricky to avoid any 
> conflicting versions.
> I think that you have a bit of a misunderstanding. You could, for example 
> create your own port file of something, and just keep that file locally 
> (see the macport instructions). That port could then have other 
> dependencies that are included with macports. All they have done is put 
> their port file, instead, on their server, and you can then use it by 
> adding it to your sources file. No redundant files involved, and no extra 
> disk space. A port file is just a text file that explains where to find 
> files, and how to build. Part of that "how" is what other ports are 
> required to be installed. If someone were able to copy the current port 
> file from their server to macports the build would be identical in size 
> and dependents.
> My guess is that the reason they haven't done that is because the release 
> version is a bit behind, and the develop version is changing every day. 
> But I don't know for sure.
 
 Adam, Jerry is correct. The binary distribution provided on the 
 openmodelica web site, though created with MacPorts, installs the 
 MacPorts-provided dependencies into a separate prefix /opt/openmodelica, 
 not the normal MacPorts prefix /opt/local. This is exactly as we at 
 MacPorts would recommend for a third party wanting to distribute a 
 standalone installer so that it will not conflict with an existing 
 MacPorts installation. Jerry is correct that, would the openmodelica 
 developers instead submit their portfile to be included in the standard 
 MacPorts ports tree, then openmodelica could be installed by using 
 existing MacPorts dependencies (in /opt/local or whatever the user's 
 prefix is), and would not need separate copies thereof in 
 /opt/openmodelica. The user can already accomplish this however by setting 
 up a second sources entry in their sources.conf pointing to the 
 openmodelica rsync server, which is in fact what Jerry had done and is 
 what prompted him to begin this thread, when the openmodelica rsync server 
 was temporarily offline.
 
 You can read more about all of this at:
 
 https://www.openmodelica.org/index.php/download/download-mac
 
 
>>> 
>>> 
>>> Perhaps we just were not communicating clearly.  I was not talking about 
>>> the binary, and I didn’t think that Jerry was either (perhaps I am 
>>> mistaken).  He was suggesting that they make an “official port file”  and 
>>> they already have one.  They just keep it on their own server.  The 
>>> instructions on that page make it clear, as you said.  The reason that I 
>>> believe the binary had nothing to do with Jerry’s comments is because if he 
>>> was using the binary he would not have run into the rsync problem when 
>>> their server went down. That problem was purely from trying to download the 
>>> source port file, which, as I have said, takes up the same amount of space 
>>> whether on their server or the macports server.
>>> I did verify that their port does just use the existing qt4-mac port, for 
>>> example, so their is no redundancy in Qt, as Jerry had suggested.  But, I 
>>> do understand that if someone installs the binary, then they are not using 
>>> Macports for the install, and will be downloading a whole bunch of stuff 
>>> that they might already have.  
>>> The port file for openmodelica-devel changes many times a day.  So, I 
>>> assume that they have a script that auto generates it, on their server, for 
>>> every change in their development branch.  I have been using their 
>>> development branch with macports, for a while now, and it has tended to 
>>> work well.  As it is devel, there are occasional problems, but they have 
>>> always been very quick to fix them, and keep it building.  
>> 
>> 
>> Well, let's all agree that I barely know what I'm talking about. 
>> 
>> My f

Re: selfupdate fails trying to synch with openmodelica (!)

[Adam Dershowitz Ph.D., P.E.]

On Jul 10, 2014, at 5:20 PM, Jerry  wrote:

> 
> On Jul 10, 2014, at 6:08 AM, Adam Dershowitz Ph.D., P.E.  
> wrote:
> 
>> 
>> 
>> On Jul 10, 2014, at 1:41 AM, Ryan Schmidt  wrote:
>> 
>>> 
>>> On Jul 9, 2014, at 11:01 PM, Adam Dershowitz  wrote:
 
 No. They do use existing standard ports. So openmodelica does require 
 certain macporys dependencies, not its own separate copies. I don't know 
 about Qt, and don't have access to check at the moment. But, my guess is 
 that they are using the standard macport Qt, not a redundant one. I know 
 that for a bunch of other things they just use the macport port so there 
 is no redundancy. They have even worked on some ports to get them upgraded 
 to get things to work together. The only reason that I could see any 
 redundant versions is if they require some specific version that macports 
 doesn't have. And doing that would be tricky to avoid any conflicting 
 versions.
 I think that you have a bit of a misunderstanding. You could, for example 
 create your own port file of something, and just keep that file locally 
 (see the macport instructions). That port could then have other 
 dependencies that are included with macports. All they have done is put 
 their port file, instead, on their server, and you can then use it by 
 adding it to your sources file. No redundant files involved, and no extra 
 disk space. A port file is just a text file that explains where to find 
 files, and how to build. Part of that "how" is what other ports are 
 required to be installed. If someone were able to copy the current port 
 file from their server to macports the build would be identical in size 
 and dependents.
 My guess is that the reason they haven't done that is because the release 
 version is a bit behind, and the develop version is changing every day. 
 But I don't know for sure.
>>> 
>>> Adam, Jerry is correct. The binary distribution provided on the 
>>> openmodelica web site, though created with MacPorts, installs the 
>>> MacPorts-provided dependencies into a separate prefix /opt/openmodelica, 
>>> not the normal MacPorts prefix /opt/local. This is exactly as we at 
>>> MacPorts would recommend for a third party wanting to distribute a 
>>> standalone installer so that it will not conflict with an existing MacPorts 
>>> installation. Jerry is correct that, would the openmodelica developers 
>>> instead submit their portfile to be included in the standard MacPorts ports 
>>> tree, then openmodelica could be installed by using existing MacPorts 
>>> dependencies (in /opt/local or whatever the user's prefix is), and would 
>>> not need separate copies thereof in /opt/openmodelica. The user can already 
>>> accomplish this however by setting up a second sources entry in their 
>>> sources.conf pointing to the openmodelica rsync server, which is in fact 
>>> what Jerry had done and is what prompted him to begin this thread, when the 
>>> openmodelica rsync server was temporarily offline.
>>> 
>>> You can read more about all of this at:
>>> 
>>> https://www.openmodelica.org/index.php/download/download-mac
>>> 
>>> 
>> 
>> 
>> Perhaps we just were not communicating clearly.  I was not talking about the 
>> binary, and I didn’t think that Jerry was either (perhaps I am mistaken).  
>> He was suggesting that they make an “official port file”  and they already 
>> have one.  They just keep it on their own server.  The instructions on that 
>> page make it clear, as you said.  The reason that I believe the binary had 
>> nothing to do with Jerry’s comments is because if he was using the binary he 
>> would not have run into the rsync problem when their server went down. That 
>> problem was purely from trying to download the source port file, which, as I 
>> have said, takes up the same amount of space whether on their server or the 
>> macports server.
>> I did verify that their port does just use the existing qt4-mac port, for 
>> example, so their is no redundancy in Qt, as Jerry had suggested.  But, I do 
>> understand that if someone installs the binary, then they are not using 
>> Macports for the install, and will be downloading a whole bunch of stuff 
>> that they might already have.  
>> The port file for openmodelica-devel changes many times a day.  So, I assume 
>> that they have a script that auto generates it, on their server, for every 
>> change in their development branch.  I have been using their development 
>> branch with macports, for a while now, and it has tended to work well.  As 
>> it is devel, there are occasional problems, but they have always been very 
>> quick to fix them, and keep it building.  
> 
> 
> Well, let's all agree that I barely know what I'm talking about. 
> 
> My file at /opt/local/etc/macports/sources.conf contains two non-comment 
> lines:
>  rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>  rsync://build.open

Re: selfupdate fails trying to synch with openmodelica (!)

[Jerry]

On Jul 10, 2014, at 6:08 AM, Adam Dershowitz Ph.D., P.E.  
wrote:

> 
> 
> On Jul 10, 2014, at 1:41 AM, Ryan Schmidt  wrote:
> 
>> 
>> On Jul 9, 2014, at 11:01 PM, Adam Dershowitz  wrote:
>>> 
>>> No. They do use existing standard ports. So openmodelica does require 
>>> certain macporys dependencies, not its own separate copies. I don't know 
>>> about Qt, and don't have access to check at the moment. But, my guess is 
>>> that they are using the standard macport Qt, not a redundant one. I know 
>>> that for a bunch of other things they just use the macport port so there is 
>>> no redundancy. They have even worked on some ports to get them upgraded to 
>>> get things to work together. The only reason that I could see any redundant 
>>> versions is if they require some specific version that macports doesn't 
>>> have. And doing that would be tricky to avoid any conflicting versions.
>>> I think that you have a bit of a misunderstanding. You could, for example 
>>> create your own port file of something, and just keep that file locally 
>>> (see the macport instructions). That port could then have other 
>>> dependencies that are included with macports. All they have done is put 
>>> their port file, instead, on their server, and you can then use it by 
>>> adding it to your sources file. No redundant files involved, and no extra 
>>> disk space. A port file is just a text file that explains where to find 
>>> files, and how to build. Part of that "how" is what other ports are 
>>> required to be installed. If someone were able to copy the current port 
>>> file from their server to macports the build would be identical in size and 
>>> dependents.
>>> My guess is that the reason they haven't done that is because the release 
>>> version is a bit behind, and the develop version is changing every day. But 
>>> I don't know for sure.
>> 
>> Adam, Jerry is correct. The binary distribution provided on the openmodelica 
>> web site, though created with MacPorts, installs the MacPorts-provided 
>> dependencies into a separate prefix /opt/openmodelica, not the normal 
>> MacPorts prefix /opt/local. This is exactly as we at MacPorts would 
>> recommend for a third party wanting to distribute a standalone installer so 
>> that it will not conflict with an existing MacPorts installation. Jerry is 
>> correct that, would the openmodelica developers instead submit their 
>> portfile to be included in the standard MacPorts ports tree, then 
>> openmodelica could be installed by using existing MacPorts dependencies (in 
>> /opt/local or whatever the user's prefix is), and would not need separate 
>> copies thereof in /opt/openmodelica. The user can already accomplish this 
>> however by setting up a second sources entry in their sources.conf pointing 
>> to the openmodelica rsync server, which is in fact what Jerry had done and 
>> is what prompted him to begin this thread, when the openmodelica rsync 
>> server was temporarily offline.
>> 
>> You can read more about all of this at:
>> 
>> https://www.openmodelica.org/index.php/download/download-mac
>> 
>> 
> 
> 
> Perhaps we just were not communicating clearly.  I was not talking about the 
> binary, and I didn’t think that Jerry was either (perhaps I am mistaken).  He 
> was suggesting that they make an “official port file”  and they already have 
> one.  They just keep it on their own server.  The instructions on that page 
> make it clear, as you said.  The reason that I believe the binary had nothing 
> to do with Jerry’s comments is because if he was using the binary he would 
> not have run into the rsync problem when their server went down.  That 
> problem was purely from trying to download the source port file, which, as I 
> have said, takes up the same amount of space whether on their server or the 
> macports server.
> I did verify that their port does just use the existing qt4-mac port, for 
> example, so their is no redundancy in Qt, as Jerry had suggested.  But, I do 
> understand that if someone installs the binary, then they are not using 
> Macports for the install, and will be downloading a whole bunch of stuff that 
> they might already have.  
> The port file for openmodelica-devel changes many times a day.  So, I assume 
> that they have a script that auto generates it, on their server, for every 
> change in their development branch.  I have been using their development 
> branch with macports, for a while now, and it has tended to work well.  As it 
> is devel, there are occasional problems, but they have always been very quick 
> to fix them, and keep it building.  


Well, let's all agree that I barely know what I'm talking about. 

My file at /opt/local/etc/macports/sources.conf contains two non-comment lines:
  rsync://rsync.macports.org/release/tarballs/ports.tar [default]
  rsync://build.openmodelica.org/macports/

I don't know how the second line appeared since I _think_ I have not messed 
with openmodelica since last installing MacPorts

Re: selfupdate fails trying to synch with openmodelica (!)

[Adam Dershowitz Ph.D., P.E.]

On Jul 10, 2014, at 1:41 AM, Ryan Schmidt  wrote:

> 
> On Jul 9, 2014, at 11:01 PM, Adam Dershowitz  wrote:
>> 
>> No. They do use existing standard ports. So openmodelica does require 
>> certain macporys dependencies, not its own separate copies. I don't know 
>> about Qt, and don't have access to check at the moment. But, my guess is 
>> that they are using the standard macport Qt, not a redundant one. I know 
>> that for a bunch of other things they just use the macport port so there is 
>> no redundancy. They have even worked on some ports to get them upgraded to 
>> get things to work together. The only reason that I could see any redundant 
>> versions is if they require some specific version that macports doesn't 
>> have. And doing that would be tricky to avoid any conflicting versions.
>> I think that you have a bit of a misunderstanding. You could, for example 
>> create your own port file of something, and just keep that file locally (see 
>> the macport instructions). That port could then have other dependencies that 
>> are included with macports. All they have done is put their port file, 
>> instead, on their server, and you can then use it by adding it to your 
>> sources file. No redundant files involved, and no extra disk space. A port 
>> file is just a text file that explains where to find files, and how to 
>> build. Part of that "how" is what other ports are required to be installed. 
>> If someone were able to copy the current port file from their server to 
>> macports the build would be identical in size and dependents.
>> My guess is that the reason they haven't done that is because the release 
>> version is a bit behind, and the develop version is changing every day. But 
>> I don't know for sure.
> 
> Adam, Jerry is correct. The binary distribution provided on the openmodelica 
> web site, though created with MacPorts, installs the MacPorts-provided 
> dependencies into a separate prefix /opt/openmodelica, not the normal 
> MacPorts prefix /opt/local. This is exactly as we at MacPorts would recommend 
> for a third party wanting to distribute a standalone installer so that it 
> will not conflict with an existing MacPorts installation. Jerry is correct 
> that, would the openmodelica developers instead submit their portfile to be 
> included in the standard MacPorts ports tree, then openmodelica could be 
> installed by using existing MacPorts dependencies (in /opt/local or whatever 
> the user's prefix is), and would not need separate copies thereof in 
> /opt/openmodelica. The user can already accomplish this however by setting up 
> a second sources entry in their sources.conf pointing to the openmodelica 
> rsync server, which is in fact what Jerry had done and is what prompted him 
> to begin this thread, when the openmodelica rsync server was temporarily 
> offline.
> 
> You can read more about all of this at:
> 
> https://www.openmodelica.org/index.php/download/download-mac
> 
> 


Perhaps we just were not communicating clearly.  I was not talking about the 
binary, and I didn’t think that Jerry was either (perhaps I am mistaken).  He 
was suggesting that they make an “official port file”  and they already have 
one.  They just keep it on their own server.  The instructions on that page 
make it clear, as you said.  The reason that I believe the binary had nothing 
to do with Jerry’s comments is because if he was using the binary he would not 
have run into the rsync problem when their server went down.  That problem was 
purely from trying to download the source port file, which, as I have said, 
takes up the same amount of space whether on their server or the macports 
server.
I did verify that their port does just use the existing qt4-mac port, for 
example, so their is no redundancy in Qt, as Jerry had suggested.  But, I do 
understand that if someone installs the binary, then they are not using 
Macports for the install, and will be downloading a whole bunch of stuff that 
they might already have.  
The port file for openmodelica-devel changes many times a day.  So, I assume 
that they have a script that auto generates it, on their server, for every 
change in their development branch.  I have been using their development branch 
with macports, for a while now, and it has tended to work well.  As it is 
devel, there are occasional problems, but they have always been very quick to 
fix them, and keep it building.  
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Ryan Schmidt]

On Jul 9, 2014, at 11:01 PM, Adam Dershowitz  wrote:
> 
> No. They do use existing standard ports. So openmodelica does require certain 
> macporys dependencies, not its own separate copies. I don't know about Qt, 
> and don't have access to check at the moment. But, my guess is that they are 
> using the standard macport Qt, not a redundant one. I know that for a bunch 
> of other things they just use the macport port so there is no redundancy. 
> They have even worked on some ports to get them upgraded to get things to 
> work together. The only reason that I could see any redundant versions is if 
> they require some specific version that macports doesn't have. And doing that 
> would be tricky to avoid any conflicting versions.
> I think that you have a bit of a misunderstanding. You could, for example 
> create your own port file of something, and just keep that file locally (see 
> the macport instructions). That port could then have other dependencies that 
> are included with macports. All they have done is put their port file, 
> instead, on their server, and you can then use it by adding it to your 
> sources file. No redundant files involved, and no extra disk space. A port 
> file is just a text file that explains where to find files, and how to build. 
> Part of that "how" is what other ports are required to be installed. If 
> someone were able to copy the current port file from their server to macports 
> the build would be identical in size and dependents.
> My guess is that the reason they haven't done that is because the release 
> version is a bit behind, and the develop version is changing every day. But I 
> don't know for sure.

Adam, Jerry is correct. The binary distribution provided on the openmodelica 
web site, though created with MacPorts, installs the MacPorts-provided 
dependencies into a separate prefix /opt/openmodelica, not the normal MacPorts 
prefix /opt/local. This is exactly as we at MacPorts would recommend for a 
third party wanting to distribute a standalone installer so that it will not 
conflict with an existing MacPorts installation. Jerry is correct that, would 
the openmodelica developers instead submit their portfile to be included in the 
standard MacPorts ports tree, then openmodelica could be installed by using 
existing MacPorts dependencies (in /opt/local or whatever the user's prefix 
is), and would not need separate copies thereof in /opt/openmodelica. The user 
can already accomplish this however by setting up a second sources entry in 
their sources.conf pointing to the openmodelica rsync server, which is in fact 
what Jerry had done and is what prompted him to begin this thread, 
 when the openmodelica rsync server was temporarily offline.

You can read more about all of this at:

https://www.openmodelica.org/index.php/download/download-mac



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Jerry]

On Jul 9, 2014, at 4:53 PM, Adam Dershowitz  wrote:

> On July 9, 2014 7:15:21 PM EDT, Jerry  wrote:
> 
> On Jul 9, 2014, at 6:15 AM, Adam Dershowitz Ph.D., P.E.  
> wrote:
>  It seems that the openmodelica.org is back up, so the sync should work again 
> (at least it does for me)
> 
> Problem solved when openmodelica.org came back.
> 
> Maybe someday the openmodelica folks could make an official port file for 
> macports instead of dumping a GB load on people's disk which duplicates in 
> most cases stuff that they already have.
> 
> Thanks, everyone.
> 
> Jerry
> 
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
> 
> I don't think those are related. They made a port file, they just keep it on 
> their own server. If they moved the port, and all the files to macport.org, 
> that would not change the size of the download. There are some required 
> dependencies and they get installed when you install it. That would not 
> change with an "official" port.
> The only change is then installation would be slightly easier, since the port 
> is in macports already. 
> 
> --Adam

I was assuming that, since many dependencies service more than one port, a 
"proper" macports port of openmodelica would, in many cases, cause less 
additional disk storage than their standalone package derived from macports. 
For example, openmodelica uses Qt; Qt is also used by many other ports, so the 
Qt bundled with their standalone package would be redundant and wasteful. Yes, 
of one does not have MacPorts already installed then the standalone approach 
would be more efficient.

I may have used "port file" incorrectly. Sorry of that caused confusion. I 
meant only to suggest that they provide an official MacPorts way to install 
their software achievable by port install openmodelica.

Jerry
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Adam Dershowitz]

On July 9, 2014 7:15:21 PM EDT, Jerry  wrote:
>
>On Jul 9, 2014, at 6:15 AM, Adam Dershowitz Ph.D., P.E.
> wrote:
>> It seems that the openmodelica.org is back up, so the sync should
>work again (at least it does for me)
>
>Problem solved when openmodelica.org came back.
>
>Maybe someday the openmodelica folks could make an official port file
>for macports instead of dumping a GB load on people's disk which
>duplicates in most cases stuff that they already have.
>
>Thanks, everyone.
>
>Jerry
>___
>macports-users mailing list
>macports-users@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-users
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

I don't think those are related.  They made a port file, they just keep it on 
their own server.  If they moved the port, and all the files to macport.org, 
that would not change the size of the download.  There are some required 
dependencies  and they get installed when you install it.  That would not 
change with an "official" port.
The only change is then installation would be slightly easier, since the port 
is in macports already.  

--Adam___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Jerry]

On Jul 9, 2014, at 6:15 AM, Adam Dershowitz Ph.D., P.E.  
wrote:
> It seems that the openmodelica.org is back up, so the sync should work again 
> (at least it does for me)

Problem solved when openmodelica.org came back.

Maybe someday the openmodelica folks could make an official port file for 
macports instead of dumping a GB load on people's disk which duplicates in most 
cases stuff that they already have.

Thanks, everyone.

Jerry
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Adam Dershowitz Ph.D., P.E.]

On Jul 8, 2014, at 6:12 PM, Jerry  wrote:

> OS 10.9.4
> MacPorts 2.3.1
> 
> I have run into this problem in connection to attempts to install qtiplot 
> https://trac.macports.org/ticket/44252 but is surely unrelated.
> 
> I just did selfupdate and got weird problem with openmodelica which isn't 
> even an available port. Terminal session is pasted below.
> 
> I run selfupdate from time to time and haven't had this problem. I ran 
> selfupdate yesterday without a problem. I'm flabbergasted.
> 
> More than two years ago I tried to install OpenModelica from probably 
> openmodelica.org. The installer was a macports-based standalone deal and had 
> lots of problems. I finally abandoned it and removed all traces of it. (It 
> installed into /opt/openmodelica and there was a weird problem with a launch 
> agent relating to org.freedesktop.dbus-session.plist.) I haven't had anything 
> to do with it since.
> 
> I have upgraded my OS once and probably twice since then. I have re-installed 
> MacPorts from scratch about two months ago after upgrading to Mavericks. Like 
> I said, I've run selfupdate a number of times, even recently, with no 
> problems.
> 
> I have Wolfram SystmModeler which is a version of OpenModelica with hooks 
> into Mathematica. I rarely use it and haven't even launched it in months. 
> Mathematica was running when I ran the problematic selfupdate today, but not 
> SystemModeler. I'm only mentioning this because like I said I can't see any 
> explanation at all. As far as I know the Wolfram product has nothing to do 
> with MacPorts.
> 
> The following folders are present in my MacPorts tree, discovered using Path 
> Finder. I don't know why. The first folder contains about 131 kB. There is 
> nothing related to openmodelica in response to port installed.
> 
> /opt/local/var/macports/sources/build.openmodelica.org
> /opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelica
> /opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelica-devel
> /opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelica-release
> /opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelicalibraries
> 
> 
> 
> == Pasted terminal session ===
> 
> MBPro:~ me$ sudo port -v selfupdate
> --->  Updating MacPorts base sources using rsync
> receiving file list ... done
> 
> sent 36 bytes  received 69 bytes  70.00 bytes/sec
> total size is 27002880  speedup is 257170.29
> receiving file list ... done
> 
> sent 36 bytes  received 76 bytes  74.67 bytes/sec
> total size is 512  speedup is 4.57
> MacPorts base version 2.3.1 installed,
> MacPorts base version 2.3.1 downloaded.
> --->  Updating the ports tree
> Synchronizing local ports tree from 
> rsync://rsync.macports.org/release/tarballs/ports.tar
> receiving file list ... done
> 
> sent 36 bytes  received 70 bytes  70.67 bytes/sec
> total size is 60876800  speedup is 574309.43
> receiving file list ... done
> 
> sent 36 bytes  received 77 bytes  75.33 bytes/sec
> total size is 512  speedup is 4.53
> Creating port index in 
> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports
> 
> Total number of ports parsed: 0 
> Ports successfully parsed:0 
> Ports failed: 0 
> Up-to-date ports skipped: 18743
> 
> Synchronizing local ports tree from rsync://build.openmodelica.org/macports/
> rsync: failed to connect to build.openmodelica.org: Operation timed out (60)
> rsync error: error in socket IO (code 10) at 
> /SourceCache/rsync/rsync-42/rsync/clientserver.c(105) [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzv --delete-after '--exclude=/PortIndex*' 
> rsync://build.openmodelica.org/macports/ 
> /opt/local/var/macports/sources/build.openmodelica.org/macports
> Exit code: 10
> Error: Synchronization of the local ports tree failed doing rsync
> Error: Couldn't sync the ports tree: Synchronization of 1 source(s) failed
> To report a bug, follow the instructions in the guide:
>http://guide.macports.org/#project.tickets
> Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
> tree: Synchronization of 1 source(s) failed


It seems that the openmodelica.org is back up, so the sync should work again 
(at least it does for me)
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Adam Dershowitz]

Yes, the installation instructions for openmodelica are to add that to the 
sources.conf.
I have been building and installing openmodelica successfully that way for a 
while.  I don't know how it was back when you tried it, but now it is very 
functional.
But, it seems that their server is down today.  (Even www.openmodelica.org) and 
macport just times out trying to connect.
So, I would say, if you don't use it anyway, you can take it out of your 
sources.conf file.  Or just wait, and hope that they get it fixed shortly.  I 
have found the openmodelica folks to be very responsive, so I would expect that 
they will fix it shortly.
By the way, is there any way at the command line to get macport to just sync 
some, or avoid, some sources? 

On July 8, 2014 6:22:24 PM EDT, Brandon Allbery  wrote:
>On Tue, Jul 8, 2014 at 6:12 PM, Jerry  wrote:
>
>> Synchronizing local ports tree from rsync://
>> build.openmodelica.org/macports/
>>
>
>The fact that it tries this at all suggests it's listed in
>/opt/local/etc/macports/sources.conf or in the equivalent file under
>~/.macports (whose exact name I'm not sure of).
>
>-- 
>brandon s allbery kf8nh   sine nomine
>associates
>allber...@gmail.com 
>ballb...@sinenomine.net
>unix, openafs, kerberos, infrastructure, xmonad   
>http://sinenomine.net
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
>
>
>
>
>___
>macports-users mailing list
>macports-users@lists.macosforge.org
>https://lists.macosforge.org/mailman/listinfo/macports-users


--Adam___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails trying to synch with openmodelica (!)

[Brandon Allbery]

On Tue, Jul 8, 2014 at 6:12 PM, Jerry  wrote:

> Synchronizing local ports tree from rsync://
> build.openmodelica.org/macports/
>

The fact that it tries this at all suggests it's listed in
/opt/local/etc/macports/sources.conf or in the equivalent file under
~/.macports (whose exact name I'm not sure of).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

selfupdate fails trying to synch with openmodelica (!)

[Jerry]

OS 10.9.4
MacPorts 2.3.1

I have run into this problem in connection to attempts to install qtiplot 
https://trac.macports.org/ticket/44252 but is surely unrelated.

I just did selfupdate and got weird problem with openmodelica which isn't even 
an available port. Terminal session is pasted below.

I run selfupdate from time to time and haven't had this problem. I ran 
selfupdate yesterday without a problem. I'm flabbergasted.

More than two years ago I tried to install OpenModelica from probably 
openmodelica.org. The installer was a macports-based standalone deal and had 
lots of problems. I finally abandoned it and removed all traces of it. (It 
installed into /opt/openmodelica and there was a weird problem with a launch 
agent relating to org.freedesktop.dbus-session.plist.) I haven't had anything 
to do with it since.

I have upgraded my OS once and probably twice since then. I have re-installed 
MacPorts from scratch about two months ago after upgrading to Mavericks. Like I 
said, I've run selfupdate a number of times, even recently, with no problems.

I have Wolfram SystmModeler which is a version of OpenModelica with hooks into 
Mathematica. I rarely use it and haven't even launched it in months. 
Mathematica was running when I ran the problematic selfupdate today, but not 
SystemModeler. I'm only mentioning this because like I said I can't see any 
explanation at all. As far as I know the Wolfram product has nothing to do with 
MacPorts.

The following folders are present in my MacPorts tree, discovered using Path 
Finder. I don't know why. The first folder contains about 131 kB. There is 
nothing related to openmodelica in response to port installed.

/opt/local/var/macports/sources/build.openmodelica.org
/opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelica
/opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelica-devel
/opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelica-release
/opt/local/var/macports/sources/build.openmodelica.org/macports/lang/openmodelicalibraries



== Pasted terminal session ===

MBPro:~ me$ sudo port -v selfupdate
--->  Updating MacPorts base sources using rsync
receiving file list ... done

sent 36 bytes  received 69 bytes  70.00 bytes/sec
total size is 27002880  speedup is 257170.29
receiving file list ... done

sent 36 bytes  received 76 bytes  74.67 bytes/sec
total size is 512  speedup is 4.57
MacPorts base version 2.3.1 installed,
MacPorts base version 2.3.1 downloaded.
--->  Updating the ports tree
Synchronizing local ports tree from 
rsync://rsync.macports.org/release/tarballs/ports.tar
receiving file list ... done

sent 36 bytes  received 70 bytes  70.67 bytes/sec
total size is 60876800  speedup is 574309.43
receiving file list ... done

sent 36 bytes  received 77 bytes  75.33 bytes/sec
total size is 512  speedup is 4.53
Creating port index in 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports

Total number of ports parsed:   0 
Ports successfully parsed:  0 
Ports failed:   0 
Up-to-date ports skipped:   18743

Synchronizing local ports tree from rsync://build.openmodelica.org/macports/
rsync: failed to connect to build.openmodelica.org: Operation timed out (60)
rsync error: error in socket IO (code 10) at 
/SourceCache/rsync/rsync-42/rsync/clientserver.c(105) [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzv --delete-after '--exclude=/PortIndex*' 
rsync://build.openmodelica.org/macports/ 
/opt/local/var/macports/sources/build.openmodelica.org/macports
Exit code: 10
Error: Synchronization of the local ports tree failed doing rsync
Error: Couldn't sync the ports tree: Synchronization of 1 source(s) failed
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
tree: Synchronization of 1 source(s) failed
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails: ghc & gcc47

[Ryan Schmidt]

On Mar 25, 2013, at 09:38, Phil Dobbin wrote:

> Running selfupdate results in:
> 
> 'Configuring zip-archive-0.1.3.4...
> Setup: At least the following dependencies are missing:
> mtl -any
> Command failed:  cd
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_hs-zip-archive/hs-zip-archive/work/zip-archive-0.1.3.4"
> && runhaskell Setup configure --prefix=/opt/local
> --with-compiler=/opt/local/bin/ghc -v --enable-library-profiling
> --with-gcc=/usr/bin/gcc-4.2
> Exit code: 1'

I'm confused about this. "sudo port selfupdate" should only be updating 
MacPorts base and your set of port definitions. It should not be trying to 
update or install any ports.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails: ghc & gcc47

[Phil Dobbin]

On 25/03/2013 15:13, Brandon Allbery wrote:

> On Mon, Mar 25, 2013 at 11:03 AM, Phil Dobbin  > wrote:
> 
> It's not installed. Neither are half a dozen other ports it keeps
> trying to install which finally culminates in ghc (sorry for the
> ugly looking reply; I'm using the abomination that is Google's Gmail
> interface).
> 
> 
> Then I would wonder what you have installed via macports that requires
> it. There isn't a whole lot in the way of end-user ports that actually
> depend on haskell; only pandoc comes to mind offhand. (And xmonad, but
> that wouldn't pull in an archiver, whereas pandoc's deps likely do.)


Good call, Brandon: it was pandoc. I removed it & all's well. Job's a
good 'un. Thanks.

Cheers,

  Phil...


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails: ghc & gcc47

[Brandon Allbery]

On Mon, Mar 25, 2013 at 11:03 AM, Phil Dobbin  wrote:

> It's not installed. Neither are half a dozen other ports it keeps trying
> to install which finally culminates in ghc (sorry for the ugly looking
> reply; I'm using the abomination that is Google's Gmail interface).
>

Then I would wonder what you have installed via macports that requires it.
There isn't a whole lot in the way of end-user ports that actually depend
on haskell; only pandoc comes to mind offhand. (And xmonad, but that
wouldn't pull in an archiver, whereas pandoc's deps likely do.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails: ghc & gcc47

[Phil Dobbin]

It's not installed. Neither are half a dozen other ports it keeps trying to
install which finally culminates in ghc (sorry for the ugly looking reply;
I'm using the abomination that is Google's Gmail interface).

Cheers,

  Phil...


On 25 March 2013 14:41, Brandon Allbery  wrote:

> On Mon, Mar 25, 2013 at 10:38 AM, Phil Dobbin wrote:
>
>> 'Configuring zip-archive-0.1.3.4...
>>
>
> Why do you have this port installed? If you removed ghc, perhaps you
> should remove ports that require and are likely only usable by ghc.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails: ghc & gcc47

[Brandon Allbery]

On Mon, Mar 25, 2013 at 10:38 AM, Phil Dobbin  wrote:

> 'Configuring zip-archive-0.1.3.4...
>

Why do you have this port installed? If you removed ghc, perhaps you should
remove ports that require and are likely only usable by ghc.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

selfupdate fails: ghc & gcc47

[Phil Dobbin]

Hi.

Running selfupdate results in:

'Configuring zip-archive-0.1.3.4...
Setup: At least the following dependencies are missing:
mtl -any
Command failed:  cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_hs-zip-archive/hs-zip-archive/work/zip-archive-0.1.3.4"
&& runhaskell Setup configure --prefix=/opt/local
--with-compiler=/opt/local/bin/ghc -v --enable-library-profiling
--with-gcc=/usr/bin/gcc-4.2
Exit code: 1'

Now I used to have ghc (haskell & haddock) installed but no longer do
but selfupdate keeps trying to install it on every upgrade & I'm getting
this error.

One other thing that is different also is that selfupdate installed
gcc47 when first running upgrade when before I only ever had Apple's
ancient version in /usr/bin.

I've tried to troubleshoot this but can't get past its insistence on
installing ghc (I take it by the look of the error message it doesn't
like /usr/bin/gcc-4.2).

Any quick fix for this would be appreciated. I have no use for ghc
unless MacPorts requires it.

Cheers,

  Phil...
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Mar 7, 2013, at 17:44, LuKreme wrote:
> In our previous episode (Thursday, 07-Mar-2013), Ryan Schmidt said:
>> On Mar 7, 2013, at 13:01, LuKreme wrote:
>> 
>>> configure:3339: /usr/bin/cc --version >&5
>>> ./configure: line 3341: /usr/bin/cc: No such file or directory
>> 
>> Please install the Xcode command line tools.
>> 
>> http://guide.macports.org/#installing.xcode.lion.43
> 
> That is peculiar. I've had ports installed and I have quite a few ports which 
> couldn't have been installed without the Xcode command line tools.
> 
> # port list installed

"port list" doesn't do what you think it does:

https://trac.macports.org/wiki/FAQ#portlist


> I wonder what happened.

I don't know. Did you install the Xcode command line tools? Does /usr/bin/cc 
now exist? Does selfupdate now work?


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[LuKreme]

In our previous episode (Thursday, 07-Mar-2013), Ryan Schmidt said:
> On Mar 7, 2013, at 13:01, LuKreme wrote:
> 
>> configure:3339: /usr/bin/cc --version >&5
>> ./configure: line 3341: /usr/bin/cc: No such file or directory
> 
> Please install the Xcode command line tools.
> 
> http://guide.macports.org/#installing.xcode.lion.43

That is peculiar. I've had ports installed and I have quite a few ports which 
couldn't have been installed without the Xcode command line tools.

# port list installed
bzip2  @1.0.6  archivers/bzip2
coreutils  @8.21   sysutils/coreutils
coreutils  @8.21   sysutils/coreutils
coreutils  @8.21   sysutils/coreutils
expat  @2.1.0  textproc/expat
findutils  @4.4.2  sysutils/findutils
gdbm   @1.10   databases/gdbm
gdbm   @1.10   databases/gdbm
gettext@0.18.2.1   devel/gettext
gmp@5.0.5  devel/gmp
gmp@5.0.5  devel/gmp
gmp@5.0.5  devel/gmp
libedit@20121213-3.0   devel/libedit
libiconv   @1.14   textproc/libiconv
libpng @1.5.14 graphics/libpng
libpng @1.5.14 graphics/libpng
ncurses@5.9devel/ncurses
openssl@1.0.1e devel/openssl
p5.12-lchown   @1.10.0 perl/p5-lchown
p5.12-lchown   @1.10.0 perl/p5-lchown
pcre   @8.32   devel/pcre
pcre   @8.32   devel/pcre
perl5.12   @5.12.4 lang/perl5.12
perl5.12   @5.12.4 lang/perl5.12
popt   @1.16   devel/popt
rsnapshot  @1.3.1  sysutils/rsnapshot
rsync  @3.0.9  net/rsync
rsync  @3.0.9  net/rsync
rsync  @3.0.9  net/rsync
slang2 @2.2.4  lang/slang2
slang2 @2.2.4  lang/slang2
slrn-devel @1.0.0pre18 news/slrn-devel
uudeview   @0.5.20 mail/uudeview
zlib   @1.2.7  archivers/zlib

I wonder what happened.


-- 
'Life's like a beach. And then you die.' --Small Gods

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Mar 7, 2013, at 13:01, LuKreme wrote:

> configure:3339: /usr/bin/cc --version >&5
> ./configure: line 3341: /usr/bin/cc: No such file or directory

Please install the Xcode command line tools.

http://guide.macports.org/#installing.xcode.lion.43

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[LuKreme]

In our previous episode (Wednesday, 06-Mar-2013), Ryan Schmidt said:
> 
> On Mar 6, 2013, at 14:24, LuKreme  wrote:
> 
>> configure: error: in 
>> `/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
> 
> Please show us what's in this config.log file.

I think I may know why this is happening. I forgot this specific machine is not 
running 10.8.2. *cough*.


>>>END
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by MacPorts configure 2.1.3, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl 
--with-install-user=root --with-install-group=admin --with-directory-mode=0755 
--enable-readline

## - ##
## Platform. ##
## - ##

hostname = www.kreme.com
uname -m = x86_64
uname -r = 12.2.1
uname -s = Darwin
uname -v = Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; 
root:xnu-2050.20.9~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = Mach kernel version:
 Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; 
root:xnu-2050.20.9~1/RELEASE_X86_64
Kernel configured for up to 8 processors.
4 processors are physically available.
8 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1 2 3 4 5 6 7
Primary memory available: 16.00 gigabytes
Default processor set: 241 tasks, 1160 threads, 8 processors
Load average: 1.05, Mach factor: 6.93
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin


## --- ##
## Core tests. ##
## --- ##

configure:2680: checking build system type
configure:2694: result: i386-apple-darwin12.2.1
configure:2714: checking host system type
configure:2727: result: i386-apple-darwin12.2.1
configure:2747: checking target system type
configure:2760: result: i386-apple-darwin12.2.1
configure:2788: checking MacPorts version
configure:2791: result: 2.1.3
configure:2824: checking for sw_vers
configure:2842: found /usr/bin/sw_vers
configure:2854: result: /usr/bin/sw_vers
configure:2864: checking for defaults
configure:2882: found /usr/bin/defaults
configure:2894: result: /usr/bin/defaults
configure:2904: checking for xcode-select
configure:2922: found /usr/bin/xcode-select
configure:2934: result: /usr/bin/xcode-select
configure:2944: checking Mac OS X version
configure:2947: result: 10.8.2
configure:2970: checking Xcode location
configure:2981: result: /Applications/Xcode.app/Contents/Developer
configure:2995: checking Xcode version
configure:3002: result: 4.6
configure:3074: checking for gcc
configure:3101: result: /usr/bin/cc
configure:3330: checking for C compiler version
configure:3339: /usr/bin/cc --version >&5
./configure: line 3341: /usr/bin/cc: No such file or directory
configure:3350: $? = 127
configure:3339: /usr/bin/cc -v >&5
./configure: line 3341: /usr/bin/cc: No such file or directory
configure:3350: $? = 127
configure:3339: /usr/bin/cc -V >&5
./configure: line 3341: /usr/bin/cc: No such file or directory
configure:3350: $? = 127
configure:3339: /usr/bin/cc -qversion >&5
./configure: line 3341: /usr/bin/cc: No such file or directory
configure:3350: $? = 127
configure:3370: checking whether the C compiler works
configure:3392: /usr/bin/ccconftest.c  >&5
./configure: line 3394: /usr/bin/cc: No such file or directory
configure:3396: $? = 127
configure:3434: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "MacPorts"
| #define PACKAGE_TARNAME "macports"
| #define PACKAGE_VERSION "2.1.3"
| #define PACKAGE_STRING "MacPorts 2.1.3"
| #define PACKAGE_BUGREPORT "macports-...@lists.macosforge.org"
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3439: error: in 
`/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base':
configure:3441: error: C compiler cannot create executables
See `config.log' for more details

##  ##
## Cache variables. ##
##  ##

ac_cv_build=i386-apple-darwin12.2.1
ac_cv_env_BSDMAKE_set=
ac_cv_env_BSDMAKE_value=
ac_cv_env_BZIP2_set=
ac_cv_env_BZIP2_value=
ac_cv_env_CC_set=set
ac_cv_env_CC_value=/usr/bin/cc
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CVS_set=
ac_cv_env_CVS_value=
ac_cv_env_GNUMAKE_set=
ac_cv_env_GNUMAKE_value=
ac_cv_env_GNUTAR_set=
ac_cv_env_GNUTAR_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_en

Re: selfupdate fails

[Chris Murphy]

On Mar 6, 2013, at 1:24 PM, LuKreme  wrote:
>>> 
>>> Darwin www.kreme.com 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 
>>> 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64

> checking build system type... i386-apple-darwin12.2.1
> checking host system type... i386-apple-darwin12.2.1
> checking target system type… i386-apple-darwin12.2.1

I find it confusing that the build/host/target system is x86_64 yet there are 
messages indicating otherwise.

Chris Murphy
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Mar 6, 2013, at 14:24, LuKreme  wrote:

> configure: error: in 
> `/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base':
> configure: error: C compiler cannot create executables
> See `config.log' for more details

Please show us what's in this config.log file.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[LuKreme]

In our previous episode (Wednesday, 06-Mar-2013), Ryan Schmidt said:
> On Mar 6, 2013, at 13:21, LuKreme wrote:
> 
>> # port selfupdate
>> --->  Updating MacPorts base sources using rsync
>> MacPorts base version 2.1.2 installed,
>> MacPorts base version 2.1.3 downloaded.
>> --->  Updating the ports tree
>> --->  MacPorts base is outdated, installing new version 2.1.3
>> Installing new MacPorts release in /opt/local as root:admin; permissions 
>> 0755; Tcl-Package in /Library/Tcl
>> 
>> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
>> MacPorts base: command execution failed
>> 
>> # uname -a
>> Darwin www.kreme.com 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 
>> 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64
> 
> Please try again with the -d flag so we can see what went wrong.
> 
> sudo port -d selfupdate


after several minutes:
...
sent 64 bytes  received 636 bytes  466.67 bytes/sec
total size is 512  speedup is 0.73
DEBUG: successful verification with key 
/opt/local/share/macports/macports-pubkey.pem
DEBUG: /usr/bin/tar -C 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/tmp -xf 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports.tar
DEBUG: /usr/bin/rsync -rtzv --delete-after 
rsync://rsync.macports.org/release/tarballs/PortIndex_darwin_12_i386/PortIndex 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs
receiving file list ... done
PortIndex

sent 18406 bytes  received 2162 bytes  13712.00 bytes/sec
total size is 9344535  speedup is 454.32
DEBUG: /usr/bin/rsync -rtzv --delete-after 
rsync://rsync.macports.org/release/tarballs/PortIndex_darwin_12_i386/PortIndex.rmd160
 /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
receiving file list ... done
PortIndex.rmd160

sent 64 bytes  received 636 bytes  466.67 bytes/sec
total size is 512  speedup is 0.73
DEBUG: successful verification with key 
/opt/local/share/macports/macports-pubkey.pem
--->  MacPorts base is outdated, installing new version 2.1.3
DEBUG: Permissions OK

Installing new MacPorts release in /opt/local as root:admin; permissions 0755; 
Tcl-Package in /Library/Tcl

checking build system type... i386-apple-darwin12.2.1
checking host system type... i386-apple-darwin12.2.1
checking target system type... i386-apple-darwin12.2.1
checking MacPorts version... 2.1.3
checking for sw_vers... /usr/bin/sw_vers
checking for defaults... /usr/bin/defaults
checking for xcode-select... /usr/bin/xcode-select
checking Mac OS X version... 10.8.2
checking Xcode location... /Applications/Xcode.app/Contents/Developer
checking Xcode version... 4.6
checking for gcc... /usr/bin/cc
checking whether the C compiler works... no
configure: error: in 
`/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base':
configure: error: C compiler cannot create executables
See `config.log' for more details
Command failed: cd 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base && 
CC=/usr/bin/cc ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl 
--with-install-user=root --with-install-group=admin --with-directory-mode=0755 
--enable-readline && make && make install SELFUPDATING=1
Exit code: 77
DEBUG: Error installing new MacPorts base: command execution failed
while executing
"macports::selfupdate [array get global_options] base_updated"
Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
MacPorts base: command execution failed

-- 
If you think that Mick Jagger will still be doing the whole rock star
thing at age fifty, well, then, you are sorely, sorely mistaken.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Mar 6, 2013, at 13:21, LuKreme wrote:

> # port selfupdate
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.1.2 installed,
> MacPorts base version 2.1.3 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is outdated, installing new version 2.1.3
> Installing new MacPorts release in /opt/local as root:admin; permissions 
> 0755; Tcl-Package in /Library/Tcl
> 
> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
> MacPorts base: command execution failed
> 
> # uname -a
> Darwin www.kreme.com 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 
> PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64

Please try again with the -d flag so we can see what went wrong.

sudo port -d selfupdate


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

selfupdate fails

[LuKreme]

# port selfupdate
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.1.2 installed,
MacPorts base version 2.1.3 downloaded.
--->  Updating the ports tree
--->  MacPorts base is outdated, installing new version 2.1.3
Installing new MacPorts release in /opt/local as root:admin; permissions 0755; 
Tcl-Package in /Library/Tcl

Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
MacPorts base: command execution failed

# uname -a
Darwin www.kreme.com 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 
PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64


-- 
ALL WORK AND NO PLAY MAKES BART A DULL BOY ALL WORK AND NO PLAY MAKES
BART A DULL BOY ALL WORK AND NO PLAY MAKES BART A DULL BOY Bart
chalkboard Ep. 1F07

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Re: MacPorts selfupdate fails& cannot write to location

[Joshua Root]

On 28164-7-23 05:59 , William H. Magill wrote:
> I have no problem simply wiping Mac Ports and sting over but upgrading from 
> Snow Leopard (where I had last run Mac Ports 1.9) to Lion and attempting to 
> upgrade to MacPorts 2.x "should work."

Another thing: Note that the Migration instructions actually say to use
the installer, not to selfupdate. If you go from 10.5 to 10.6 for
example, the existing version will most likely not be able to run
because an i386/ppc MacPorts.dylib cannot be loaded into an x86_64 tclsh.

Selfupdate probably does work OK going from 10.6 to 10.7, and I'm not
sure if installing the .pkg resets the ownership on the directories
(which would solve your problem if it does). But anyway, that's what the
Migration wiki page says, and there are good reasons for it.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Re: MacPorts selfupdate fails& cannot write to location

[Joshua Root]

On 28164-7-23 05:59 , William H. Magill wrote:
> Returning to a problem I was having earlier before "life" interrupted ?.and 
> am still having.
> 
> I realize that the registry.db file does not exist. What I don't understand 
> is the "couldn't write to this location" part of the error.

It's a bug (fixed in svn). It's looking at the permissions on the
registry dir, sees that it is not the owner, and the group and world
writable bits are not set, so it concludes that it cannot write to that
directory.

> I have no problem simply wiping Mac Ports and sting over but upgrading from 
> Snow Leopard (where I had last run Mac Ports 1.9) to Lion and attempting to 
> upgrade to MacPorts 2.x "should work."
> I also realize that the flat registry is/was gone because of a previous 
> failed "self update"? but why can't it write?

What makes you say the flat registry is gone? Is there nothing in
/opt/local/var/macports/receipts?

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts selfupdate fails… cannot write to location

[William H. Magill]

On Sep 14, 2011, at 12:38 PM, Ryan Schmidt wrote:

> On Sep 13, 2011, at 21:49, William H. Magill wrote:
>> This is very weird… True… registry.db does not exist… no idea why unless the 
>> previous "selfupdate" attempt deleted it.
>>  False… both my userid and root (sudo) can 
>> write to the directory.
>> ---
>> outpost> sudo port -v selfupdate
>> Password:
>> port registry doesn't exist at 
>> "/opt/local/var/macports/registry/registry.db" and couldn't write to this 
>> location
> 
> [snip]
> 
>> Note: last activity had been 8 July when I successfully installed iStumbler.
> 
> July 8 predates MacPorts 2, unless you were running a beta version of it.
> 
> MacPorts 1 by default used a flat registry, not the new SQLite registry 
> mandated by MacPorts 2.
> 
> When upgrading to MacPorts 2, it's supposed to detect if you're using the 
> flat registry, and convert it to the new SQLite registry.
> 
> It looks like that conversion didn't happen in your case, or at least, didn't 
> happen completely. Or maybe you thought selfupdate was taking too long and 
> you interrupted it? The conversion can take hours depending on how many ports 
> you have installed and how fast your computer is.
> 
> In that case, hopefully MacPorts hasn't removed the previous flat registry 
> information, and it should be possible to "reset" MacPorts so that it tries 
> the conversion again. But I forget how to make it do that.

Returning to a problem I was having earlier before "life" interrupted ….and am 
still having.

I realize that the registry.db file does not exist. What I don't understand is 
the "couldn't write to this location" part of the error.

I have no problem simply wiping Mac Ports and sting over but upgrading from 
Snow Leopard (where I had last run Mac Ports 1.9) to Lion and attempting to 
upgrade to MacPorts 2.x "should work."
I also realize that the flat registry is/was gone because of a previous failed 
"self update"… but why can't it write?


outpost> sudo port -vd selfupdate
port registry doesn't exist at "/opt/local/var/macports/registry/registry.db" 
and couldn't write to this location
while executing
"registry::open $db_path"
(procedure "mportinit" line 551)
invoked from within
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, port registry 
doesn't exist at "/opt/local/var/macports/registry/registry.db" and couldn't 
write to this location


outpost> ls -alse /opt
total 0
0 drwxr-xr-x@  3 magill  admin   102 Aug 27  2009 .
0 drwxr-xr-x@ 32 rootwheel  1156 Aug 17 21:49 ..
0 drwxr-xr-x  13 magill  admin   442 Sep 12 13:45 local
[/Users/magill] magill 
 outpost> ls -alse /opt/local
total 4
0 drwxr-xr-x  13 magill  admin   442 Sep 12 13:45 .
0 drwxr-xr-x@  3 magill  admin   102 Aug 27  2009 ..
0 drwxr-xr-x  28 magill  admin   952 Sep 12 13:45 bin
0 drwxr-xr-x   3 magill  admin   102 Aug 27  2009 etc
0 drwxr-xr-x  23 magill  admin   782 Jun 15 01:37 include
0 drwxr-xr-x  31 magill  admin  1054 Sep 12 13:45 lib
0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 libexec
4 lrwxr-xr-x   1 rootadmin 9 Sep 12 13:45 man -> share/man
0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 sbin
0 drwxr-xr-x   7 magill  admin   238 Sep 12 13:45 share
0 drwxr-xr-x   2 magill  admin68 Sep 12 13:45 src
0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 var
0 drwxr-xr-x   2 magill  admin68 Sep 12 13:45 www
[/Users/magill] magill 
 outpost> ls -alse /opt/local/var
total 0
0 drwxr-xr-x   3 magill  admin  102 Nov  7  2010 .
0 drwxr-xr-x  13 magill  admin  442 Sep 12 13:45 ..
0 drwxr-xr-x  12 magill  admin  408 Sep 12 13:45 macports
[/Users/magill] magill 
 outpost> ls -alse /opt/local/var/macports
total 16
 0 drwxr-xr-x  12 magill  admin   408 Sep 12 13:45 .
 0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 ..
 4 -rw-r--r--   1 rootadmin13 Sep 12 13:45 .tclpackage
 0 drwxr-xr-x   3 magill  admin   102 Jul  8 14:03 build
 0 drwxr-xr-x   4 magill  admin   136 Jul  8 14:03 distfiles
 0 drwxr-xr-x   2 magill  admin68 Jul  8 14:03 logs
 0 drwxr-xr-x   3 rootadmin   102 Nov  7  2010 packages
12 -r--r--r--   1 magill  admin  9851 Sep 12 13:45 port-help.tcl
 0 drwxr-xr-x   6 rootadmin   204 Jul  8 14:03 receipts
 0 drwxr-xr-x   4 magill  admin   136 Sep 13 22:39 registry
 0 drwxr-xr-x   3 magill  admin   102 Jul  8 14:03 software
 0 drwxr-xr-x   3 rootadmin   102 Jun 15 01:37 sources
[/Users/magill] magill 
 outpost> ls -alse /opt/local/var/macports/registry
total 0
0 drwxr-xr-x   4 magill  admin  136 Sep 13 22:39 .
0 drwxr-xr-x  12 magill  admin  408 Sep 12 13:45 ..
0 -rw-r--r--   1 rootadmin0 Jul  8 14:03 .registry.lock
0 -rw-rw-r--   1 rootadmin0 Nov  7  2010 .turd_MacPorts
[/Users/magill] magill 



T.T.F.N.
William H. Magill
# iMac11,3 Core i7 [2.936GHz

Re: MacPorts selfupdate fails… v 1.9.2 to 2.0.3 w Xcode 4.1 - OSX 10.7.1

[Ryan Schmidt]

On Sep 13, 2011, at 21:49, William H. Magill wrote:
> This is very weird… True… registry.db does not exist… no idea why unless the 
> previous "selfupdate" attempt deleted it.
>   False… both my userid and root (sudo) can 
> write to the directory.
> ---
> outpost> sudo port -v selfupdate
> Password:
> port registry doesn't exist at "/opt/local/var/macports/registry/registry.db" 
> and couldn't write to this location

[snip]

> Note: last activity had been 8 July when I successfully installed iStumbler.

July 8 predates MacPorts 2, unless you were running a beta version of it.

MacPorts 1 by default used a flat registry, not the new SQLite registry 
mandated by MacPorts 2.

When upgrading to MacPorts 2, it's supposed to detect if you're using the flat 
registry, and convert it to the new SQLite registry.

It looks like that conversion didn't happen in your case, or at least, didn't 
happen completely. Or maybe you thought selfupdate was taking too long and you 
interrupted it? The conversion can take hours depending on how many ports you 
have installed and how fast your computer is.

In that case, hopefully MacPorts hasn't removed the previous flat registry 
information, and it should be possible to "reset" MacPorts so that it tries the 
conversion again. But I forget how to make it do that.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts selfupdate fails… v 1.9.2 to 2.0.3 w Xcode 4.1 - OSX 10.7.1

[William H. Magill]

On Sep 12, 2011, at 8:36 PM, Ryan Schmidt wrote:
> On Sep 12, 2011, at 14:54, William H. Magill wrote:
> 
>> ==
>> # 27 inch iMac Intel (mid 2010) - 27 inch diagonal screen - Acquired 6/2011
>> Model
>> Processor 2.93 GHz Intel Core i7
>> Memory  4 GB 1333 MHz DDR3
>> Graphics  ATI Radeon HD 5750 1024 MB
>> Display   27-inch (2560 x 1440)
>> Software  Mac OS X Lion 10.7.1 (11B26)
>> ==
>> After failing to "selfupdate" under Xcode 4.0.2, I updated Xcode to 4.1 from 
>> the App Store, I got the same error as before (below), however the log file 
>> (below) as several different errors in it.
>> 
>> I also note that, other than what appear to be "normal" config failures, no 
>> errors are reported.
>> 
>> 
>> outpost> sudo port selfupdate
>> Password:
>> --->  Updating the ports tree
>> --->  Updating MacPorts base sources using rsync
>> MacPorts base version 1.9.2 installed,
>> MacPorts base version 2.0.3 downloaded.
>> --->  MacPorts base is outdated, installing new version 2.0.3
>> Installing new MacPorts release in /opt/local as magill:admin; permissions 
>> 0755; Tcl-Package in /Library/Tcl
>> 
>> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
>> MacPorts base: shell command failed (see log for details)
>> [/opt/local] magill 
>> 
>> -
>> outpost> ls -als  
>> ./var/macports/sources/rsync.macports.org/release/base/config.log
>> 60 -rw-r--r--  1 root  admin  58749 Sep 12 13:45 
>> ./var/macports/sources/rsync.macports.org/release/base/config.log
>> 
>> outpost> more  
>> ./var/macports/sources/rsync.macports.org/release/base/config.log
>> This file contains any messages produced by compilers while
>> running configure, to aid debugging if configure makes a mistake.
> 
> 
> [snip]
> 
> Right, the config.log only tells you about what happened during the configure 
> phase, which appears to have completed just fine. Presumably an error is 
> happening in a later phase, like the build phase. Re-run selfupdate with the 
> verbose flag to see what's happening.
> 
> sudo port -v selfupdate

This is very weird… True… registry.db does not exist… no idea why unless the 
previous "selfupdate" attempt deleted it.
   False… both my userid and root (sudo) can 
write to the directory.
---
 outpost> sudo port -v selfupdate
Password:
port registry doesn't exist at "/opt/local/var/macports/registry/registry.db" 
and couldn't write to this location
while executing
"registry::open $db_path"
(procedure "mportinit" line 551)
invoked from within
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, port registry 
doesn't exist at "/opt/local/var/macports/registry/registry.db" and couldn't 
write to this location
[/Users/magill] magill 


outpost> ls -alse /opt
total 0
0 drwxr-xr-x@  3 magill  admin   102 Aug 27  2009 .
0 drwxr-xr-x@ 32 rootwheel  1156 Aug 17 21:49 ..
0 drwxr-xr-x  13 magill  admin   442 Sep 12 13:45 local
[/opt/local/var/macports] magill 
 outpost> ls -alse /opt/local
total 4
0 drwxr-xr-x  13 magill  admin   442 Sep 12 13:45 .
0 drwxr-xr-x@  3 magill  admin   102 Aug 27  2009 ..
0 drwxr-xr-x  28 magill  admin   952 Sep 12 13:45 bin
0 drwxr-xr-x   3 magill  admin   102 Aug 27  2009 etc
0 drwxr-xr-x  23 magill  admin   782 Jun 15 01:37 include
0 drwxr-xr-x  31 magill  admin  1054 Sep 12 13:45 lib
0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 libexec
4 lrwxr-xr-x   1 rootadmin 9 Sep 12 13:45 man -> share/man
0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 sbin
0 drwxr-xr-x   7 magill  admin   238 Sep 12 13:45 share
0 drwxr-xr-x   2 magill  admin68 Sep 12 13:45 src
0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 var
0 drwxr-xr-x   2 magill  admin68 Sep 12 13:45 www
[/opt/local/var/macports] magill 
 outpost> ls -alse /opt/local/var/   
total 0
0 drwxr-xr-x   3 magill  admin  102 Nov  7  2010 .
0 drwxr-xr-x  13 magill  admin  442 Sep 12 13:45 ..
0 drwxr-xr-x  12 magill  admin  408 Sep 12 13:45 macports
[/opt/local/var/macports] magill 
 outpost> ls -alse /opt/local/var/macports
total 16
 0 drwxr-xr-x  12 magill  admin   408 Sep 12 13:45 .
 0 drwxr-xr-x   3 magill  admin   102 Nov  7  2010 ..
 4 -rw-r--r--   1 rootadmin13 Sep 12 13:45 .tclpackage
 0 drwxr-xr-x   3 magill  admin   102 Jul  8 14:03 build
 0 drwxr-xr-x   4 magill  admin   136 Jul  8 14:03 distfiles
 0 drwxr-xr-x   2 magill  admin68 Jul  8 14:03 logs
 0 drwxr-xr-x   3 rootadmin   102 Nov  7  2010 packages
12 -r--r--r--   1 magill  admin  9851 Sep 12 13:45 port-help.tcl
 0 drwxr-xr-x   6 rootadmin   204 Jul  8 14:03 receipts
 0 drwxr-xr-x   4 magill  admin   136 Sep 13 22:39 registry
 0 drwxr-xr-x   3 magill  admin   102 Jul  8 14:03 software

Re: FYI - MacPorts selfupdate fails… v 1.9.2 to 2.0.3 .. no log file produced (in an obvious place) w Xcode 4.0.2 - OSX 10.7.1

[Scott Webster]

On Mon, Sep 12, 2011 at 5:33 PM, Ryan Schmidt  wrote:
> On Sep 12, 2011, at 14:52, William H. Magill wrote:
>
>> Note: this particular error happened before I realized I did not upgrade 
>> Xcode on this machine…. was Xcode 4.0.2 -- OSX 10.7.1. (However, it failed 
>> again after updating to Xcode 4.1.)
>> This posting is simply "for the record" -- that the message needs to be 
>> expanded :).
>
> "the message": you mean the message "see log for details"? That's a generic 
> error printed any time any shell command files, so it can't be more specific. 
> We could print an additional message with the log location; we do that for 
> port installs already.

Printing the location would be nice.  I have tried and failed to find
such a log in the past.  Perhaps it really does not exist, or it ends
up being deleted somehow at the end of the selfupdate process.

Scott
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: MacPorts selfupdate fails… v 1.9.2 to 2.0.3 w Xcode 4.1 - OSX 10.7.1

[Ryan Schmidt]

On Sep 12, 2011, at 14:54, William H. Magill wrote:

> ==
> # 27 inch iMac Intel (mid 2010) - 27 inch diagonal screen - Acquired 6/2011
> Model
> Processor 2.93 GHz Intel Core i7
> Memory  4 GB 1333 MHz DDR3
> Graphics  ATI Radeon HD 5750 1024 MB
> Display   27-inch (2560 x 1440)
> Software  Mac OS X Lion 10.7.1 (11B26)
> ==
> After failing to "selfupdate" under Xcode 4.0.2, I updated Xcode to 4.1 from 
> the App Store, I got the same error as before (below), however the log file 
> (below) as several different errors in it.
> 
> I also note that, other than what appear to be "normal" config failures, no 
> errors are reported.
> 
> 
> outpost> sudo port selfupdate
> Password:
> --->  Updating the ports tree
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 1.9.2 installed,
> MacPorts base version 2.0.3 downloaded.
> --->  MacPorts base is outdated, installing new version 2.0.3
> Installing new MacPorts release in /opt/local as magill:admin; permissions 
> 0755; Tcl-Package in /Library/Tcl
> 
> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
> MacPorts base: shell command failed (see log for details)
> [/opt/local] magill 
> 
> -
> outpost> ls -als  
> ./var/macports/sources/rsync.macports.org/release/base/config.log
> 60 -rw-r--r--  1 root  admin  58749 Sep 12 13:45 
> ./var/macports/sources/rsync.macports.org/release/base/config.log
> 
> outpost> more  
> ./var/macports/sources/rsync.macports.org/release/base/config.log
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.


[snip]

Right, the config.log only tells you about what happened during the configure 
phase, which appears to have completed just fine. Presumably an error is 
happening in a later phase, like the build phase. Re-run selfupdate with the 
verbose flag to see what's happening.

sudo port -v selfupdate


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: FYI - MacPorts selfupdate fails… v 1.9.2 to 2.0.3 .. no log file produced (in an obvious place) w Xcode 4.0.2 - OSX 10.7.1

[Ryan Schmidt]

On Sep 12, 2011, at 14:52, William H. Magill wrote:

> Note: this particular error happened before I realized I did not upgrade 
> Xcode on this machine…. was Xcode 4.0.2 -- OSX 10.7.1. (However, it failed 
> again after updating to Xcode 4.1.)
> This posting is simply "for the record" -- that the message needs to be 
> expanded :).

"the message": you mean the message "see log for details"? That's a generic 
error printed any time any shell command files, so it can't be more specific. 
We could print an additional message with the log location; we do that for port 
installs already.


> outpost> sudo port selfupdate
> Password:
> Warning: port definitions are more than two weeks old, consider using 
> selfupdate
> --->  Updating the ports tree
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 1.9.2 installed,
> MacPorts base version 2.0.3 downloaded.
> --->  MacPorts base is outdated, installing new version 2.0.3
> Installing new MacPorts release in /opt/local as magill:admin; permissions 
> 0755; Tcl-Package in /Library/Tcl
> 
> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
> MacPorts base: shell command failed (see log for details)
> 
> ….. Could not find any log …. in  /opt/local or in /var/log or /library/logs
> 
> Finally found: 
>
> /opt/local/var/macports/sources/rsync.macports.org/release/base/config.log
> 
> I guess that is the log being talked about as there are no others in 
> /opt/local according to "find"… however it doesn't say anything other than to 
> look for the errors in the ?same? file.

I don't think that's the log we're talking about, but I don't know where a 
selfupdate log would be. We may not have one. As I said the "see log" message 
is generic, and usually occurs during port installs, where we do have a log.

You've already found that not upgrading your Xcode was the problem, but if you 
were still searching for the cause of the problem, I would have advised you to 
re-run with the verbose flag, to get more output.

sudo port -v selfupdate


I'm actually surprised that our MacPorts configure script doesn't check for 
incompatible Xcode versions. All we check is:

case "$XCODE_VERSION" in
  1.*|2.[[0-1]]*)
AC_MSG_WARN([This version of Xcode Tools is not supported])
AC_MSG_WARN([Please upgrade at http://connect.apple.com/])
;;
  2.[[2-3]]*|3.[[0]]*)
AC_MSG_WARN([This version of Xcode Tools is out of date])
AC_MSG_WARN([Please consider upgrading as some ports fail compiling])
;;
  2.*|3.*|4.*)
dnl Supported version
;;
  *)
;;
esac

That's fine as far as it goes, but I thought we were already checking for 
Xcode/OS version mismatches; I guess we're not.



> [Annoying … the Appstore  download of the lion Xcode4 update … doesn't do 
> anything. You have to launch the installer manually.]

That's correct. The people to complain to about that are Apple, not us.



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

FYI - MacPorts selfupdate fails… v 1.9.2 to 2.0.3 .. no log file produced (in an obvious place) w Xcode 4.0.2 - OSX 10.7.1

[William H. Magill]

Note: this particular error happened before I realized I did not upgrade Xcode 
on this machine…. was Xcode 4.0.2 -- OSX 10.7.1. (However, it failed again 
after updating to Xcode 4.1.)
This posting is simply "for the record" -- that the message needs to be 
expanded :).

outpost> sudo port selfupdate
Password:
Warning: port definitions are more than two weeks old, consider using selfupdate
--->  Updating the ports tree
--->  Updating MacPorts base sources using rsync
MacPorts base version 1.9.2 installed,
MacPorts base version 2.0.3 downloaded.
--->  MacPorts base is outdated, installing new version 2.0.3
Installing new MacPorts release in /opt/local as magill:admin; permissions 
0755; Tcl-Package in /Library/Tcl

Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
MacPorts base: shell command failed (see log for details)

….. Could not find any log …. in  /opt/local or in /var/log or /library/logs

Finally found: 

/opt/local/var/macports/sources/rsync.macports.org/release/base/config.log

I guess that is the log being talked about as there are no others in /opt/local 
according to "find"… however it doesn't say anything other than to look for the 
errors in the ?same? file.
[Annoying … the Appstore  download of the lion Xcode4 update … doesn't do 
anything. You have to launch the installer manually.]

outpost> 
[/opt/local] magill 
outpost> more  ./var/macports/sources/rsync.macports.org/release/base/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by MacPorts configure 2.0.3, which was
generated by GNU Autoconf 2.68.  Invocation command line was

$ ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl 
--with-install-user=magill --with-install-group=admin 
--with-directory-mode=0755 --enable-readline

## - ##
## Platform. ##
## - ##

hostname = outpostmcgillsocietyorg.local
uname -m = x86_64
uname -r = 11.1.0
uname -s = Darwin
uname -v = Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; 
root:xnu-1699.22.81~1/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = Mach kernel version:
  Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; 
root:xnu-1699.22.81~1/RELEASE_X86_64
Kernel configured for up to 8 processors.
4 processors are physically available.
8 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1 2 3 4 5 6 7
Primary memory available: 4.00 gigabytes
Default processor set: 84 tasks, 355 threads, 8 processors
Load average: 2.14, Mach factor: 5.85
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin


## --- ##
## Core tests. ##
## --- ##

configure:2655: checking build system type
configure:2669: result: i386-apple-darwin11.1.0
configure:2689: checking host system type
configure:2702: result: i386-apple-darwin11.1.0
configure:2722: checking target system type
configure:2735: result: i386-apple-darwin11.1.0
configure:2763: checking MacPorts version
configure:2766: result: 2.0.3
configure:2799: checking for sw_vers
configure:2817: found /usr/bin/sw_vers
configure:2829: result: /usr/bin/sw_vers
configure:2839: checking for defaults
configure:2857: found /usr/bin/defaults
configure:2869: result: /usr/bin/defaults
configure:2879: checking for xcode-select
configure:2912: result: no
configure:2919: checking Mac OS X version
configure:2922: result: 10.7.1
configure:2957: checking Xcode version
configure:2964: result: 4.0.2
configure:3036: checking for gcc
configure:3063: result: /usr/bin/llvm-gcc-4.2
configure:3292: checking for C compiler version
configure:3301: /usr/bin/llvm-gcc-4.2 --version >&5
./configure: line 3303: /usr/bin/llvm-gcc-4.2: No such file or directory
configure:3312: $? = 127
configure:3301: /usr/bin/llvm-gcc-4.2 -v >&5
./configure: line 3303: /usr/bin/llvm-gcc-4.2: No such file or directory
configure:3312: $? = 127
configure:3301: /usr/bin/llvm-gcc-4.2 -V >&5
./configure: line 3303: /usr/bin/llvm-gcc-4.2: No such file or directory
configure:3312: $? = 127
configure:3301: /usr/bin/llvm-gcc-4.2 -qversion >&5
./configure: line 3303: /usr/bin/llvm-gcc-4.2: No such file or directory
configure:3312: $? = 127
configure:3332: checking whether the C compiler works
configure:3354: /usr/bin/llvm-gcc-4.2conftest.c  >&5
./configure: line 3356: /usr/bin/llvm-gcc-4.2: No such file or directory
configure:3358: $? = 127
configure:3396: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "MacPorts"
| #define PACKAGE_TARNAME "macports"
| #define PACKAGE_VERSION "2.0.3"
| #define PACKAGE_STRING "MacPorts 2.0.3"
| #d

Re: sudo port selfupdate fails

[Ryan Schmidt]

On Sep 6, 2011, at 08:41, Johannes Ruscheinski wrote:

> On 5 September 2011 21:48, Ryan Schmidt wrote:
>> 
>> On Sep 5, 2011, at 23:40, Johannes Ruscheinski wrote:
>> 
>>> After doing a "sudo port uninstall mono" I still get the same error.
>>> My build still prints out:
>>> 
>>> base32cmd.o sha1cmd.o curl.o rmd160cmd.o sha256cmd.o readline.o uid.o
>>> tracelib.o tty.o readdir.o pipe.o flock.o system.o mktemp.o realpath.o
>>> -o Pextlib.dylib
>>> -L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5
>>> -lcurl  -lreadline
>>> ===> making all in src/registry2.0
>>> /usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
>>> -Wall -pedantic
>>> -I/Library/Frameworks/Mono.framework/Versions/2.2/include
>>> -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common registry.c -o
>>> registry.o
>>> In file included from ../cregistry/registry.h:35,
>>> from registry.c:39:
>>> 
>>> How can I identify the problematic port in order to uninstall it?   Thanks!
>> 
>> It is not a port. It is a standalone installation of Mono, installed by a 
>> means other than MacPorts.
> 
> Ok, so how can I remove it?

You'll have to ask them; I don't know where all it put its files. At minimum, 
remove /Library/Frameworks/Mono.framework and /usr/bin/pkgconfig.

> And why is MacPorts picking up on it?
> Something in my PATH that I need to remove?

Because they installed /usr/bin/pkgconfig pointing to their own pkgconfig. 
MacPorts and other software will query pkgconfig if present and use its results 
to determine where to find libraries. It is an error for them to have installed 
/usr/bin/pkgconfig.

Meanwhile, we hope to work around this problem in a future version of MacPorts 
by no longer querying pkgconfig, since we know Mac OS X does not come with 
pkgconfig and that we can find the libraries without it.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Rainer Müller]

On 09/06/2011 03:41 PM, Johannes Ruscheinski wrote:

Ok, so how can I remove it?  And why is MacPorts picking up on it?
Something in my PATH that I need to remove?


IIRC, Mono installs a symlink to their pkg-config in the Mono.framework 
into /usr/bin which causes these problems.


Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Johannes Ruscheinski]

On 5 September 2011 21:48, Ryan Schmidt  wrote:
>
> On Sep 5, 2011, at 23:40, Johannes Ruscheinski wrote:
>
>> Hi Ryan,
>>
>> After doing a "sudo port uninstall mono" I still get the same error.
>> My build still prints out:
>>
>> base32cmd.o sha1cmd.o curl.o rmd160cmd.o sha256cmd.o readline.o uid.o
>> tracelib.o tty.o readdir.o pipe.o flock.o system.o mktemp.o realpath.o
>> -o Pextlib.dylib
>> -L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5
>> -lcurl  -lreadline
>> ===> making all in src/registry2.0
>> /usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
>> -Wall -pedantic
>> -I/Library/Frameworks/Mono.framework/Versions/2.2/include
>> -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common registry.c -o
>> registry.o
>> In file included from ../cregistry/registry.h:35,
>>                 from registry.c:39:
>>
>> How can I identify the problematic port in order to uninstall it?   Thanks!
>
> It is not a port. It is a standalone installation of Mono, installed by a 
> means other than MacPorts.

Ok, so how can I remove it?  And why is MacPorts picking up on it?
Something in my PATH that I need to remove?

>
>



-- 
Johannes

Obligatory current favourite quotes:

"We are all atheists about most of the gods that societies have ever
believed in. Some of us just go one god further."
--Richard Dawkins

"Religion is regarded by the common people as true, by the wise as
false, and by the rulers as useful".
 -- Seneca
"I have more confidence in the methods of science, based on the amazing
record of science and its ability over the centuries to answer
unanswerable questions, than I do in the methods of faith (what are they?)."
 -- David J. Gross "Physics Nobel Laureate"

"Atheism is a religion to the same extent that not collecting stamps is a
 hobby."
 -- seen on Slashdot.org

http://xkcd.com/808/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Ryan Schmidt]

On Sep 5, 2011, at 23:40, Johannes Ruscheinski wrote:

> Hi Ryan,
> 
> After doing a "sudo port uninstall mono" I still get the same error.
> My build still prints out:
> 
> base32cmd.o sha1cmd.o curl.o rmd160cmd.o sha256cmd.o readline.o uid.o
> tracelib.o tty.o readdir.o pipe.o flock.o system.o mktemp.o realpath.o
> -o Pextlib.dylib
> -L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5
> -lcurl  -lreadline
> ===> making all in src/registry2.0
> /usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
> -Wall -pedantic
> -I/Library/Frameworks/Mono.framework/Versions/2.2/include
> -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common registry.c -o
> registry.o
> In file included from ../cregistry/registry.h:35,
> from registry.c:39:
> 
> How can I identify the problematic port in order to uninstall it?   Thanks!

It is not a port. It is a standalone installation of Mono, installed by a means 
other than MacPorts.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Johannes Ruscheinski]

Hi Ryan,

After doing a "sudo port uninstall mono" I still get the same error.
My build still prints out:

base32cmd.o sha1cmd.o curl.o rmd160cmd.o sha256cmd.o readline.o uid.o
tracelib.o tty.o readdir.o pipe.o flock.o system.o mktemp.o realpath.o
-o Pextlib.dylib
-L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5
-lcurl  -lreadline
===> making all in src/registry2.0
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic
-I/Library/Frameworks/Mono.framework/Versions/2.2/include
-DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common registry.c -o
registry.o
In file included from ../cregistry/registry.h:35,
 from registry.c:39:

How can I identify the problematic port in order to uninstall it?   Thanks!

On 5 September 2011 19:19, Ryan Schmidt  wrote:
> On Sep 5, 2011, at 21:04, Johannes Ruscheinski wrote:
>
>> The next problem that I am running into now is:
>
> [snip]
>
>> ===> making all in src/registry2.0
>> /usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
>> -Wall -pedantic
>> -I/Library/Frameworks/Mono.framework/Versions/2.2/include
>> -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common registry.c -o
>> registry.o
>> In file included from ../cregistry/registry.h:35,
>>                 from registry.c:39:
>> /Library/Frameworks/Mono.framework/Versions/2.2/include/sqlite3.h:198:
>> warning: ISO C90 does not support 'long long'
>> /Library/Frameworks/Mono.framework/Versions/2.2/include/sqlite3.h:199:
>> warning: ISO C90 does not support 'long long'
>
> [snip]
>
>> Any idea what to do about that?
>
> This is this problem:
>
> https://trac.macports.org/ticket/30932
>
> Delete your Mono framework. It is broken (as in, it is designed to cause this 
> problem). If you have the time, please advise the developers of the Mono 
> framework to stop distributing this broken packaging of Mono.



-- 
Johannes

Obligatory current favourite quotes:

"We are all atheists about most of the gods that societies have ever
believed in. Some of us just go one god further."
--Richard Dawkins

"Religion is regarded by the common people as true, by the wise as
false, and by the rulers as useful".
 -- Seneca
"I have more confidence in the methods of science, based on the amazing
record of science and its ability over the centuries to answer
unanswerable questions, than I do in the methods of faith (what are they?)."
 -- David J. Gross "Physics Nobel Laureate"

"Atheism is a religion to the same extent that not collecting stamps is a
 hobby."
 -- seen on Slashdot.org

http://xkcd.com/808/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Ryan Schmidt]

On Sep 5, 2011, at 21:04, Johannes Ruscheinski wrote:

> The next problem that I am running into now is:

[snip]

> ===> making all in src/registry2.0
> /usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
> -Wall -pedantic
> -I/Library/Frameworks/Mono.framework/Versions/2.2/include
> -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common registry.c -o
> registry.o
> In file included from ../cregistry/registry.h:35,
> from registry.c:39:
> /Library/Frameworks/Mono.framework/Versions/2.2/include/sqlite3.h:198:
> warning: ISO C90 does not support 'long long'
> /Library/Frameworks/Mono.framework/Versions/2.2/include/sqlite3.h:199:
> warning: ISO C90 does not support 'long long'

[snip]

> Any idea what to do about that?

This is this problem:

https://trac.macports.org/ticket/30932

Delete your Mono framework. It is broken (as in, it is designed to cause this 
problem). If you have the time, please advise the developers of the Mono 
framework to stop distributing this broken packaging of Mono.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Johannes Ruscheinski]

Hi Ryan,

The next problem that I am running into now is:

...
Failed to parse file x11/mesa/Portfile: invalid command name
"get_canonical_archflags"

Total number of ports parsed:   1079
Ports successfully parsed:  0
Ports failed:   1079
Up-to-date ports skipped:   7126

DEBUG: MacPorts sources location:
/opt/local/var/macports/sources/rsync.macports.org/release/base
--->  Updating MacPorts base sources using rsync
receiving file list ... done
./
Mk/
doc/
portmgr/freebsd/
src/
src/cregistry/
...
eleting src/registry2.0/registry_autoconf.tcl
deleting src/registry2.0/registry.o
deleting src/registry2.0/entryobj.o
deleting src/registry2.0/entry.o

sent 114 bytes  received 6887 bytes  4667.33 bytes/sec
total size is 2966586  speedup is 423.74
MacPorts base version 1.9.99 installed,
DEBUG: Rebuilding and reinstalling MacPorts if needed
MacPorts base version 2.0.2 downloaded.
--->  MacPorts base is outdated, installing new version 2.0.2
DEBUG: Permissions OK
Installing new MacPorts release in /opt/local as root:admin;
permissions 0755; Tcl-Package in /Library/Tcl
...
===> making all in src/package1.0
===> making all in src/pextlib1.0
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common Pextlib.c -o Pextlib.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common strsed.c -o strsed.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common fgetln.c -o fgetln.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common md5cmd.c -o md5cmd.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common setmode.c -o setmode.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common xinstall.c -o xinstall.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common fs-traverse.c -o fs-traverse.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common strcasecmp.c -o strcasecmp.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common vercomp.c -o vercomp.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common filemap.c -o filemap.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common base32cmd.c -o base32cmd.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common sha1cmd.c -o sha1cmd.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common curl.c -o curl.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common rmd160cmd.c -o rmd160cmd.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common sha256cmd.c -o sha256cmd.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common readline.c -o readline.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common uid.c -o uid.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common tracelib.c -o tracelib.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common tty.c -o tty.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common readdir.c -o readdir.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common pipe.c -o pipe.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I.  -I"/usr/include"
-fno-common flock.c -o flock.o
/usr/bin/llvm-gcc-4.2 -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W
-Wall -pedantic -DHAVE_CONFIG_H -I.. -I. 

Re: sudo port selfupdate fails

[Ryan Schmidt]

On Sep 5, 2011, at 19:59, Johannes Ruscheinski wrote:

>>> Creating port index in /opt/mports/trunk/dports
>>> Failed to parse file archivers/arj/Portfile: invalid command name
>>> "get_canonical_archflags"
>>> 
>> 
>> 
>>> Any idea what might be wrong and how to fix it?
>> 
>> This is normal, unfortunately, for users upgrading from MacPorts 1.x now. 
>> get_canonical_archs, installs_libs, and others, are new commands only 
>> MacPorts 2 understands. We should not have been trying to rebuild the port 
>> index when upgrading the MaCPorts version. We've already fixed this for the 
>> future, but unfortunately can't do anything about it for users upgrading 
>> from 1.x. Despite all these errors, you should now have MacPorts 2 
>> installed, and simply running selfupdate again should rebuild the port index 
>> correctly with MacPorts 2.
> 
> I did interrupt this before it was done.  I assume it should be fine
> just doing it again (twice?).  Am I correct?

Yes, I believe that should be fine.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Johannes Ruscheinski]

Hi Ryan,

On 5 September 2011 17:30, Ryan Schmidt  wrote:
> On Sep 5, 2011, at 19:07, Johannes Ruscheinski wrote:
>
>> Here is what I get when I run "sudo port -d selfupdate":
>>
>> --->  Updating the ports tree
>> DEBUG: Synchronizing ports tree(s)
>> Synchronizing local ports tree from file:///opt/mports/trunk/dports
>> DEBUG: /usr/bin/svn update --non-interactive /opt/mports/trunk/dports
>> DEBUG: changing euid/egid - current euid: 0 - current egid: 0
>> U    /opt/mports/trunk/dports/python/py26-pygpgme/Portfile
>> A    /opt/mports/trunk/dports/python/py-matplotlib/files/patch-dviread.diff
>> U    /opt/mports/trunk/dports/python/py-matplotlib/Portfile
>> D    /opt/mports/trunk/dports/www/wml/files
>> ...
>> Updated to revision 83561.
>> Creating port index in /opt/mports/trunk/dports
>> Failed to parse file archivers/arj/Portfile: invalid command name
>> "get_canonical_archflags"
>>
>
>
>> Any idea what might be wrong and how to fix it?
>
> This is normal, unfortunately, for users upgrading from MacPorts 1.x now. 
> get_canonical_archs, installs_libs, and others, are new commands only 
> MacPorts 2 understands. We should not have been trying to rebuild the port 
> index when upgrading the MaCPorts version. We've already fixed this for the 
> future, but unfortunately can't do anything about it for users upgrading from 
> 1.x. Despite all these errors, you should now have MacPorts 2 installed, and 
> simply running selfupdate again should rebuild the port index correctly with 
> MacPorts 2.

I did interrupt this before it was done.  I assume it should be fine
just doing it again (twice?).  Am I correct?

Also, thanks for your help and a project that makes life with Mac OS
almost as enjoyable as using Linux or FreeBSD!   I wouldn't know what
I would do w/o MacPorts!  Thanks!!

>
>
>
>



-- 
Johannes

Obligatory current favourite quotes:

"We are all atheists about most of the gods that societies have ever
believed in. Some of us just go one god further."
--Richard Dawkins

"Religion is regarded by the common people as true, by the wise as
false, and by the rulers as useful".
 -- Seneca
"I have more confidence in the methods of science, based on the amazing
record of science and its ability over the centuries to answer
unanswerable questions, than I do in the methods of faith (what are they?)."
 -- David J. Gross "Physics Nobel Laureate"

"Atheism is a religion to the same extent that not collecting stamps is a
 hobby."
 -- seen on Slashdot.org

http://xkcd.com/808/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: sudo port selfupdate fails

[Ryan Schmidt]

On Sep 5, 2011, at 19:07, Johannes Ruscheinski wrote:

> Here is what I get when I run "sudo port -d selfupdate":
> 
> --->  Updating the ports tree
> DEBUG: Synchronizing ports tree(s)
> Synchronizing local ports tree from file:///opt/mports/trunk/dports
> DEBUG: /usr/bin/svn update --non-interactive /opt/mports/trunk/dports
> DEBUG: changing euid/egid - current euid: 0 - current egid: 0
> U/opt/mports/trunk/dports/python/py26-pygpgme/Portfile
> A/opt/mports/trunk/dports/python/py-matplotlib/files/patch-dviread.diff
> U/opt/mports/trunk/dports/python/py-matplotlib/Portfile
> D/opt/mports/trunk/dports/www/wml/files
> ...
> Updated to revision 83561.
> Creating port index in /opt/mports/trunk/dports
> Failed to parse file archivers/arj/Portfile: invalid command name
> "get_canonical_archflags"
> 


> Any idea what might be wrong and how to fix it?

This is normal, unfortunately, for users upgrading from MacPorts 1.x now. 
get_canonical_archs, installs_libs, and others, are new commands only MacPorts 
2 understands. We should not have been trying to rebuild the port index when 
upgrading the MaCPorts version. We've already fixed this for the future, but 
unfortunately can't do anything about it for users upgrading from 1.x. Despite 
all these errors, you should now have MacPorts 2 installed, and simply running 
selfupdate again should rebuild the port index correctly with MacPorts 2.



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

sudo port selfupdate fails

[Johannes Ruscheinski]

Hi,

Here is what I get when I run "sudo port -d selfupdate":

--->  Updating the ports tree
DEBUG: Synchronizing ports tree(s)
Synchronizing local ports tree from file:///opt/mports/trunk/dports
DEBUG: /usr/bin/svn update --non-interactive /opt/mports/trunk/dports
DEBUG: changing euid/egid - current euid: 0 - current egid: 0
U/opt/mports/trunk/dports/python/py26-pygpgme/Portfile
A/opt/mports/trunk/dports/python/py-matplotlib/files/patch-dviread.diff
U/opt/mports/trunk/dports/python/py-matplotlib/Portfile
D/opt/mports/trunk/dports/www/wml/files
...
Updated to revision 83561.
Creating port index in /opt/mports/trunk/dports
Failed to parse file archivers/arj/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file archivers/gzip/Portfile: invalid command name
"installs_libs"
Failed to parse file archivers/xdelta/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file archivers/zoo/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file audio/faust/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file audio/id3v2/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file audio/pianobar/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file audio/qtplay/Portfile: invalid command name "installs_libs"
Failed to parse file audio/ssrc/Portfile: invalid command name
"get_canonical_archflags"
Adding port databases/libgda4
Failed to parse file databases/mongodb/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file databases/redis/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file databases/tinycdb/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file devel/aqbanking5/Portfile: can't read "subport":
no such variable
Failed to parse file devel/bazaar/Portfile: invalid command name "installs_libs"
Adding port devel/bzr-fastimport
Failed to parse file devel/dylibbundler/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file devel/fossil/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file devel/git-core/Portfile: invalid command name
"get_canonical_archflags"
Failed to parse file devel/gmake/Portfile: invalid command name "installs_libs"
...

Any idea what might be wrong and how to fix it?

Thanks!
-- 
Johannes

Obligatory current favourite quotes:

"We are all atheists about most of the gods that societies have ever
believed in. Some of us just go one god further."
--Richard Dawkins

"Religion is regarded by the common people as true, by the wise as
false, and by the rulers as useful".
 -- Seneca
"I have more confidence in the methods of science, based on the amazing
record of science and its ability over the centuries to answer
unanswerable questions, than I do in the methods of faith (what are they?)."
 -- David J. Gross "Physics Nobel Laureate"

"Atheism is a religion to the same extent that not collecting stamps is a
 hobby."
 -- seen on Slashdot.org

http://xkcd.com/808/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Andrew Long]

On 16 Aug 2011, at 22:24, Andrew Long wrote:
>> 
> 
> The problem that I now have is to find out which application that, probably 
> several years and several machines ago, caused me to need to install mono 
> framework. But that isn't a problem for this list.

The application was usenext (the high-level usenet client for the usenext.de 
usenet services). I installed mono from macports and usenext is still(?) 
working (I never tried to use it after uninstalling the mono-framework from 
mono-project.com, so I don't *know* that it would have failed)

However, trying to install mono-basic fails trying to access shared memory 
under /var/empty/.wapi (file does not exist). Also, mono-addins refuses to 
install because the only +universal it understands is i386 & ppc, not x86_64.

So I'm going to leave it here unless anyone else wants to dig deeper.

Regards, Andy

-- 
Andrew Long
andrew dot long at mac dot com








PGP.sig
Description: This is a digitally signed message part
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Daniel J. Luke]

On Aug 16, 2011, at 5:01 PM, Eric Cronin wrote:
> 
>> As far as I know, we don't link with Mono, so it shouldn't interfere
>> with selfupdate (it may interfere with building your own mono). I
>> wasn't sure which was failing for you...
> 
> We don't.  But, the 3rd party Mono package installs in a location that we're 
> searching for libraries in, and it seems ./configure is finding it, and we're 
> preferring it's sqlite library to the system one when building macports base:
> 
> (from an earlier message in the thread):
> ld: warning: in 
> /Library/Frameworks/Mono.framework/Versions/1.9.1/lib/libsqlite3.dylib, 
> missing required architecture x86_64 in file

... but why is our configure looking there at all? 

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Andrew Long]

On 16 Aug 2011, at 22:01, Eric Cronin wrote:

> On Tue, 16 Aug 2011 16:27:06 -0400, Daniel J. Luke wrote:
>> On Aug 16, 2011, at 4:14 PM, Andrew Long wrote:
>>> 
>> 
>> As far as I know, we don't link with Mono, so it shouldn't interfere
>> with selfupdate (it may interfere with building your own mono). I
>> wasn't sure which was failing for you...
> 
> We don't.  But, the 3rd party Mono package installs in a location that we're 
> searching for libraries in, and it seems ./configure is finding it, and we're 
> preferring it's sqlite library to the system one when building macports base:
> 
> (from an earlier message in the thread):
> ld: warning: in 
> /Library/Frameworks/Mono.framework/Versions/1.9.1/lib/libsqlite3.dylib, 
> missing required architecture x86_64 in file
> 
> So if you move the non-macports Mono out of /Library/Frameworks and 
> selfupdate again it should detect the system libsqlite and be happy.
> 
I've followed the 'uninstall' instructions at mono-project.com (it isn't 
*really* a third party mono - it's in fact the one and truly original 
and the selfupdate and update outdated has indeed now completed. 

> You don't need to install mono out of ports unless you want mono (macports 
> base does not need it), and installing it out of ports won't solve the 
> problem of the 3rd party libraries in /Library/Frameworks breaking the 
> selfupdate build (you need to remove that directory as suggested above)...

The problem that I now have is to find out which application that, probably 
several years and several machines ago, caused me to need to install mono 
framework. But that isn't a problem for this list.

What I think *is* still a question that I an usefully address to the list is 
this:-

Assuming that I do still need mono for whichever application it was, or that I 
finally get around to learning .NET from my (seemingly endless) list of 
self-improvement projects, I can install the macports mono, mono-basic & 
mono-addins packages. WIll the standard mono development packages then sit 
happily on top of this? Or am I *still* going to have to struggle with building 
a universal version from the mono-project source? (which should get rid of the 
problem that selfupdate is having - only finding an x86 version of the sqlite 
libraries?)

Regards, Andy

-- 
Andrew Long
andrew dot long at yahoo dot com







PGP.sig
Description: This is a digitally signed message part
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Eric Cronin]

On Tue, 16 Aug 2011 16:27:06 -0400, Daniel J. Luke wrote:

On Aug 16, 2011, at 4:14 PM, Andrew Long wrote:


For the other issue, please delete 
/Library/Frameworks/Mono.framework. You don't need to install the 
MacPorts mono ports unless you have a need for them; MacPorts isn't 
going to use them.


I left ports trying to build mono last night, and twenty four hours 
later, it was still building mono. There was a process running the 
/Library/Frameworks/mono.framework that was consuming an awful lot of 
mill. I killed and and cleaned mono, then got a new version of the 
mono framework from the mono web site, and tried to do the self-update 
again. No Joy.


Quite some time ago, I had problems building mono - but things seemed
to work if I stopped the build and started it again (without
cleaning). I never spent time investigating it, as I didn't end up
needing mono for long.

I note a comment at the web site that the current release of mono 
for OSX is 32-bit only, and I'd need to build a 64-bit one myself. 
Haven't found the destructions for that yet. I'm going to try deleting 
the mono framework and having another go at the selfupdate.


As far as I know, we don't link with Mono, so it shouldn't interfere
with selfupdate (it may interfere with building your own mono). I
wasn't sure which was failing for you...


We don't.  But, the 3rd party Mono package installs in a location that 
we're searching for libraries in, and it seems ./configure is finding 
it, and we're preferring it's sqlite library to the system one when 
building macports base:


(from an earlier message in the thread):
ld: warning: in 
/Library/Frameworks/Mono.framework/Versions/1.9.1/lib/libsqlite3.dylib, 
missing required architecture x86_64 in file


So if you move the non-macports Mono out of /Library/Frameworks and 
selfupdate again it should detect the system libsqlite and be happy.


You don't need to install mono out of ports unless you want mono 
(macports base does not need it), and installing it out of ports won't 
solve the problem of the 3rd party libraries in /Library/Frameworks 
breaking the selfupdate build (you need to remove that directory as 
suggested above)...


Thanks,
Eric
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Daniel J. Luke]

On Aug 16, 2011, at 4:14 PM, Andrew Long wrote:
> 
>>> For the other issue, please delete /Library/Frameworks/Mono.framework. You 
>>> don't need to install the MacPorts mono ports unless you have a need for 
>>> them; MacPorts isn't going to use them.
> 
> I left ports trying to build mono last night, and twenty four hours later, it 
> was still building mono. There was a process running the 
> /Library/Frameworks/mono.framework that was consuming an awful lot of mill. I 
> killed and and cleaned mono, then got a new version of the mono framework 
> from the mono web site, and tried to do the self-update again. No Joy.

Quite some time ago, I had problems building mono - but things seemed to work 
if I stopped the build and started it again (without cleaning). I never spent 
time investigating it, as I didn't end up needing mono for long.

> I note a comment at the web site that the current release of mono for OSX is 
> 32-bit only, and I'd need to build a 64-bit one myself. Haven't found the 
> destructions for that yet. I'm going to try deleting the mono framework and 
> having another go at the selfupdate.

As far as I know, we don't link with Mono, so it shouldn't interfere with 
selfupdate (it may interfere with building your own mono). I wasn't sure which 
was failing for you...

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Andrew Long]

> On 15 Aug 2011, at 21:12, Ryan Schmidt wrote:
> 
>> 
>> On Aug 15, 2011, at 13:36, Andrew Long wrote:
>> 
>>> On 15 Aug 2011, at 18:52, Daniel J. Luke wrote:
>>> 
>> 
>> The perl5 portgroup was just hours ago converted into a new unified format 
>> which is probably going to cause some issues for a few moments while things 
>> settle down. Things should be better in a few hours, or tomorrow.
>> 
> I'll do that tomorrow

Did that. The Perl upgrade has worked, but I'm still having problems with the 
Mono (see below)

> 
>> For the other issue, please delete /Library/Frameworks/Mono.framework. You 
>> don't need to install the MacPorts mono ports unless you have a need for 
>> them; MacPorts isn't going to use them.

I left ports trying to build mono last night, and twenty four hours later, it 
was still building mono. There was a process running the 
/Library/Frameworks/mono.framework that was consuming an awful lot of mill. I 
killed and and cleaned mono, then got a new version of the mono framework from 
the mono web site, and tried to do the self-update again. No Joy.

I note a comment at the web site that the current release of mono for OSX is 
32-bit only, and I'd need to build a 64-bit one myself. Haven't found the 
destructions for that yet. I'm going to try deleting the mono framework and 
having another go at the selfupdate.

Regards, Andy

-- 
Andrew Long
andrew dot long at yahoo dot com







PGP.sig
Description: This is a digitally signed message part
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Andrew Long]

On 15 Aug 2011, at 21:12, Ryan Schmidt wrote:

> 
> On Aug 15, 2011, at 13:36, Andrew Long wrote:
> 
>> On 15 Aug 2011, at 18:52, Daniel J. Luke wrote:
>> 
> 
> The perl5 portgroup was just hours ago converted into a new unified format 
> which is probably going to cause some issues for a few moments while things 
> settle down. Things should be better in a few hours, or tomorrow.
> 
I'll do that tomorrow

> For the other issue, please delete /Library/Frameworks/Mono.framework. You 
> don't need to install the MacPorts mono ports unless you have a need for 
> them; MacPorts isn't going to use them.

I'm sire that there *was* a reason to install it, but it was a few years back. 
So since it looks like the self-update is going to try to build itself using 
Mono (as it's available) I'll finish the current mono installation. I'll also 
look at finding a more recent version of the mono framework and try putting 
that in

Thanks for your help

Regards, Andy
-- 
Andrew Long
andrew dot long at yahoo dot com







PGP.sig
Description: This is a digitally signed message part
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Ryan Schmidt]

On Aug 15, 2011, at 13:36, Andrew Long wrote:

> On 15 Aug 2011, at 18:52, Daniel J. Luke wrote:
> 
>> On Aug 15, 2011, at 1:42 PM, Andrew Long wrote:
>>> 
>>> Can someone please tell me where to look for the log, so I can have a try 
>>> at self-diagnosing, or perhaps tell me where to look for what the *real* 
>>> problem is?
>> 
>> I'm not sure where the log is (someone else probably knows and can tell 
>> you), but you can run selfupdate with the verbose (or debug) mode to see 
>> what is going on.
>> 
>> I usually run like this:
>> 
>> sudo port -dv selfupdate
> 
> Thanks for this suggestion. It has produce a log file that seems to indicate 
> that I have, in fact, got *two* problems. Here are the relevamnt portions of 
> the log file:-
> 
> 
> Creating port index in 
> /opt/local/var/macports/sources/rsync.macports.org/release/ports
> Failed to parse file perl/p5-text-tabsxwrap/Portfile: can't set 
> "depends_lib": invalid depspec: port:p5.12-text-tabs+wrap
> 
> Total number of ports parsed:   1 
> Ports successfully parsed:  0 
> Ports failed:   1 
> Up-to-date ports skipped:   12054
> 
> 
> and 
> 
> 
> /usr/bin/cc -dynamiclib -g -O2 -W -Wall -pedantic  
> -I/Library/Frameworks/Mono.framework/Versions/1.9.1/include
> -Wl,-single_module registry.o util.o entry.o entryobj.o 
> ../cregistry/cregistry.a -o registry.dylib 
> -L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5   
> -L/Library/Frameworks/Mono.framework/Versions/1.9.1/lib -lsqlite3  
> ld: warning: in 
> /Library/Frameworks/Mono.framework/Versions/1.9.1/lib/libsqlite3.dylib, 
> missing required architecture x86_64 in file
> 
> 
> 
> I'm not sure about the perl issue; there doesn't appear to be a port with 
> that title (according to port info) although there is a Portfile in the 
> relevant location 
> /opt/local/var/macports/sources/rsync.macports.org/release/ports/perl/p5-text-tabsxwrap/Portfile
> 
> The sqllite issue appears to be related to the /Library/Frameworks for mono 
> not including a universal binary - as this isn't a port, I'm trying to 
> install the available mono ports (mono, mono-basic & mono-addins)

The perl5 portgroup was just hours ago converted into a new unified format 
which is probably going to cause some issues for a few moments while things 
settle down. Things should be better in a few hours, or tomorrow.

For the other issue, please delete /Library/Frameworks/Mono.framework. You 
don't need to install the MacPorts mono ports unless you have a need for them; 
MacPorts isn't going to use them.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Andrew Long]

On 15 Aug 2011, at 18:52, Daniel J. Luke wrote:

> On Aug 15, 2011, at 1:42 PM, Andrew Long wrote:
>> 
>> Can someone please tell me where to look for the log, so I can have a try at 
>> self-diagnosing, or perhaps tell me where to look for what the *real* 
>> problem is?
> 
> I'm not sure where the log is (someone else probably knows and can tell you), 
> but you can run selfupdate with the verbose (or debug) mode to see what is 
> going on.
> 
> I usually run like this:
> 
> sudo port -dv selfupdate

Thanks for this suggestion. It has produce a log file that seems to indicate 
that I have, in fact, got *two* problems. Here are the relevamnt portions of 
the log file:-


Creating port index in 
/opt/local/var/macports/sources/rsync.macports.org/release/ports
Failed to parse file perl/p5-text-tabsxwrap/Portfile: can't set "depends_lib": 
invalid depspec: port:p5.12-text-tabs+wrap

Total number of ports parsed:   1 
Ports successfully parsed:  0 
Ports failed:   1 
Up-to-date ports skipped:   12054


and 


/usr/bin/cc -dynamiclib -g -O2 -W -Wall -pedantic  
-I/Library/Frameworks/Mono.framework/Versions/1.9.1/include
-Wl,-single_module registry.o util.o entry.o entryobj.o 
../cregistry/cregistry.a -o registry.dylib 
-L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5   
-L/Library/Frameworks/Mono.framework/Versions/1.9.1/lib -lsqlite3  
ld: warning: in 
/Library/Frameworks/Mono.framework/Versions/1.9.1/lib/libsqlite3.dylib, missing 
required architecture x86_64 in file



I'm not sure about the perl issue; there doesn't appear to be a port with that 
title (according to port info) although there is a Portfile in the relevant 
location 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/perl/p5-text-tabsxwrap/Portfile

The sqllite issue appears to be related to the /Library/Frameworks for mono not 
including a universal binary - as this isn't a port, I'm trying to install the 
available mono ports (mono, mono-basic & mono-addins)

More later.

Regards, Andy

-- 
Andrew Long
andrew dot long at yahoo dot com







PGP.sig
Description: This is a digitally signed message part
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Daniel J. Luke]

On Aug 15, 2011, at 1:42 PM, Andrew Long wrote:
> 
> Can someone please tell me where to look for the log, so I can have a try at 
> self-diagnosing, or perhaps tell me where to look for what the *real* problem 
> is?

I'm not sure where the log is (someone else probably knows and can tell you), 
but you can run selfupdate with the verbose (or debug) mode to see what is 
going on.

I usually run like this:

sudo port -dv selfupdate

(although I think -d implies -v now)

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++




___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

port selfupdate fails

[Andrew Long]

I've just tried to self update the ports tree from 2.0.0 to 2.0.1, and it has 
failed *again* This has happened to me for over a year now; the symptoms is 
that it tells me the following:-


Warning: port definitions are more than two weeks old, consider using selfupdate
--->  Updating the ports tree
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.0.0 installed,
MacPorts base version 2.0.1 downloaded.
--->  MacPorts base is outdated, installing new version 2.0.1
Installing new MacPorts release in /opt/local as root:admin; permissions 0755; 
Tcl-Package in /Library/Tcl

Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
MacPorts base: shell command failed (see log for details)

There's no indication of where to look for the log. Every time this has 
happened to me in the past I've had to download the new DMG and re-install from 
there; since the port is supposed to be self-updating, I guess there's 
something weird about my installation.


Can someone please tell me where to look for the log, so I can have a try at 
self-diagnosing, or perhaps tell me where to look for what the *real* problem 
is?

Regards, Andy
-- 
Andrew Long
andrew dot long at yahoo dot com







PGP.sig
Description: This is a digitally signed message part
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 15:14, Marko Käning wrote:

> So, well, what does this mean for macports itself then?
> Looks like there is still an issue here, since it would not install with your 
> sabotage...

Read:

http://lists.macosforge.org/pipermail/macports-users/2010-June/020629.html


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Joshua Root]

On 2010-6-18 06:14 , Marko Käning wrote:
>> Absolutely, since the point of the modifications described in 
>> UsingTheRightCompiler is to sabotage "gcc" so that you can identify software 
>> that is using "gcc" instead of the CC environment variable.
> 
> Ha, well, that's the reason for the whole confusion: I forgot to disable this 
> "sabotage" after I had successfully installed makeicns.
> 
> So, well, what does this mean for macports itself then?
> Looks like there is still an issue here, since it would not install with your 
> sabotage...

The only issue was with the configuration you were using. The sabotage
caused collateral damage.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Marko Käning]

> Absolutely, since the point of the modifications described in 
> UsingTheRightCompiler is to sabotage "gcc" so that you can identify software 
> that is using "gcc" instead of the CC environment variable.

Ha, well, that's the reason for the whole confusion: I forgot to disable this 
"sabotage" after I had successfully installed makeicns.

So, well, what does this mean for macports itself then?
Looks like there is still an issue here, since it would not install with your 
sabotage...

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Marko Käning]

> Read the last paragraph here:
> http://lists.macosforge.org/pipermail/macports-users/2010-June/020623.html

Oh, well, yes, I did that and it worked. Sorry, there were so many posts coming 
in that I got confused about how to proceed. :)
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 15:06, Joshua Root wrote:

> On 2010-6-18 06:04 , Ryan Schmidt wrote:
>> 
> 
>> Yes exactly. So #23095 is completely the relevant ticket, since it causes 
>> selfupdate to not use "gcc" anymore but to use the specific appropriate 
>> compiler.
> 
> My point is that 'gcc' would be fine had you not intentionally sabotaged
> it using binpath.

Absolutely, since the point of the modifications described in 
UsingTheRightCompiler is to sabotage "gcc" so that you can identify software 
that is using "gcc" instead of the CC environment variable.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Joshua Root]

On 2010-6-18 06:04 , Ryan Schmidt wrote:
> 
> On Jun 17, 2010, at 14:50, Joshua Root wrote:
> 
>> On 2010-6-18 05:45 , Ryan Schmidt wrote:
>>>
>>> On Jun 17, 2010, at 14:29, Joshua Root wrote:
>>>
 On 2010-6-18 05:14 , Ryan Schmidt wrote:
>
> You made the changes described in UsingTheRightCompiler to discover when 
> ports are not using the configure.cc etc. variables. You have now 
> discovered that MacPorts itself does not use configure.cc when 
> selfupdating. See:
>
> http://trac.macports.org/ticket/23095
>
> That ticket says this was supposed to have been fixed If it's not, 
> the ticket should be re-opened.
>
> Until it's fixed, you will need to undo the changes described in 
> UsingTheRightCompiler in order to proceed. (I generally just edit the 
> binpath and change /opt/local/bin/no_default_gcc by one character, e.g. 
> change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) 
> so that when I later want to re-enable it again I just have to change one 
> character to do so.

 The base configure script removes $prefix from its PATH. When it's
 running from within MacPorts, 'gcc' *is* the right compiler for it to
 use, so #23095 is a complete non-issue unless you've messed with
 extra_env (unsupported) or actually changed what /usr/bin/gcc points to
 (also unsupported).
>>>
>>> Well it doesn't seem to remove "/opt/local/bin/no_default_gcc" from the 
>>> path (nor would I expect it to),
>>
>> Exactly. Doing precisely what you asked it to.
> 
> Yes exactly. So #23095 is completely the relevant ticket, since it causes 
> selfupdate to not use "gcc" anymore but to use the specific appropriate 
> compiler.

My point is that 'gcc' would be fine had you not intentionally sabotaged
it using binpath.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 14:55, Marko Käning wrote:

> But well, the question is now: How do I go on to get a working macports setup 
> again.

Read the last paragraph here:

http://lists.macosforge.org/pipermail/macports-users/2010-June/020623.html



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 14:50, Joshua Root wrote:

> On 2010-6-18 05:45 , Ryan Schmidt wrote:
>> 
>> On Jun 17, 2010, at 14:29, Joshua Root wrote:
>> 
>>> On 2010-6-18 05:14 , Ryan Schmidt wrote:
 
 You made the changes described in UsingTheRightCompiler to discover when 
 ports are not using the configure.cc etc. variables. You have now 
 discovered that MacPorts itself does not use configure.cc when 
 selfupdating. See:
 
 http://trac.macports.org/ticket/23095
 
 That ticket says this was supposed to have been fixed If it's not, the 
 ticket should be re-opened.
 
 Until it's fixed, you will need to undo the changes described in 
 UsingTheRightCompiler in order to proceed. (I generally just edit the 
 binpath and change /opt/local/bin/no_default_gcc by one character, e.g. 
 change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) so 
 that when I later want to re-enable it again I just have to change one 
 character to do so.
>>> 
>>> The base configure script removes $prefix from its PATH. When it's
>>> running from within MacPorts, 'gcc' *is* the right compiler for it to
>>> use, so #23095 is a complete non-issue unless you've messed with
>>> extra_env (unsupported) or actually changed what /usr/bin/gcc points to
>>> (also unsupported).
>> 
>> Well it doesn't seem to remove "/opt/local/bin/no_default_gcc" from the path 
>> (nor would I expect it to),
> 
> Exactly. Doing precisely what you asked it to.

Yes exactly. So #23095 is completely the relevant ticket, since it causes 
selfupdate to not use "gcc" anymore but to use the specific appropriate 
compiler.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Marko Käning]

But well, the question is now: How do I go on to get a working macports setup 
again.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Marko Käning]

> You're just running /usr/bin/cc here because you're on a
> case-insensitive filesystem. The CC environment variable is probably
> what you're after.

yep, you are right:

Last login: Thu Jun 17 21:06:47 on ttys001
markos-imac:~ marko$ CC
i686-apple-darwin10-gcc-4.2.1: no input files
markos-imac:~ marko$ set | grep CC
_=CC

I didn't know that MacOSX's file system is case insensitive, actually.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Joshua Root]

On 2010-6-18 05:45 , Ryan Schmidt wrote:
> 
> On Jun 17, 2010, at 14:29, Joshua Root wrote:
> 
>> On 2010-6-18 05:14 , Ryan Schmidt wrote:
>>>
>>> You made the changes described in UsingTheRightCompiler to discover when 
>>> ports are not using the configure.cc etc. variables. You have now 
>>> discovered that MacPorts itself does not use configure.cc when 
>>> selfupdating. See:
>>>
>>> http://trac.macports.org/ticket/23095
>>>
>>> That ticket says this was supposed to have been fixed If it's not, the 
>>> ticket should be re-opened.
>>>
>>> Until it's fixed, you will need to undo the changes described in 
>>> UsingTheRightCompiler in order to proceed. (I generally just edit the 
>>> binpath and change /opt/local/bin/no_default_gcc by one character, e.g. 
>>> change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) so 
>>> that when I later want to re-enable it again I just have to change one 
>>> character to do so.
>>
>> The base configure script removes $prefix from its PATH. When it's
>> running from within MacPorts, 'gcc' *is* the right compiler for it to
>> use, so #23095 is a complete non-issue unless you've messed with
>> extra_env (unsupported) or actually changed what /usr/bin/gcc points to
>> (also unsupported).
> 
> Well it doesn't seem to remove "/opt/local/bin/no_default_gcc" from the path 
> (nor would I expect it to),

Exactly. Doing precisely what you asked it to.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 14:29, Joshua Root wrote:

> On 2010-6-18 05:14 , Ryan Schmidt wrote:
>> 
>> You made the changes described in UsingTheRightCompiler to discover when 
>> ports are not using the configure.cc etc. variables. You have now discovered 
>> that MacPorts itself does not use configure.cc when selfupdating. See:
>> 
>> http://trac.macports.org/ticket/23095
>> 
>> That ticket says this was supposed to have been fixed If it's not, the 
>> ticket should be re-opened.
>> 
>> Until it's fixed, you will need to undo the changes described in 
>> UsingTheRightCompiler in order to proceed. (I generally just edit the 
>> binpath and change /opt/local/bin/no_default_gcc by one character, e.g. 
>> change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) so 
>> that when I later want to re-enable it again I just have to change one 
>> character to do so.
> 
> The base configure script removes $prefix from its PATH. When it's
> running from within MacPorts, 'gcc' *is* the right compiler for it to
> use, so #23095 is a complete non-issue unless you've messed with
> extra_env (unsupported) or actually changed what /usr/bin/gcc points to
> (also unsupported).

Well it doesn't seem to remove "/opt/local/bin/no_default_gcc" from the path 
(nor would I expect it to),

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Joshua Root]

On 2010-6-18 05:14 , Ryan Schmidt wrote:
> 
> On Jun 17, 2010, at 13:58, Marko Käning wrote:
> 
>>> Well, can your C compiler create executables? Is Xcode properly installed? 
>>> Check the config.log for more details!
>>
>> up to now i never had problems with my macports and Xcode installation…
>>
>> config.log says this:
>> ---
>> configure:3002: checking for gcc
>> configure:3018: found /opt/local/bin/no_default_gcc/gcc
>> configure:3029: result: gcc
>> configure:3258: checking for C compiler version
>> configure:3267: gcc --version >&5
>> gcc --version
>> gcc: Error: You should be using ${configure.cc}
>> See http://trac.macports.org/wiki/UsingTheRightCompiler
> 
> [snip]
> 
>> UsingTheRightCompiler rings a bell! :) You hinted that out to me when I 
>> introduced the makeicns port.
>> But I didn't expect to see a message like this when I do an upgrade to 1.9.0…
>>
>> I wonder how to proceed from here.
> 
> You made the changes described in UsingTheRightCompiler to discover when 
> ports are not using the configure.cc etc. variables. You have now discovered 
> that MacPorts itself does not use configure.cc when selfupdating. See:
> 
> http://trac.macports.org/ticket/23095
> 
> That ticket says this was supposed to have been fixed If it's not, the 
> ticket should be re-opened.
> 
> Until it's fixed, you will need to undo the changes described in 
> UsingTheRightCompiler in order to proceed. (I generally just edit the binpath 
> and change /opt/local/bin/no_default_gcc by one character, e.g. change it to 
> /opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I 
> later want to re-enable it again I just have to change one character to do so.

The base configure script removes $prefix from its PATH. When it's
running from within MacPorts, 'gcc' *is* the right compiler for it to
use, so #23095 is a complete non-issue unless you've messed with
extra_env (unsupported) or actually changed what /usr/bin/gcc points to
(also unsupported).

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 14:14, Ryan Schmidt wrote:

> You have now discovered that MacPorts itself does not use configure.cc when 
> selfupdating. See:
> 
> http://trac.macports.org/ticket/23095
> 
> That ticket says this was supposed to have been fixed If it's not, the 
> ticket should be re-opened.

I'm assuming that this is in fact fixed, so long as MacPorts 1.9.0+ is the one 
doing the selfupdating; since the MacPorts doing the selfupdating in your case 
was 1.8.2 you still encountered the issue.

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Joshua Root]

On 2010-6-18 05:09 , Marko Käning wrote:
> This is what happens if I call CC from bash:
> ---
> markos-imac:~ marko$ sudo bash
> bash-3.2# CC
> i686-apple-darwin10-gcc-4.2.1: no input files
> ---

You're just running /usr/bin/cc here because you're on a
case-insensitive filesystem. The CC environment variable is probably
what you're after.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Joshua Root]

On 2010-6-18 05:05 , Daniel J. Luke wrote:
> On Jun 17, 2010, at 2:58 PM, Marko Käning wrote:
>>> Well, can your C compiler create executables? Is Xcode properly installed? 
>>> Check the config.log for more details!
>> up to now i never had problems with my macports and Xcode installation…
>>
>> config.log says this:
>> ---
>> configure:3002: checking for gcc
>> configure:3018: found /opt/local/bin/no_default_gcc/gcc
> 
> you don't want it to find this compile, you want to use the one installed by 
> Xcode.
> 
> You probably have 'CC' set so AC_PROG_CC is finding this instead of the 
> 'normal' Xcode installed compiler.
> 
> When normally installing ports, Macports sanitizes the environment so this 
> isn't an issue, but I think that this doesn't happen for building macports (I 
> could be wrong).

We do clean out the environment at startup. Marko must have CC in
extra_env or something, in which case it's just doing what he asked it to.

- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 13:58, Marko Käning wrote:

>> Well, can your C compiler create executables? Is Xcode properly installed? 
>> Check the config.log for more details!
> 
> up to now i never had problems with my macports and Xcode installation…
> 
> config.log says this:
> ---
> configure:3002: checking for gcc
> configure:3018: found /opt/local/bin/no_default_gcc/gcc
> configure:3029: result: gcc
> configure:3258: checking for C compiler version
> configure:3267: gcc --version >&5
> gcc --version
> gcc: Error: You should be using ${configure.cc}
> See http://trac.macports.org/wiki/UsingTheRightCompiler

[snip]

> UsingTheRightCompiler rings a bell! :) You hinted that out to me when I 
> introduced the makeicns port.
> But I didn't expect to see a message like this when I do an upgrade to 1.9.0…
> 
> I wonder how to proceed from here.

You made the changes described in UsingTheRightCompiler to discover when ports 
are not using the configure.cc etc. variables. You have now discovered that 
MacPorts itself does not use configure.cc when selfupdating. See:

http://trac.macports.org/ticket/23095

That ticket says this was supposed to have been fixed If it's not, the 
ticket should be re-opened.

Until it's fixed, you will need to undo the changes described in 
UsingTheRightCompiler in order to proceed. (I generally just edit the binpath 
and change /opt/local/bin/no_default_gcc by one character, e.g. change it to 
/opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I later 
want to re-enable it again I just have to change one character to do so.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Marko Käning]

This is what happens if I call CC from bash:
---
markos-imac:~ marko$ sudo bash
bash-3.2# CC
i686-apple-darwin10-gcc-4.2.1: no input files
---
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Daniel J. Luke]

On Jun 17, 2010, at 2:58 PM, Marko Käning wrote:
>> Well, can your C compiler create executables? Is Xcode properly installed? 
>> Check the config.log for more details!
> up to now i never had problems with my macports and Xcode installation…
> 
> config.log says this:
> ---
> configure:3002: checking for gcc
> configure:3018: found /opt/local/bin/no_default_gcc/gcc

you don't want it to find this compile, you want to use the one installed by 
Xcode.

You probably have 'CC' set so AC_PROG_CC is finding this instead of the 
'normal' Xcode installed compiler.

When normally installing ports, Macports sanitizes the environment so this 
isn't an issue, but I think that this doesn't happen for building macports (I 
could be wrong).

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Marko Käning]

Hi Ryan,

> Well, can your C compiler create executables? Is Xcode properly installed? 
> Check the config.log for more details!
up to now i never had problems with my macports and Xcode installation…

config.log says this:
---
configure:3002: checking for gcc
configure:3018: found /opt/local/bin/no_default_gcc/gcc
configure:3029: result: gcc
configure:3258: checking for C compiler version
configure:3267: gcc --version >&5
gcc --version
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3267: gcc -v >&5
gcc -v
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3267: gcc -V >&5
gcc -V
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3267: gcc -qversion >&5
gcc -qversion
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3298: checking whether the C compiler works
configure:3320: gccconftest.c  >&5
gcc conftest.c
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3324: $? = 1
configure:3362: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "MacPorts"
| #define PACKAGE_TARNAME "macports"
| #define PACKAGE_VERSION "1.9.0"
| #define PACKAGE_STRING "MacPorts 1.9.0"
| #define PACKAGE_BUGREPORT "macports-...@lists.macosforge.org"
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3367: error: in 
`/opt/local/var/macports/sources/rsync.macports.org/release/base':
configure:3371: error: C compiler cannot create executables
See `config.log' for more details.
---

UsingTheRightCompiler rings a bell! :) You hinted that out to me when I 
introduced the makeicns port.
But I didn't expect to see a message like this when I do an upgrade to 1.9.0…

I wonder how to proceed from here.

Greets,
Marko
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Jun 17, 2010, at 13:07, Marko Käning wrote:

> I just tried to selfupdate and it failed.
> 
> Further down you can see:  "configure: error: C compiler cannot create 
> executable"!

> checking for gcc... gcc
> checking whether the C compiler works... no
> configure: error: in 
> `/opt/local/var/macports/sources/rsync.macports.org/release/base':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.

Well, can your C compiler create executables? Is Xcode properly installed? 
Check the config.log for more details!


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

selfupdate fails

[Marko Käning]

I just tried to selfupdate and it failed.

Further down you can see:  "configure: error: C compiler cannot create 
executable"!

I wonder what's going on here! I never saw stg like this.

---
.
.
.
sent 20068 bytes  received 462257 bytes  107183.33 bytes/sec
total size is 54551356  speedup is 113.10
DEBUG: MacPorts sources location: 
/opt/local/var/macports/sources/rsync.macports.org/release/base
--->  Updating MacPorts base sources using rsync
receiving file list ... done
./
deleting config.log

sent 42 bytes  received 6676 bytes  2687.20 bytes/sec
total size is 2874599  speedup is 427.90
MacPorts base version 1.8.2 installed,
DEBUG: Rebuilding and reinstalling MacPorts if needed
MacPorts base version 1.9.0 downloaded.
--->  MacPorts base is outdated, installing new version 1.9.0
DEBUG: Permissions OK
Installing new MacPorts release in /opt/local as root:admin; permissions 0755; 
Tcl-Package in /Library/Tcl

checking build system type... i386-apple-darwin10.3.0
checking host system type... i386-apple-darwin10.3.0
checking target system type... i386-apple-darwin10.3.0
checking MacPorts version... 1.9.0
checking for sw_vers... /usr/bin/sw_vers
checking for defaults... /usr/bin/defaults
checking for xcode-select... /usr/bin/xcode-select
checking Mac OS X version... 10.6.3
checking Xcode location... /Developer
checking Xcode version... 3.2.2
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in 
`/opt/local/var/macports/sources/rsync.macports.org/release/base':
configure: error: C compiler cannot create executables
See `config.log' for more details.
DEBUG: Error installing new MacPorts base: shell command "cd 
/opt/local/var/macports/sources/rsync.macports.org/release/base && ./configure 
--prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root 
--with-install-group=admin --with-directory-mode=0755 --enable-readline && make 
&& make install" returned error 77
while executing
"macports::selfupdate [array get global_options]"
Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
MacPorts base: shell command "cd 
/opt/local/var/macports/sources/rsync.macports.org/release/base && ./configure 
--prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root 
--with-install-group=admin --with-directory-mode=0755 --enable-readline && make 
&& make install" returned error 77
markos-imac:~ marko$ 

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

missing make (was: port selfupdate fails)

[Joshua Root]

On 2009-12-23 02:16 , Peter B. West wrote:
> 
> lydia:local pbw$ sudo port upgrade outdated
> Error: Unable to open port: can't read "build.cmd": Failed to locate 'make' 
> in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at 
> its MacPorts configuration time location, did you move it?
> lydia:local pbw$ which make
> lydia:local pbw$ echo $PATH
> /opt/subversion/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/local/mysql/bin:/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin:/opt/local/share/java/apache-ant/bin:/Applications/NetBeans/NetBeans/6.7/Contents/Resources/NetBeans/bin:/Users/pbw/bin:/Users/pbw/src/perl:/Users/pbw/src/sh:/Users/pbw/src/tcl:/Applications/oxygen:/opt/pbw/idea/bin:/opt/scala/bin:.
> 
> 
> Make has gone away. I swear I didn't touch it. Could a normal Mac software 
> update have affected it?

Usually this means you don't have Xcode Tools installed, or you
deselected the "Unix Development" option.



- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Greg Shenaut]

On Dec 22, 2009, at 1:52 PM, Peter B. West wrote:
Make has gone away. I swear I didn't touch it. Could a normal Mac  
software update have affected it?



gmake is there, so I'll add a softlink to make. Is gmake the  
standard for MacPorts? What is the standard Xcode make?


On my system, ls -l `whence make` yields:

lrwxr-xr-x  1 root  wheel  7 Mar 21  2009 /usr/bin/make -> gnumake

And of course, ls -l `whence gnumake`:
/usr/bin/gnumake

Greg Shenaut
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Peter B. West]

On 23/12/2009, at 1:16 AM, Peter B. West wrote:

> 
> On 23/12/2009, at 12:57 AM, Daniel J. Luke wrote:
> 
>> On Dec 22, 2009, at 5:09 AM, Peter B. West wrote:
>>> lydia:Downloads pbw$ port selfupdate
>>> --->  Updating the ports tree
>>> Error: Synchronization of the local ports tree failed doing rsync
>>> Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
>>> tree: Synchronization of 1 source(s) failed
>>> 
>>> Any ideas?
>> 
>> http://trac.macports.org/wiki/FAQ#selfupdatefails
> 
> 
> Had a look at that. Tried the
> sudo port -d selfupdate
> and it worked.
> 
> I followed the instructions at the end of the output:
> 
> MacPorts base version 1.8.1 downloaded.
> --->  MacPorts base is already the latest version
> DEBUG: Setting MacPorts sources ownership to root
> 
> The ports tree has been updated. To upgrade your installed ports, you should 
> run
>  port upgrade outdated
> lydia:local pbw$ sudo port upgrade outdated
> Error: Unable to open port: can't read "build.cmd": Failed to locate 'make' 
> in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at 
> its MacPorts configuration time location, did you move it?
> lydia:local pbw$ which make
> lydia:local pbw$ echo $PATH
> /opt/subversion/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/local/mysql/bin:/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin:/opt/local/share/java/apache-ant/bin:/Applications/NetBeans/NetBeans/6.7/Contents/Resources/NetBeans/bin:/Users/pbw/bin:/Users/pbw/src/perl:/Users/pbw/src/sh:/Users/pbw/src/tcl:/Applications/oxygen:/opt/pbw/idea/bin:/opt/scala/bin:.
> 
> 
> Make has gone away. I swear I didn't touch it. Could a normal Mac software 
> update have affected it?


gmake is there, so I'll add a softlink to make. Is gmake the standard for 
MacPorts? What is the standard Xcode make?

Peter

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Peter B. West]

On 23/12/2009, at 12:57 AM, Daniel J. Luke wrote:

> On Dec 22, 2009, at 5:09 AM, Peter B. West wrote:
>> lydia:Downloads pbw$ port selfupdate
>> --->  Updating the ports tree
>> Error: Synchronization of the local ports tree failed doing rsync
>> Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
>> tree: Synchronization of 1 source(s) failed
>> 
>> Any ideas?
> 
> http://trac.macports.org/wiki/FAQ#selfupdatefails


Had a look at that. Tried the
 sudo port -d selfupdate
and it worked.

I followed the instructions at the end of the output:

MacPorts base version 1.8.1 downloaded.
--->  MacPorts base is already the latest version
DEBUG: Setting MacPorts sources ownership to root

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
lydia:local pbw$ sudo port upgrade outdated
Error: Unable to open port: can't read "build.cmd": Failed to locate 'make' in 
path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its 
MacPorts configuration time location, did you move it?
lydia:local pbw$ which make
lydia:local pbw$ echo $PATH
/opt/subversion/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/local/mysql/bin:/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin:/opt/local/share/java/apache-ant/bin:/Applications/NetBeans/NetBeans/6.7/Contents/Resources/NetBeans/bin:/Users/pbw/bin:/Users/pbw/src/perl:/Users/pbw/src/sh:/Users/pbw/src/tcl:/Applications/oxygen:/opt/pbw/idea/bin:/opt/scala/bin:.


Make has gone away. I swear I didn't touch it. Could a normal Mac software 
update have affected it?

Peter

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: port selfupdate fails

[Daniel J. Luke]

On Dec 22, 2009, at 5:09 AM, Peter B. West wrote:
> lydia:Downloads pbw$ port selfupdate
> --->  Updating the ports tree
> Error: Synchronization of the local ports tree failed doing rsync
> Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
> tree: Synchronization of 1 source(s) failed
> 
> Any ideas?

http://trac.macports.org/wiki/FAQ#selfupdatefails

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

port selfupdate fails

[Peter B. West]

lydia:Downloads pbw$ port selfupdate
--->  Updating the ports tree
Error: Synchronization of the local ports tree failed doing rsync
Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports 
tree: Synchronization of 1 source(s) failed


Any ideas?

Peter
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Jochen Küpper]

On 30.03.2009, at 08:05, Bryan Blackburn wrote:


On Mon, Mar 30, 2009 at 12:11:46AM -0500, Ryan Schmidt said:

On Mar 29, 2009, at 11:17, Jochen Küpper wrote:


after the announcement of 1.7.1 I run port selfupdate, however, this
bails -- could be due to gcc_select 4.3?

So, this is a Mac OS X 10.5.6 system with MacPorts 1.7.0. I have  
used

gcc_select to pick gcc-mp-4.3:
 /opt/local/bin/gcc@ -> /opt/local/bin/gcc-mp-4.3


I don't know could you try removing the /opt/local/bin/gcc  
symlink and
see if selfupdate then works? I would have hoped that selfupdate,  
like
MacPorts itself, would use only the very specific gcc version with  
which

we have all tested (/usr/bin/gcc-4.0).


selfupdate, or more specifically, configure, removes ${prefix}/bin and
${prefix}/sbin from PATH prior to running (through MP_PATH_SCAN in
aclocal.m4) so nothing there like gcc should even be seen.


That seems to be correct; from /opt/local/var/macports/sources/ 
rsync.macports.org/release/base/config.log


configure:2605: checking for C compiler version
configure:2613: gcc --version >&5
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)


However, it does not seem to make sure that the correct gcc is used  
for building!


When I
   cd /opt/local/var/macports/sources/rsync.macports.org/release/base/ 
src/tclobjc1.0

and then run
   sudo make CC=/usr/bin/gcc
it does successfully compile everything in there...
To me this looks like it "correctly" makes sure that GCC is not from $ 
{prefix}, but then lets make happily (fatally) use whatever gcc it  
finds...


If I remove /opt/local/bin/gcc everything works as expected.

So, port selfupdate really needs to pass CC to make or, prefrable  
(because better visible) set it in the Makefiles...



Anyway, thanks for all your work and for your suggestions on this issue.


Using 'sudo port -d selfupdate' would be more helpful as the issue  
is probably before the output we're seeing.


Not really, this is the first error I am getting when using my  
original setup:



===> making all in src/tclobjc1.0
gcc -c -DUSE_TCL_STUBS -g -O2  -g -Os -DHAVE_CONFIG_H -I.. -I.  -I"/ 
usr/include"  -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - 
D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 - 
DHAVE_PTHREAD_ATFORK=1 -DHAVE_READDIR_R=1 -DMAC_OSX_TCL=1 - 
DHAVE_CFBUNDLE=1 -DUSE_VFORK=1 -DTCL_DEFAULT_ENCODING=\"utf-8\" - 
DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 - 
DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 - 
DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 - 
DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 - 
DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 - 
DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 - 
DSTDC_HEADERS=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 - 
DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_FILIO_H=1 -include tclArch.h  - 
UPACKAGE_NAME -UPACKAGE_TARNAME -UPACKAGE_VERSION -UPACKAGE_STRING - 
UPACKAGE_BUGREPORT -fno-common tclobjc.m -o tclobjc.o
In file included from /System/Library/Frameworks/Foundation.framework/ 
Headers/NSAffineTransform.h:5,
 from /System/Library/Frameworks/Foundation.framework/ 
Headers/Foundation.h:13,

 from tclobjc.m:42:
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h: 
122: error: expected ';' before '__attribute__'
In file included from /System/Library/Frameworks/Foundation.framework/ 
Headers/NSGeometry.h:7,
 from /System/Library/Frameworks/Foundation.framework/ 
Headers/NSAffineTransform.h:6,
 from /System/Library/Frameworks/Foundation.framework/ 
Headers/Foundation.h:13,

 from tclobjc.m:42:
/System/Library/Frameworks/Foundation.framework/Headers/NSCoder.h:79:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSCoder.h:87:  
error: expected ';' before '__attribute__'
In file included from /System/Library/Frameworks/Foundation.framework/ 
Headers/Foundation.h:15,

 from tclobjc.m:42:
/System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:62:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:66:  
error: expected ';' before '__attribute__'
In file included from /System/Library/Frameworks/Foundation.framework/ 
Headers/NSAttributedString.h:5,
 from /System/Library/Frameworks/Foundation.framework/ 
Headers/Foundation.h:16,

 from tclobjc.m:42:
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h: 
345: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h: 
346: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h: 
347: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h: 
348: error: expected ';' before '__attri

Re: selfupdate fails

[Bryan Blackburn]

On Mon, Mar 30, 2009 at 12:11:46AM -0500, Ryan Schmidt said:
> On Mar 29, 2009, at 11:17, Jochen Küpper wrote:
>
>> after the announcement of 1.7.1 I run port selfupdate, however, this 
>> bails -- could be due to gcc_select 4.3?
>>
>> So, this is a Mac OS X 10.5.6 system with MacPorts 1.7.0. I have used 
>> gcc_select to pick gcc-mp-4.3:
>>   /opt/local/bin/gcc@ -> /opt/local/bin/gcc-mp-4.3
>
> I don't know could you try removing the /opt/local/bin/gcc symlink and 
> see if selfupdate then works? I would have hoped that selfupdate, like 
> MacPorts itself, would use only the very specific gcc version with which 
> we have all tested (/usr/bin/gcc-4.0).

selfupdate, or more specifically, configure, removes ${prefix}/bin and
${prefix}/sbin from PATH prior to running (through MP_PATH_SCAN in
aclocal.m4) so nothing there like gcc should even be seen.

Using 'sudo port -d selfupdate' would be more helpful as the issue is
probably before the output we're seeing.

Bryan

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Ryan Schmidt]

On Mar 29, 2009, at 11:17, Jochen Küpper wrote:

after the announcement of 1.7.1 I run port selfupdate, however,  
this bails -- could be due to gcc_select 4.3?


So, this is a Mac OS X 10.5.6 system with MacPorts 1.7.0. I have  
used gcc_select to pick gcc-mp-4.3:

  /opt/local/bin/gcc@ -> /opt/local/bin/gcc-mp-4.3


I don't know could you try removing the /opt/local/bin/gcc  
symlink and see if selfupdate then works? I would have hoped that  
selfupdate, like MacPorts itself, would use only the very specific  
gcc version with which we have all tested (/usr/bin/gcc-4.0).



___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

selfupdate fails

[Jochen Küpper]

Hi,

after the announcement of 1.7.1 I run port selfupdate, however, this  
bails -- could be due to gcc_select 4.3?


So, this is a Mac OS X 10.5.6 system with MacPorts 1.7.0. I have used  
gcc_select to pick gcc-mp-4.3:

  /opt/local/bin/gcc@ -> /opt/local/bin/gcc-mp-4.3

Anyway, this is what selfupdate tells me:

> sudo port selfupdate
Password:

MacPorts base version 1.700 installed
Downloaded MacPorts base version 1.710

Installing new MacPorts release in /opt/local as root:admin - TCL- 
PACKAGE in /Library/Tcl; Permissions: 0755


Error: /opt/local/bin/port: port selfupdate failed: Error installing  
new MacPorts base: shell command "cd /opt/local/var/macports/sources/ 
rsync.macports.org/release/base && ./configure --prefix=/opt/local -- 
with-tclpackage=/Library/Tcl --with-install-user=root --with-install- 
group=admin --with-directory-mode=0755 && make && make install"  
returned error 2
Command output: /System/Library/Frameworks/Foundation.framework/ 
Headers/NSURLHandle.h:80: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
83: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
86: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
89: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
90: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
93: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
94: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
95: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
97: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
98: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
99: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
100: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
102: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
103: error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h: 
104: error: expected ';' before '__attribute__'
In file included from /System/Library/Frameworks/Foundation.framework/ 
Headers/Foundation.h:88,

 from tclobjc.m:42:
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:75:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:76:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:77:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:78:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:83:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:84:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:85:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:88:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:89:  
error: expected ';' before '__attribute__'
/System/Library/Frameworks/Foundation.framework/Headers/NSURL.h:91:  
error: expected ';' before '__attribute__'

make[2]: *** [tclobjc.o] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1

Greetings,
Jochen
--
Einigkeit und Recht und Freiheithttp://www.Jochen-Kuepper.de
Liberté, Égalité, FraternitéGnuPG key: CC1B0B4D
Sex, drugs and rock-n-roll




PGP.sig
Description: This is a digitally signed message part
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: selfupdate fails

[Rainer Müller]

Dimitri Hendriks wrote:

Hi,

I try to selfupdate macports on system 10.4.11,
but it fails; see error message below.
Does anyone know how to solve this?


No idea. Try installing from the disk image as a workaround.

Rainer

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

selfupdate fails

[Dimitri Hendriks]

Hi,

I try to selfupdate macports on system 10.4.11,
but it fails; see error message below.
Does anyone know how to solve this?

Thanks in advance,
Dimitri

[EMAIL PROTECTED]:~<513> sudo port selfupdate -dMacPorts base version 1.520  
installed

Downloaded MacPorts base version 1.600
Configuring, Building and Installing new MacPorts base
Error: /opt/local/bin/port: selfupdate failed: Error installing new  
MacPorts base: shell command "cd /opt/local/var/macports/sources/ 
rsync.macports.org/release/base && ./configure --prefix=/opt/local -- 
with-install-user=root --with-install-group=admin --with-tclpackage=/ 
Library/Tcl && make && make install" returned error 2
Command output: registry.c:305: error: `errPtr' undeclared (first use  
in this function)
registry.c:306: error: request for member `status' in something not a  
structure or unionregistry.c: At top level:


registry.c:321: error: parse error before '*' token
registry.c: In function `reg_start_write':
registry.c:322: error: `errPtr' undeclared (first use in this function)
registry.c:323: error: request for member `status' in something not a  
structure or union

registry.c: At top level:
registry.c:333: error: parse error before '*' token
registry.c: In function `reg_end':
registry.c:334: error: request for member `status' in something not a  
structure or union

registry.c:335: error: `errPtr' undeclared (first use in this function)
registry.c:341: error: request for member `db' in something not a  
structure or union

registry.c:341: error: `query' undeclared (first use in this function)
registry.c:342: error: `SQLITE_OK' undeclared (first use in this  
function)
registry.c:345: error: `SQLITE_BUSY' undeclared (first use in this  
function)
registry.c:346: error: request for member `db' in something not a  
structure or union

registry.c: At top level:
registry.c:359: error: parse error before '*' token
registry.c: In function `reg_commit':
registry.c:360: error: `errPtr' undeclared (first use in this function)
registry.c:361: error: request for member `status' in something not a  
structure or union

registry.c: At top level:
registry.c:376: error: parse error before '*' token
registry.c: In function `reg_rollback':
registry.c:377: error: `errPtr' undeclared (first use in this function)
registry.c:378: error: request for member `status' in something not a  
structure or unionmake[2]: *** [registry.o] Error 1make[1]: *** [all]  
Error 1make: *** [all] Error 1


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users

Re: newbie selfupdate fails

[Ryan Schmidt]

On Jul 23, 2007, at 21:11, Eric Platon wrote:


It looks like rsync is failing to connect.  Perhaps the server is too
busy?
Or perhaps my company firewalls are blocking it?
Suggestions?


My company firewalls does block rsync and it was my problem to get the
updates. I could connect to rsync, so it seems working well. The  
solution to
the firewall problem was to change the rsync target for the svn  
repository

in /opt/local/etc/macports/source.conf. The svn address is:
http://svn.macosforge.org/repository/macports/trunk/

I wonder however whether the MacPorts team prefers users to avoid  
using the

svn, as most of the official information leads to rsync.


Feel free to use the svn method. The svn repository is, after all,  
the master; the rsync version is merely copied from that. I have used  
the svn method for many months. By doing so, you will get updates  
quicker than rsync users. (The rsync version only syncs with the svn  
repository every half hour or so.) The only reason (that I know of)  
that MacPorts does not use svn by default is that Mac OS X does not  
include the svn software, but does include the rsync software, and  
requiring users to build svn (and all its dependencies) would be a  
bit heavy.


___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users