Posts Tagged ‘MacPorts’

Mittwoch, 31. August 2016

Xcode für die Verwendung mit MacPorts bereit machen

Bevor man anfängt, mit MacPorts Pakete zu kompilieren, muss man Apples Xcode installieren.

Damit ist es aber noch nicht getan — einerseits gehören die Command Line Tools installiert:

$ xcode-select --install

Quelle: How to Install Command Line Tools in OS X Mavericks & Yosemite (Without Xcode)

Anschliessend muss man noch die Lizenzbestimmungen abnicken:

# xcodebuild -license accept

Tags: , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Montag, 29. August 2016

MacPorts kann spidermonkey und mozjs17 nicht installieren

Nach meiner kürzlichen Migration auf OS X El Capitan habe ich noch mit den einen oder anderen Kinderwehen zu kämpfen.

Unter anderem bringt es MacPorts nicht fertig, die Pakete spidermonkey und mozjs17 zu installieren.

Die Fehlermeldungen lauteten:

--->  Building spidermonkey
Error: org.macports.build for port spidermonkey returned: command execution failed
Please see the log file for port spidermonkey for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_spidermonkey/spidermonkey/main.log
Error: Unable to upgrade port: 1
Error rebuilding spidermonkey
    while executing
"error "Error rebuilding $portname""
    (procedure "revupgrade_scanandrebuild" line 395)
    invoked from within
"revupgrade_scanandrebuild broken_port_counts $opts"
    (procedure "macports::revupgrade" line 5)
    invoked from within
"macports::revupgrade $opts"
    (procedure "action_revupgrade" line 2)
    invoked from within
"action_revupgrade $action $portlist $opts"
    (procedure "action_upgrade" line 25)
    invoked from within
"$action_proc $action $portlist [array get global_options]"
    (procedure "process_cmd" line 103)
    invoked from within
"process_cmd $remaining_args"
    invoked from within
