Re: Debian-like rename utility - available via MacPorts?

[Dan Ports]

On Thu, Feb 23, 2012 at 03:24:44AM +, Sam Kuper wrote:
> One slight quibble: given that the script seems normally to be invoked
> with "rename" rather than "file-rename" (even the synopsis in the man
> page I get from entering "man file-rename" seems to expect the script
> to be invoked with "rename" rather than "file-rename"!), I think it
> might be better if the MacPorts port follows this convention. That
> way, users used to using the "rename" script they've obtained via
> Debian/Ubuntu/Brew/whatever won't be confused if they switch to
> MacPorts. Does this sound fair?

Sure. I added a symlink for rename -> file-rename.

I didn't do that originally because the File::Rename module installs
the script as as `file-rename` and I thought there might be some
differences between it and the original `rename` script, but upon
closer examination it's clearly the same script in slightly different
form.

Dan

-- 
Dan R. K. Ports  MIT CSAILhttp://drkp.net/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Debian-like rename utility - available via MacPorts?

[Jeremy Lavergne]

> it *does*, for some reason, still respond to "man rename".

That's rename(2). If it's a command line program, it'd be rename(1).

These categories plan am important trickle down in this situation ;-)



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Debian-like rename utility - available via MacPorts?

[Sam Kuper]

On 23 February 2012 01:32, Dan Ports  wrote:
>
> On Wed, Feb 22, 2012 at 11:33:50PM +, Sam Kuper wrote:
> > If I'm not mistaken, in Debian Linux (& Ubuntu, etc), there is a
> > "rename" utility, which I think comes from Debian's Perl package. It
> > allows file renaming using regular expressions, as described in Jens
> > Dreger's post here[1].
> [...]
> > In any case, it would be much better if MacPorts users could simply
> > get "rename" by running "port install rename" much as Brew users can
> > apparently get it by running "brew install rename"[2].
>
> Sounds like a useful thing to have. I just added the p5-file-rename
> port, which is a newer version of that script. It installs both a perl
> module and a command-line script `file-rename`.


Thanks for the quick response, Dan!

I just ran "sudo port selfupdate" and then "sudo port install
p5-file-rename", and have now used the "file-rename" script to rename
a few files. Seems to be working fine.

One slight quibble: given that the script seems normally to be invoked
with "rename" rather than "file-rename" (even the synopsis in the man
page I get from entering "man file-rename" seems to expect the script
to be invoked with "rename" rather than "file-rename"!), I think it
might be better if the MacPorts port follows this convention. That
way, users used to using the "rename" script they've obtained via
Debian/Ubuntu/Brew/whatever won't be confused if they switch to
MacPorts. Does this sound fair?

The only snag I can foresee is that although, by default, OS X (at
least, Snow Leopard, which I'm using) doesn't have a "rename" script
installed, it *does*, for some reason, still respond to "man rename".
So some kind of override might be needed to ensure that the correct
man page is shown if a user who has installed p5-file-rename via
MacPorts invokes "man rename". I guess the Brew maintainer for
"rename" must have either stumbled on this stumbling block or found a
way around it, but not being a Brew user, I'm not sure which!

Thanks again,

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

Re: error using MacPorts zlib, not present with system zlib?

[Eric Cronin]

On Feb 22, 2012, at 10:02 PM, Brandon Allbery wrote:
> 
> On Wed, Feb 22, 2012 at 21:36, Mike Alexander  wrote:
> --On February 22, 2012 4:50:52 PM -0500 Eric Cronin  
> wrote:
> This code is wrong.  The zlib documentation says gzgetc takes a
> gzFile* not a void*.
> 
>  typedef struct gzFile_s *gzFile;
> 
> so it's defined as a pointer.  Some compilers at some warning levels get 
> annoyed if you use a gzFile* instead of gzFile for these parameters.
> 
> As they well should.
>  


Yeah, that was a typo/glancing at the docs too quickly (it is a pointer type 
eventually which makes it void* convertable).  I don't think any compiler would 
let you pass a gzFile* to a function expecting a gzFile at any warning level, 
C's type system isn't *that* bad.

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

Re: error using MacPorts zlib, not present with system zlib?

[Brandon Allbery]

On Wed, Feb 22, 2012 at 21:36, Mike Alexander  wrote:

> --On February 22, 2012 4:50:52 PM -0500 Eric Cronin 
> wrote:
>
>> This code is wrong.  The zlib documentation says gzgetc takes a
>> gzFile* not a void*.
>>
>
>  typedef struct gzFile_s *gzFile;
>
> so it's defined as a pointer.  Some compilers at some warning levels get
> annoyed if you use a gzFile* instead of gzFile for these parameters.


As they well should.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: error using MacPorts zlib, not present with system zlib?

[Mike Alexander]

--On February 22, 2012 4:50:52 PM -0500 Eric Cronin 
 wrote:



This code is wrong.  The zlib documentation says gzgetc takes a
gzFile* not a void*.


Your analysis of this is correct except for one minor point.  gzopen 
returns and gzgetc (and others) take a gzFile not a gzFile*.  The 
definition of gzFile is



 typedef struct gzFile_s *gzFile;

so it's defined as a pointer.  Some compilers at some warning levels 
get annoyed if you use a gzFile* instead of gzFile for these parameters.


   Mike

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

Re: Debian-like rename utility - available via MacPorts?

[Dan Ports]

On Wed, Feb 22, 2012 at 11:33:50PM +, Sam Kuper wrote:
> If I'm not mistaken, in Debian Linux (& Ubuntu, etc), there is a
> "rename" utility, which I think comes from Debian's Perl package. It
> allows file renaming using regular expressions, as described in Jens
> Dreger's post here[1].
[...]
> In any case, it would be much better if MacPorts users could simply
> get "rename" by running "port install rename" much as Brew users can
> apparently get it by running "brew install rename"[2].

Sounds like a useful thing to have. I just added the p5-file-rename
port, which is a newer version of that script. It installs both a perl
module and a command-line script `file-rename`.

Dan

-- 
Dan R. K. Ports  MIT CSAILhttp://drkp.net/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: clamav and bzip2

[John Brown]

Dear Jeremy,

   Thank you for the reminder that it's all available at the developers 
site. That's what happens when you leave home.


Shalom,

John B Brown
j...@vcn.com
358 High Street
Buffalo, Wyoming
82834

"Freedom is not worth having if it does not include
the freedom to make mistakes" Mahatma Gandhi
"There was never a good war, or a bad peace."
Benjamin Franklin
"I wonder whether the world is being run
by smart people who are putting us on
or by imbeciles who really mean it." Mark Twain

1-307-684-9068


Jeremy Lavergne wrote:

  Having performed software update a number of times what else must I do? Is a 
later Xcode archived?


From:
http://guide.macports.org/#installing.xcode

Always make sure to install the latest available version of Xcode for your Mac 
OS X release (with the exception of Xcode 4.3, for now); using outdated 
versions of Xcode may cause port install failures. Also note that Xcode is not 
updated via Mac OS X's Software Update utility on OS versions prior to 10.6, 
and is updated via the Mac App Store on 10.7.

You can find all Xcode downloads through connect.apple.com.




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

Re: Help please

[James Linder]

On 23/02/2012, at 1:07 AM, Ryan Schmidt wrote:

> 
> On Feb 21, 2012, at 22:44, James Linder wrote:
> 
> checking for Apple Objective-C runtime... yes
> checking for GNU Objective C runtime... no
> configure: Using Apple Objective-C runtime
> checking for Apple Foundation library... no
> configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your 
> environment, preventing the use of GNUstep's Foundation library
> configure: error: Could not find a working Foundation implementation
 
 This is an error we've encountered a few times before, such as:
 
 https://trac.macports.org/ticket/28452
 
 https://trac.macports.org/ticket/30298
 
 We didn't receive further feedback from the reporters so were unable to 
 pursue the matter further. Can you attach your config.log? Maybe it will 
 shed further light.
 
 In #28452 we presumed software installed in /usr/local was interfering. Do 
 you have anything installed in /usr/local? If so, remove it and try again.
 
 In #30298 we presumed the user's operating system components had become 
 damaged and the OS should be reinstalled. So that's another avenue you 
 could pursue.
>>> 
>>> haycorn:~ # ls /usr/local
>>> .gitLibrary etc share
>>> .gitignore  README.md   include texlive
>>> Cellar  bin lib
>>> 
>>> This was put here by latex install ...
>>> 
>>> haycorn:~ # mv /usr/local/ /usr/oldlocal
>>> haycorn:~ # port -d selfupdate
>>> [snip]
>>> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
>>> MacPorts base: shell command failed (see log for details)
>>> 
>>> OK it'll take me a day or so to backup everything I want, so reinstall 
>>> (which will certainly work, it did work before) and I'll report back
>> 
>> Snow Leopard and install CD: Insert CD 'Instal Mac OS X': whirr whirr (1 
>> hour) {but this way is very easy)
>> 
>> then
>> 
>> ...
>> DEBUG: Error installing new MacPorts base: shell command failed (see log for 
>> details)
>> while executing
>> "macports::selfupdate [array get global_options] base_updated"
>> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
>> MacPorts base: shell command failed (see log for details)
> 
> That portion of the error doesn't tell us anything other than something went 
> wrong. If you check back further in the log, was it the same "Could not find 
> a working Foundation implementation" error?

Aaaargh hangs head in shame! I had not reinstalled Xcode.

So
Reinstall OS
install Xcode

Everything running sweetly again.
Thanks for all the help.
James
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Debian-like rename utility - available via MacPorts?

[Sam Kuper]

Dear all,

If I'm not mistaken, in Debian Linux (& Ubuntu, etc), there is a
"rename" utility, which I think comes from Debian's Perl package. It
allows file renaming using regular expressions, as described in Jens
Dreger's post here[1].

Apparently it (or something very much like it) is now available for
Mac users via Brew.[2]

However, I'm not a Brew user, I'm a MacPorts user. Please can you tell
me if this utility is available via MacPorts?

The closest I've found so far is "renameutils", which IMO doesn't
offer anything like the same ease of use, and isn't what I'm looking
for at all.

I haven't yet tried installing any of MacPorts's Perl packages,
because in order to exhaustively check all of them for whether they
include the "rename" utility, I'd potentially have to install several
of them!

In any case, it would be much better if MacPorts users could simply
get "rename" by running "port install rename" much as Brew users can
apparently get it by running "brew install rename"[2].

I did do a web search before posting this message and this topic
doesn't seem to have been discussed before, but if my google-fu failed
me and it *has* already been discussed, please feel free to point me
to the relevant discussion.

Thanks in advance for your comments and assistance,

Sam

[1] https://answers.launchpad.net/ubuntu/+source/nautilus/+question/2309
[2] 
http://superuser.com/questions/152627/renaming-many-files-in-mac-os-x-batch-processing
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: error using MacPorts zlib, not present with system zlib?

[Adam Mercer]

On Wed, Feb 22, 2012 at 15:50, Eric Cronin  wrote:

> I'm not near a Mac right now, but I believe the system version of zlib is
> pretty ancient.  In version 1.2.4 there was a "Wholesale replacement of gz*
> functions with faster versions" according to zlib.net, one of which I
> suspect was the replacement of the gzgetc() function with a macro.

Looks like it, Lion seems to have zlib 1.2.5 which has a standard
fucntion prototype for the gzgetc() function whereas 1.2.6 in MacPorts
gzgetc() is indeed a macro.

> C treats void* very unsafely, silently converting it to and from other
> pointer types whenever it knows how.  So converting the gzFile* gzopen()
> returned to the void* 'file' is legal.  Then, if gzgetc() is an actual
> function declared as 'char gzgetc(gzFile*)' the compiler will allow the
> void* be passed to the function, and within the function it is treated as a
> gzFile*.  But if gzgetc is just a macro the compiler doesn't know to convert
> 'file' to a gzFile*, so you get errors about trying to treat void as
> struct/union.  If the API said gzgetc took a void* they would fix this by
> casting "g" to a gzFile* inside the macro that replaced the function, but
> the API doesn't say this, and so the zlib authors don't... The current
> version is actually both faster and safer since it catches this type of
> void* abuse.
>
> So tldr answer: patch the port using libz to use a gzFile* or to cast the
> void* gack to a gzFile* before calling functions expecting a gzFile*.

I ended up applying a patch to the port that casts the void* pointer
to gzFile and that allows it to build, but the upstream developer
didn't like that approach. But this analysis is interesting and
imagine this build error will be seen on other platforms that have
zlib-1.2.6.

Thanks for the help.

Cheers

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

Re: error using MacPorts zlib, not present with system zlib?

[Eric Cronin]

On 22.02.2012 15:32, Adam Mercer wrote:

Hi

Not sure of the correct place to discuss this but in tracking down a
build issue with a port I've found an interesting issue with MacPorts
zlib.

This simple test code illustrates the problem:

[ram@mimir tmp]$ cat test.c
#include 
#include 
#include 

int main(void)
{
  void *file;





  c = gzgetc(file);


This code is wrong.  The zlib documentation says gzgetc takes a gzFile* 
not a void*.




Does anyone know why MacPorts zlib treats this as an error but the
system version doesn't?


I'm not near a Mac right now, but I believe the system version of zlib 
is pretty ancient.  In version 1.2.4 there was a "Wholesale replacement 
of gz* functions with faster versions" according to zlib.net, one of 
which I suspect was the replacement of the gzgetc() function with a 
macro.


C treats void* very unsafely, silently converting it to and from other 
pointer types whenever it knows how.  So converting the gzFile* gzopen() 
returned to the void* 'file' is legal.  Then, if gzgetc() is an actual 
function declared as 'char gzgetc(gzFile*)' the compiler will allow the 
void* be passed to the function, and within the function it is treated 
as a gzFile*.  But if gzgetc is just a macro the compiler doesn't know 
to convert 'file' to a gzFile*, so you get errors about trying to treat 
void as struct/union.  If the API said gzgetc took a void* they would 
fix this by casting "g" to a gzFile* inside the macro that replaced the 
function, but the API doesn't say this, and so the zlib authors don't... 
The current version is actually both faster and safer since it catches 
this type of void* abuse.


So tldr answer: patch the port using libz to use a gzFile* or to cast 
the void* gack to a gzFile* before calling functions expecting a 
gzFile*.


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

error using MacPorts zlib, not present with system zlib?

[Adam Mercer]

Hi

Not sure of the correct place to discuss this but in tracking down a
build issue with a port I've found an interesting issue with MacPorts
zlib.

This simple test code illustrates the problem:

[ram@mimir tmp]$ cat test.c
#include 
#include 
#include 

int main(void)
{
  void *file;
  int c;

  file = gzopen("test.dat.gz", "r");
  if (file == Z_NULL)
  {
fprintf(stderr, "unable to open file\n");
exit(1);
  }

  c = gzgetc(file);

  fprintf(stdout, "c = %c\n", c);

  gzclose(file);
}
[ram@mimir tmp]$ zcat test.dat.gz
test
file

If I compile this against the system zlib then it works as expected:

[ram@mimir tmp]$ clang -o test test.c -lz
[ram@mimir tmp]$ ./test
c = t

But not against the MacPorts zlib:

[ram@mimir tmp]$ clang -o test test.c -I/opt/local/include -L/opt/local/lib -lz
test.c:17:7: error: member reference base type 'void' is not a structure or
  union
  c = gzgetc(file);
  ^~~~
/opt/local/include/zlib.h:1655:11: note: instantiated from:
((g)->have ? ((g)->have--, (g)->pos++, *((g)->next)++) : gzgetc_(g))
 ~~~  ^
test.c:17:7: error: member reference base type 'void' is not a structure or
  union
  c = gzgetc(file);
  ^~~~
/opt/local/include/zlib.h:1655:24: note: instantiated from:
((g)->have ? ((g)->have--, (g)->pos++, *((g)->next)++) : gzgetc_(g))
  ~~~  ^
test.c:17:7: error: member reference base type 'void' is not a structure or
  union
  c = gzgetc(file);
  ^~~~
/opt/local/include/zlib.h:1655:37: note: instantiated from:
((g)->have ? ((g)->have--, (g)->pos++, *((g)->next)++) : gzgetc_(g))
   ~~~  ^
test.c:17:7: error: member reference base type 'void' is not a structure or
  union
  c = gzgetc(file);
  ^~~~
/opt/local/include/zlib.h:1655:51: note: instantiated from:
((g)->have ? ((g)->have--, (g)->pos++, *((g)->next)++) : gzgetc_(g))
 ~~~  ^
4 errors generated.
[ram@mimir tmp]$

Does anyone know why MacPorts zlib treats this as an error but the
system version doesn't?

Cheers

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

Re: Still no Universal variant for NSS?

[Ryan Schmidt]

On Feb 21, 2012, at 12:38, Greg Earle wrote:

> I wanted to update WINE-devel via MacPorts but was told my ports were out of 
> date when I ran "sudo port update wine-devel".
> 
> I've migrated my system from a 32-bit (only) old MacBook Pro to a 
> present-model Mac Pro running in full 64-bit mode.
> 
> When I ran "sudo port selfupdate" it converted me from 1.9.2 to 2.0.3.  (Oops)

Why "oops"? That's what "selfupdate" is supposed to do -- update MacPorts base 
to the latest version, and update your portfile definitions.

MacPorts 2 was released a long time ago. In the future, please do not wait so 
long to selfupdate.


> I soon had problems with programs crashing so I said the heck with it and 
> reinstalled 2.0.3 from DMG.

Indeed; the migration instructions state that you must reinstall MacPorts and 
all ports when you migrate to a new machine with a different OS version or 
processor architecture.


> I then decided to try the
> 
> sudo port -qv installed > /tmp/installed_ports.txt
> sudo port -fp uninstall --follow-dependents installed
> sudo port clean all
> curl -O 
> http://svn.macports.org/repository/macports/contrib/restore_ports/restore_ports.tcl
> chmod +x restore_ports.tcl
> sudo ./restore_ports.tcl /tmp/installed_ports.txt
> 
> method described in the migration FAQ.

Right, that should reinstall all your ports.


> It was humming along quite nicely until it got to "xulrunner":
> 
> --
> [...]
> --->  Activating libcanberra @0.28_0+universal
> --->  Cleaning libcanberra
> Error: Cannot install xulrunner for the arch(s) 'i386' because
> Error: its dependency nss is only installed for the arch 'x86_64'
> Error: and does not have a universal variant.
> architecture mismatch
>while executing
> "macports::_upgrade_mport_deps $mport $target"
>(procedure "mportexec" line 33)
>invoked from within
> "mportexec $workername $install_target"
> Unable to execute target 'install' for port 'xulrunner': architecture mismatch
>while executing
> "install_ports $operationList"
>(file "./restore_ports.tcl" line 269)
> 
> [21:39] nightowl:/tmp % sudo port installed nss
> Password:
> The following ports are currently installed:
>  nss @3.13.1_0 (active)
> 
> [21:47] nightowl:/tmp % lipo -info /opt/local/lib/nss/libnss3.dylib
> Non-fat file: /opt/local/lib/nss/libnss3.dylib is architecture: x86_64
> 
> [21:47] nightowl:/tmp % grep firefox /tmp/installed_ports 
>  firefox-x11 @3.6.13_0 platform='darwin 10' archs='i386'
>  firefox-x11 @3.6.15_0 platform='darwin 10' archs='i386'
>  firefox-x11 @3.6.16_0 (active) platform='darwin 10' archs='i386'
> 
> [21:48] nightowl:/tmp % sudo port installed firefox
> None of the specified ports are installed.
> 
> [21:48] nightowl:/tmp % sudo port installed firefox-x11
> None of the specified ports are installed.
> 
> [21:48] nightowl:/tmp % sudo port installed firefox-x11-devel
> None of the specified ports are installed.
> --
> 
> This looks suspiciously like Ticket #23424 - nss: add universal variant and 
> support for build_arch
> 
> https://trac.macports.org/ticket/23424
> 
> which looks like a 2-year-old ticket that has had no fix/movement on in well 
> over a year.
> 
> Am I hosed?
> 

> Should I try 'cheating' and change the "firefox-x11" to "firefox-x11-devel" 
> in my "installed_ports.txt" file and run it again?


The current version of the firefox-x11 port does not appear to have a 
dependency on nss or xulrunner so try removing those from your 
installed_ports.txt.

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

Re: gcc et al without XCode

[Ryan Schmidt]

On Feb 21, 2012, at 11:08, Craig Treleaven wrote:

> Haven't tried it, but Apple has released a new package that installs Apple's 
> tools and SDK's without having to download and install the full XCode app.
> 
> http://www.kennethreitz.com/xcode-gcc-and-homebrew.html

Yes they have. But as always, MacPorts will require both those and Xcode; we're 
not changing that.


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

Re: Help please

[Ryan Schmidt]

On Feb 21, 2012, at 22:44, James Linder wrote:

 checking for Apple Objective-C runtime... yes
 checking for GNU Objective C runtime... no
 configure: Using Apple Objective-C runtime
 checking for Apple Foundation library... no
 configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your 
 environment, preventing the use of GNUstep's Foundation library
 configure: error: Could not find a working Foundation implementation
>>> 
>>> This is an error we've encountered a few times before, such as:
>>> 
>>> https://trac.macports.org/ticket/28452
>>> 
>>> https://trac.macports.org/ticket/30298
>>> 
>>> We didn't receive further feedback from the reporters so were unable to 
>>> pursue the matter further. Can you attach your config.log? Maybe it will 
>>> shed further light.
>>> 
>>> In #28452 we presumed software installed in /usr/local was interfering. Do 
>>> you have anything installed in /usr/local? If so, remove it and try again.
>>> 
>>> In #30298 we presumed the user's operating system components had become 
>>> damaged and the OS should be reinstalled. So that's another avenue you 
>>> could pursue.
>> 
>> haycorn:~ # ls /usr/local
>> .git Library etc share
>> .gitignore   README.md   include texlive
>> Cellar   bin lib
>> 
>> This was put here by latex install ...
>> 
>> haycorn:~ # mv /usr/local/ /usr/oldlocal
>> haycorn:~ # port -d selfupdate
>> [snip]
>> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
>> MacPorts base: shell command failed (see log for details)
>> 
>> OK it'll take me a day or so to backup everything I want, so reinstall 
>> (which will certainly work, it did work before) and I'll report back
> 
> Snow Leopard and install CD: Insert CD 'Instal Mac OS X': whirr whirr (1 
> hour) {but this way is very easy)
> 
> then
> 
> ...
> DEBUG: Error installing new MacPorts base: shell command failed (see log for 
> details)
>  while executing
> "macports::selfupdate [array get global_options] base_updated"
> Error: /opt/local/bin/port: port selfupdate failed: Error installing new 
> MacPorts base: shell command failed (see log for details)

That portion of the error doesn't tell us anything other than something went 
wrong. If you check back further in the log, was it the same "Could not find a 
working Foundation implementation" error?


> OK next I'll format the disk then install and report

I would not have suggested that as the next step, but then again I have no 
further suggestions, so if you do this, let us know if it helps.


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

Re: problem to install apr-util in OSX 10.8?

[Ryan Schmidt]

On Feb 22, 2012, at 10:08, Giovanni Lovato wrote:

> Jeremy Lavergne wrote:
> 
>>> Log for apr-util is at: /opt/local/var/macports/logs/.../apr-util/main.log
>> 
>> We cannot help you without this log file.
> 
> I have the same issue with OS X 10.8, XCode 4.4, fresh MP trunk install:

Most of us do not have the pre-releases of OS X 10.8 or Xcode 4.4, and you may 
be prohibited from discussing it publicly due to your non-disclosure agreement.

> building apr-util fails on
> 
> :info:build /bin/sh /opt/local/share/apr-1/build/libtool --silent --mode=link
> /usr/bin/clang -pipe -O2 -arch x86_64   -L/opt/local/lib -arch x86_64
> -L/opt/local/lib/db46 -L/opt/local/lib -release 1 -module -rpath
> /opt/local/lib/apr-util-1 -o dbd/apr_dbd_sqlite3.la dbd/apr_dbd_sqlite3.lo
> -L/opt/local/lib  -lsqlite3
> :info:build clang: error: unable to execute command: Segmentation fault: 11
> :info:build clang: error: linker command failed due to signal 2 (use -v to
> see invocation)
> 
> Here's the full log: http://pastebin.com/0fMbwTSP 

The full error message reads:

:info:build clang: error: unable to execute command: Segmentation fault: 11
:info:build clang: error: linker command failed due to signal 2 (use -v to see 
invocation)
:info:build clang: note: diagnostic msg: Please submit a bug report to 
http://developer.apple.com/bugreporter/ and include command line arguments and 
all diagnostic information.
:info:build clang: note: diagnostic msg: Error generating preprocessed 
source(s) - cannot generate preprocessed source with multiple -arch options.

So please do that.

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

Re: clamav and bzip2

[John Brown]

Daniel J. Luke wrote:

On Feb 22, 2012, at 2:29 AM, John Brown wrote:
  

Warning: The installed version of Xcode (2.3) is known to cause problems. 
Version 2.5 or later is recommended on Mac OS X 10.4.



this warning is printed for a reason, you should upgrade Xcode.

  

--->  Verifying checksum(s) for bzip2
Error: Checksum (md5) mismatch for bzip2-1.0.6.tar.gz
Error: Checksum (sha1) mismatch for bzip2-1.0.6.tar.gz
Error: Checksum (rmd160) mismatch for bzip2-1.0.6.tar.gz
***
The non-matching file appears to be HTML. See this page for possible reasons
for the checksum mismatch:

***



This message is also printed for a reason, did you follow that link and read what was there? 


--
Daniel J. Luke   
++
| * dl...@geeklair.net * |  
| *-- http://www.geeklair.net -* |  
++
|   Opinions expressed are mine and do not necessarily   |  
|  reflect the opinions of my employer.  |  
++





  

Yes, I followed the link.

Shalom,

John B Brown
j...@vcn.com
358 High Street
Buffalo, Wyoming
82834

"Freedom is not worth having if it does not include
the freedom to make mistakes" Mahatma Gandhi
"There was never a good war, or a bad peace."
Benjamin Franklin
"I wonder whether the world is being run
by smart people who are putting us on
or by imbeciles who really mean it." Mark Twain

1-307-684-9068


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

Re: problem to install apr-util in OSX 10.8?

[Giovanni Lovato]

Jeremy Lavergne  lavergne.gotdns.org> writes:

> 
> > Log for apr-util is at: /opt/local/var/macports/logs/.../apr-util/main.log
> 
> We cannot help you without this log file.

I have the same issue with OS X 10.8, XCode 4.4, fresh MP trunk install:
building apr-util fails on

:info:build /bin/sh /opt/local/share/apr-1/build/libtool --silent --mode=link
/usr/bin/clang -pipe -O2 -arch x86_64   -L/opt/local/lib -arch x86_64
-L/opt/local/lib/db46 -L/opt/local/lib -release 1 -module -rpath
/opt/local/lib/apr-util-1 -o dbd/apr_dbd_sqlite3.la dbd/apr_dbd_sqlite3.lo
-L/opt/local/lib  -lsqlite3
:info:build clang: error: unable to execute command: Segmentation fault: 11
:info:build clang: error: linker command failed due to signal 2 (use -v to
see invocation)

Here's the full log: http://pastebin.com/0fMbwTSP 

And clang version:
$ clang -v
Apple clang version 4.0 (tags/Apple/clang-418.0.46) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.0.0
Thread model: posix

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

Re: clamav and bzip2

[Daniel J. Luke]

On Feb 22, 2012, at 10:11 AM, John Brown wrote:
> Error: On Mac OS X 10.4, zlib 1.2.6 requires Xcode 2.4.1 or later but you 
> have Xcode 2.3.
> Error: See http://guide.macports.org/chunked/installing.xcode.html for 
> download links.
> Error: Target org.macports.extract returned: incompatible Xcode version
> Error: Failed to install zlib

Did you follow that link? The guide has a link specifically for you to get the 
latest Xcode for 10.4 (guide section 2.2.3)

--
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: clamav and bzip2

[Jeremy Lavergne]

>   Having performed software update a number of times what else must I do? Is 
> a later Xcode archived?

From:
http://guide.macports.org/#installing.xcode

Always make sure to install the latest available version of Xcode for your Mac 
OS X release (with the exception of Xcode 4.3, for now); using outdated 
versions of Xcode may cause port install failures. Also note that Xcode is not 
updated via Mac OS X's Software Update utility on OS versions prior to 10.6, 
and is updated via the Mac App Store on 10.7.

You can find all Xcode downloads through connect.apple.com.



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: clamav and bzip2

[John Brown]

Jeremy Lavergne wrote:

***
The non-matching file appears to be HTML. See this page for possible reasons
for the checksum mismatch:

***



Sounds like you've been downloading web pages instead of source for packages.

Consider wiping out these downloads and trying again, and possibly getting 
online through a different network.

sudo port clean --dist PACKAGES

  
   The command worked. I installed bzip2 successfully. Now a different 
problem arises:


jbb@pinball2:~
(4): % sudo port -s install clamav
Warning: The installed version of Xcode (2.3) is known to cause 
problems. Version 2.5 or later is recommended on Mac OS X 10.4.

--->  Computing dependencies for clamav
--->  Dependencies to be installed: zlib
--->  Fetching zlib
--->  Attempting to fetch zlib-1.2.6.tar.bz2 from 
http://distfiles.macports.org/zlib

--->  Verifying checksum(s) for zlib
--->  Extracting zlib
Error: On Mac OS X 10.4, zlib 1.2.6 requires Xcode 2.4.1 or later but 
you have Xcode 2.3.
Error: See http://guide.macports.org/chunked/installing.xcode.html for 
download links.

Error: Target org.macports.extract returned: incompatible Xcode version
Error: Failed to install zlib
Log for zlib is at: 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_archivers_zlib/zlib/main.log

Error: The following dependencies were not installed: zlib
Error: Status 1 encountered during processing.
To report a bug, see 
jbb@pinball2:~
(5): %

   Having performed software update a number of times what else must I 
do? Is a later Xcode archived?


Shalom,

John B Brown
j...@vcn.com
358 High Street
Buffalo, Wyoming
82834

"Freedom is not worth having if it does not include
the freedom to make mistakes" Mahatma Gandhi
"There was never a good war, or a bad peace."
Benjamin Franklin
"I wonder whether the world is being run
by smart people who are putting us on
or by imbeciles who really mean it." Mark Twain

1-307-684-9068


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

Re: clamav and bzip2

[Daniel J. Luke]

On Feb 22, 2012, at 2:29 AM, John Brown wrote:
> Warning: The installed version of Xcode (2.3) is known to cause problems. 
> Version 2.5 or later is recommended on Mac OS X 10.4.

this warning is printed for a reason, you should upgrade Xcode.

> --->  Verifying checksum(s) for bzip2
> Error: Checksum (md5) mismatch for bzip2-1.0.6.tar.gz
> Error: Checksum (sha1) mismatch for bzip2-1.0.6.tar.gz
> Error: Checksum (rmd160) mismatch for bzip2-1.0.6.tar.gz
> ***
> The non-matching file appears to be HTML. See this page for possible reasons
> for the checksum mismatch:
> 
> ***

This message is also printed for a reason, did you follow that link and read 
what was there? 

--
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: clamav and bzip2

[Jeremy Lavergne]

> ***
> The non-matching file appears to be HTML. See this page for possible reasons
> for the checksum mismatch:
> 
> ***

Sounds like you've been downloading web pages instead of source for packages.

Consider wiping out these downloads and trying again, and possibly getting 
online through a different network.

sudo port clean --dist PACKAGES



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users