"if { [llength $remaining_args] > 0 } {

    # If there are remaining arguments, process those as a command
    set exit_status [process_cmd $remaining..."
    (file "/opt/local/bin/port" line 5268)
Done.

Die Datei /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_spidermonkey/spidermonkey/main.log enthält über 9000 Zeilen, doch schlussendlich fand ich die aussagekräftigsten Stellen:

:debug:archivefetch Found Dependency: receipt exists for nspr
...
:info:build cat: ../../dist/Darwin_OPT.OBJ/nspr/Version: No such file or directory

… sowie viel weiter unten …

:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[1]: *** [Darwin_OPT.OBJ/libjs.dylib] Error 1

Nach einigem herumgoogeln (das Problem ist im Netz nirgends erwähnt; es handelt sich also um ein ganz spezifisches Aeby-Problem) stiess ich auf den über sechs Jahre alten Fehlerreport Spidermonkey build failure (undefined symbols) with non-default build_arch.

Irgendwie schien mein spidermonkey Symbole für die x86_64-Architektur nicht zu finden, und vielleicht hing dies ja mit einer Einstellung in macports.conf zusammen.

Und siehe da:

/opt/local/etc/macports$ ls -l
total 112
-rw-r--r--  1 root  admin  1941 17 Mai  2014 archive_sites.conf
-r--r--r--  1 root  admin  1941  1 Okt  2015 archive_sites.conf.default
-rw-r--r--  1 root  admin  8251 17 Mai  2014 macports.conf
-r--r--r--  1 root  admin  8248  1 Okt  2015 macports.conf.default
-rw-r--r--  1 root  admin   523 17 Mai  2014 pubkeys.conf
-r--r--r--  1 root  admin   523  1 Okt  2015 pubkeys.conf.default
-rw-r--r--  1 root  admin  1243 17 Mai  2014 sources.conf
-r--r--r--  1 root  admin  1243  1 Okt  2015 sources.conf.default
-rw-r--r--  1 root  admin   461 17 Mai  2014 variants.conf
-r--r--r--  1 root  admin   461  1 Okt  2015 variants.conf.default

Ich hatte offenbar noch eine uralte macports.conf herumliegen, und aus irgendeinem Grund wurde bei einem Upgrade die neuere Version der Datei (.default) nicht über die Alte kopiert. Doch was ist der Unterschied zwischen den beiden Dateien?

$ diff macports.conf.default macports.conf 
1c1
< # $Id: macports.conf.in 117120 2014-02-17 00:55:33Z jmr@macports.org $
---
> # $Id: macports.conf.in 108047 2013-07-11 06:19:13Z larryv@macports.org $
63c63
< # "x86_64 i386" on OS X 10.6 and later.
---
> # "x64_64 i386" on OS X 10.6 and later.

Ein Schreibfehler! Es hätte heissen sollen „x86_64“, stattdessen aber hatte wohl jemand in aller Flüchtigkeit „x64_64“ geschrieben. Ich löschte die alte Datei und platzierte die neue Datei an ihrer Stelle.

Als nächstes installierte ich npsr erneut …

# port install nspr

… welches im gleichen Rutsch eine ganze Ladung Dependencies ebenfalls aktualisierte (unter anderem GTK3, welches mörderisch lange zum kompilieren braucht).

Schlussendlich führte ich ein ordentliches MacPorts-Update aus:

# port selfupdate
# port upgrade outdated
# port uninstall inactive
# port clean --all vile

Fertig.

Tags: , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. August 2016

launchd vergisst nach Upgrade auf OS X El Capitan die Pfade (PATH)

Dies ist bei mir ganz kritisch, da meine Scripts auf viele MacPorts-Tools angewiesen sind — unter anderem realpath, wget sowie curlftpfs.

Abhilfe schafft man folgendermassen:

~/Library/LaunchAgents/com.emeidi.environment.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>my.startup</string>
  <key>ProgramArguments</key>
  <array>
    <string>sh</string>
    <string>-c</string>
    <string>launchctl setenv PATH /opt/local/bin:/opt/local/sbin:$PATH</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

Quelle: Setting the system-wide PATH environment variable in Mavericks

Anschliessend startet man den „Job“:

$ launchctl load ~/Library/LaunchAgents/com.emeidi.environment.plist

Tags: , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Samstag, 27. August 2016

Eine MacPorts-Variante installieren

Wenn MacPorts folgende oder ähnliche Fehler meldet …

--->  Computing dependencies for jslint
--->  Configuring jslint
Error: You need to install spidermonkey with the +fileobject variant in order to use jslint.
Error: org.macports.configure for port jslint returned: incompatible spidermonkey installation
Please see the log file for port jslint for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_jslint/jslint/main.log

installiert man die geforderte Variante folgendermassen:

# port install spidermonkey +fileobject

Quelle: 3.2. Port Variants

Tags: , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Samstag, 2. April 2016

monit mit MacPorts unter OS X El Capitan installieren (mit angeblich fehlenden OpenSSL-Headern)

Vor einigen Tagen habe ich mich entschieden, mein MacBook Air (Late 2010) komplett platt zu machen und OS X El Capitan darauf zu installieren.

Nach der Neuinstallation musste ich auch alle meine MacPorts-Packages neu installieren. Leider gab es Probleme bei der Installation des Pakets monit:

$ sudo port install monit
Password:
---> Computing dependencies for monit
---> Configuring monit
Error: Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log
Error: org.macports.configure for port monit returned: configure failure: command execution failed
Please see the log file for port monit for details:
   /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log
To report a bug, follow the instructions in the guide:
   http://guide.macports.org/#project.tickets
Error: Processing of port monit failed

Ein Blick in /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log zeigte folgende detailliertere Fehlermeldung:

...
:info:configure checking for static SSL support... disabled
:info:configure checking for SSL support... enabled
:info:configure checking for SSL include directory... Not found
:info:configure 
:info:configure Couldn't find your SSL header files.
:info:configure Use --with-ssl-incl-dir option to fix this problem or disable
:info:configure the SSL support with --without-ssl
:info:configure 
:info:configure Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1" && ./configure --prefix=/opt/local 
:info:configure Exit code: 1
:error:configure Failed to configure monit, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/work/monit-5.12.1/config.log
:error:configure org.macports.configure for port monit returned: configure failure: command execution failed
:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
   while executing
"portconfigure::configure_main org.macports.configure"
   ("eval" body line 1)
   invoked from within
"eval $procedure $targetname"
:info:configure Warning: targets not executed for monit: org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install
:notice:configure Please see the log file for port monit for details:
   /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_monit/monit/main.log

Der relevante Teil des Logs:

...
:info:configure Couldn't find your SSL header files.
:info:configure Use --with-ssl-incl-dir option to fix this problem or disable
:info:configure the SSL support with --without-ssl
...

MacPorts openssl war aber installiert und die Header-Files fanden sich im Pfad /opt/local/include/openssl. Den Pfad hatte ich mit einer Suche nach ssl.h ausgemacht.

Nach mehr als einer Stunde Google-Suche war ich immer noch nicht weiter. Da kam mir der Geistesblitz: Das configure-Script von monit wird die SSL-Headers wohl im Standardverzeichnis suchen. Offenbar gibt es dieses Verzeichnis nicht, weshalb die Installation scheitert … wenn ich aber herausfinde, wie das Standardverzeichnis lautet, kann ich dieses mit einem Symlink auf das MacPorts-Verzeichnis umbiegen und die Installation sollte durchlaufen.

Gesagt, getan. Als erstes startete ich in einem Terminal-Fenster die Installation von monit:

$ sudo port install monit

In einem zweiten Tab führte ich dann folgenden Befehl aus, um alle Zugriffe auf das Dateisystem zu loggen:

$ sudo fs_usage

Nachdem das Tab mit dem MacPorts-Befehl wieder „bash“ als Titel anzeigte, stoppte ich fs_usage mit Ctrl-C. Anschliessend kopierte ich den ganzen Text in eine Textdatei, speicherte diese auf dem Desktop ab und begann, den Text zu greppen.

Ganz am Schluss der Aktivitäten kam heraus:

...
18:17:53  stat64            /usr/include/sys/_pthread/_pthread_key_t.h                                 0.000008   clang       
18:17:53  stat64            /usr/include/sys/_types/_fsblkcnt_t.h                                      0.000008   clang       
18:17:53  stat64            /usr/include/sys/_types/_fsfilcnt_t.h                                      0.000008   clang       
18:17:53  stat64            /opt/local/include                                                         0.000013   clang       
18:17:53  stat64            /usr/local/include                                                         0.000005   clang       
18:17:53  stat64            /usr/local/include                                                         0.000004   clang       
18:17:53  stat64            /Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.3.0/include    0.000013   clang       
18:17:53  stat64            .app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include    0.000007   clang       
18:17:53  stat64            /usr/include                                                               0.000005   clang

/usr/local/include tönte vielversprechend nach einem Standardpfad … und Bingo:

$ cd /usr/local/include
-bash: /usr/local/include: No such file or directory

Tönt wie ein Volltreffer. Dann versuchen wir es doch einmal damit:

$ sudo mkdir /usr/local/include
$ cd /usr/local/include
$ sudo ln -s /opt/local/include/openssl .

Alles bereit für den Versuch? Dann los — et voilà:

$ sudo port install monit
--->  Computing dependencies for monit
--->  Configuring monit
--->  Building monit
--->  Staging monit into destroot
--->  Creating launchd control script
###########################################################
# A startup item has been generated that will aid in
# starting monit with launchd. It is disabled
# by default. Execute the following command to start it,
# and to cause it to launch at startup:
#
# sudo port load monit
###########################################################
--->  Installing monit @5.12.1_1
--->  Activating monit @5.12.1_1
--->  Cleaning monit
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.

Die Jungs von homebrew haben die Problematik übrigens direkt im config-File gefixt, und zwar mit dem Parameter --with-ssl-dir, welches auf den openssl-Pfad zeigt:

...
def install
    system "./configure", "--prefix=#{prefix}",
                          "--localstatedir=#{var}/monit",
                          "--sysconfdir=#{etc}/monit",
                          "--with-ssl-dir=#{Formula["openssl"].opt_prefix}"
    system "make", "install"
    (share/"monit").install "monitrc"
...

Quelle: homebrew/monit.rb at master

Tags: , , , , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 29. Oktober 2015

MacPorts kann das Paket openmotif nicht installieren

Beim monatlichen Update meiner MacPorts-Installation stand ich vor folgender Fehlermeldung:

--> Fetching archive for openmotif
Error: org.macports.archivefetch for port openmotif returned: xorg-libXt must be installed with +flat_namespace.
Please see the log file for port openmotif for details:
   /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_openmotif/openmotif/main.log
To report a bug, follow the instructions in the guide:
   http://guide.macports.org/#project.tickets
Error: Processing of port openmotif failed
Done.

Eine kurze Google-Suche förderte folgenden Diskussions-Thread zu Tage:

openmotif: xorg-libXt must be installed with +flat_namespace

Folgende lokal ausgeführten Befehle lösten das Problem:

# port install xorg-libXt +flat_namespace

Nachdem das neue Paket installiert war, musste ich dieses noch aktivieren, damit es beim Update von openmotif auch effektiv zur Verfügung stand:

# port activate xorg-libXt @1.1.5_1+flat_namespace

Anschliessend konnte ich mit der Aktualisierung fortfahren.

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 30. April 2015

Unter OS X mit MacPorts die xpdf-tools sowie poppler installieren

MacPorts präsentierte mir bei der Installation des Pakets poppler folgende Fehlermeldung:

Unable to execute port: Can’t install poppler because conflicting ports are installed: xpdf

Wie löst man dieses Problem? Als erstes deaktiviert man allfällige, bereits vorhandene OSS-Pakete mit PDF-Funktionalitäten:

# port deactivate xpdf-tools xpdf

Anschliessend installiert man die xpdf-Tools derart neu, dass auch poppler mitkommt:

# port install xpdf +with_poppler

Quelle: Please Help – can’t install ufraw

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 26. März 2015

monit unter Mac OS X neu starten

Vor einigen Tagen meldete mir die monit-Instanz aus einem anderen Subnet, dass die Web-Oberfläche der monit-Instanz auf meinem Mac mini nicht mehr ansprechbar war. Heute, nach unzähligen Warnmeldungen, habe ich mich um das Problem gekümmert.

Wie sich herausstellte, liess sich das Problem beheben, indem ich monit schlicht neu startete. Auf der Mac OS X-Kommandozeile geht dies so:

$ sudo launchctl unload /Library/LaunchDaemons/com.tildeslash.monit.daemon.plist
$ sudo launchctl load /Library/LaunchDaemons/com.tildeslash.monit.daemon.plist

Via: Monit

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 22. Februar 2015

ogv mit ffmpeg zu mp4 konvertieren

Das geht bei mir unter Mac OS X mit MacPorts und ffmpeg in der Version 2.5.3 folgendermassen:

$ ffmpeg -i "Selectric.ogv" -acodec aac -strict -2 -aq 80 -vcodec libx264 -preset slow -crf 25 -threads 0 "Selectric.mp4"

Via: ffmpeg unkown libfaac ubuntu 14.04

Obwohl ffmpeg folgende Fehlermeldungen ausspuckt, kann ich das Video anschliessend schauen:

[ogg @ 0x7f9884026c00] Broken file, keyframe not correctly marked.

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 6. März 2014

rsync braucht unter Mac OS X ewig für „building file list…“

rsync ist das Tool meiner Wahl, um meine Backups auf mein Synology NAS im LAN sowie per WAN auf einen Linux-Server im Elternhaus zu spiegeln. Doch aufgepasst: Wer sich seit jeher daran stört, dass die Backup-Scripts bei hunderttausenden Dateien eine Ewigkeit bei „building file list…“ stehen bleiben, sei folgender Rat gegeben:

Man sollte unbedingt eine aktuelle Version von rsync – mindestens aber Version 3 – verwenden. Bis und mit Mac OS X 10.8 liefert Apple Version 2.6 mit, welche in dieser Hinsicht noch nicht optimiert wurde: Version 2 liest zuerst alle Dateien des Quellverzeichnis ein, während Version 3 nach den ersten 1000 Dateien (oder so) mit dem Backup beginnt und die verbleibenden Dateien anschliessend päckchenweise (nach Bedarf, basierend auf der Backup-Geschwindigkeit), einliest. Diese Massnahme verringert nebenbei auch gerade den RAM-Bedarf des Tools.

Version 3 ist auf meinem System über MacPorts installiert:

# port install rsync

Damit man auch wirklich sicher ist, dass in den eigenen Backup-Scripts Version 3 und nicht Version 2 verwendet wird, sollte man den rsync-Pfad in Scripts hardkodieren:

#RSYNC=$(which rsync)
RSYNC="/opt/local/bin/rsync/"

Um während der Ausführung eines Scripts zu prüfen, ob Version 3 des Tools verwendet wird, empfiehlt es sich, rsync das Argument --info=progress2 mitzugeben. In diesem Fall wird jede Datei, die kopiert wird, auf einer neuen Zeile ausgegeben. Neben dessen Grösse, dem Netzwerk-Durchsatz und der Transfergeschwindigkeit auf das Zielmedium steht ganz am Ende der Zeile einerseits xfr für die fortlaufende Nummer aller übertragender Dateien und Ordner sowie to-chk, die Zahl der bereits überprüften Dateien vom (provisorischen) Total aller Dateien. to-chk wird sich während der Laufzeit des Scripts sequentiell erhöhen.

$ rsync -av --info=progress2 . /mnt/backup/2014-03-06/
... 1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen