@tryge wenn du damit einverstanden bist würde ich das übernehmen
Bitte fahre fort!
Wie in #1184 besprochen, wäre es auch schön, Mac OS X-Binärdateien mit Travis zu erstellen.
Aber das Hinzufügen von Homebrew Formula hat die höchste Priorität, ich hoffe, jemand mit einem Mac kann dies aufgreifen!
Ich habe eine Homebrew-Formel und einen Tap für Elektra erstellt.
@markus2330 Ich habe das Repo an dich übertragen, Markus, da ich den Administratorstatus benötigt hätte, um das Repo zur Organisation ElektraInitiative zu verschieben. Können Sie das Repository bitte von Ihrem persönlichen Konto zur ElektraInitiative-Organisation verschieben?
Ich habe eine Homebrew-Formel und einen Tap für Elektra erstellt.
Danke, das ist wirklich toll!
Enthält es auch Binärpakete für die neueste Version?
Ich habe das Repo an dich übertragen, Markus, da ich den Administratorstatus benötigt hätte, um das Repo zur Organisation ElektraInitiative zu verschieben. Können Sie das Repository bitte von Ihrem persönlichen Konto zur ElektraInitiative-Organisation verschieben?
Entschuldigung, wo kann ich es finden? In https://github.com/sanssecours/homebrew-elektra fehlt mir der Button „Einstellungen“ (der zum Übertragen nötig wäre).
Warum nicht einfach klonen? (Oder neu erstellen, indem Sie dieselben Commits hineinschieben)
Übrigens. Ist es möglich, diese Formel auch stromaufwärts zum Brauen zu bringen?
@omnidan Kannst du testen, ob der Zapfhahn/die Flasche auch bei dir funktioniert?
Sollten wir Probleme mit dem Zapfhahn/der Flasche hier oder unter erstellen
https://github.com/ElektraInitiative/homebrew-elektra?
Enthält es auch Binärpakete für die neueste Version?
Noch nicht, das Erstellen eines Binärpakets scheint jedoch nicht so schwierig zu sein . Ich werde mal schauen.
Entschuldigung, wo kann ich es finden? In https://github.com/sanssecours/homebrew-elektra fehlt mir der Button „Einstellungen“ (der zum Übertragen nötig wäre).
Vielen Dank für den Admin-Zugang. Ich habe gerade das Repo übertragen.
Übrigens. Ist es möglich, diese Formel auch stromaufwärts zum Brauen zu bringen?
Jawohl. Ich wollte das zuerst tun, aber soweit ich das beurteilen kann, sind die Homebrew-Entwickler ziemlich wählerisch in Bezug auf das, was sie akzeptieren . Vor allem der Text
Wir missbilligen es, wenn Autoren ihre eigene Arbeit einreichen, es sei denn, sie ist sehr beliebt.
klingt nach einem Problem.
Ich habe gerade das Repo übertragen.
Noch nicht, das Erstellen eines Binärpakets scheint jedoch nicht so schwierig zu sein. Ich werde mal schauen.
Danke!
Vielen Dank für den Admin-Zugang.
Bei Bedarf jederzeit wieder. Wir können auch über einen dauerhaften Administratorzugriff sprechen.
Jawohl. Ich wollte das zuerst tun, aber soweit ich das beurteilen kann, sind die Homebrew-Entwickler ziemlich wählerisch, was sie akzeptieren. Vor allem der Text
Es ist gut, wenn wir Feedback bekommen, auch wenn sie es nicht akzeptieren.
Wir missbilligen es, wenn Autoren ihre eigene Arbeit einreichen, es sei denn, sie ist sehr beliebt.
Ich verstehe diesen Satz, dass Sie kein Formular für Ihre eigene Arbeit (= von Ihnen alleine geschriebenes Repo) einreichen sollten. Dies ist hier kaum der Fall.
Ein binäres Homebrew-Paket (Flasche) ist jetzt verfügbar . Wenn jemand die Formel ausprobieren möchte, befolgen Sie bitte die folgenden Schritte.
brew doctor
aus und entfernen Sie alle Fragmente von Elektra, die der Befehl meldet.brew tap ElektraInitiative/homebrew-elektra
.brew install elektra
.brew install --build-from-source elektra
.brew install --HEAD elektra
.brew test elektra
verwenden.Es ist gut, wenn wir Feedback bekommen, auch wenn sie es nicht akzeptieren.
Hm, okay. Wenn ich Zeit habe, werde ich versuchen, morgen einen Pull-Request zu öffnen.
Das sind wieder tolle Neuigkeiten!
Können Sie die README.md des Homebrew-Elektra aktualisieren, um diese längere Beschreibung zu enthalten?
Haben Sie einige Build-Protokolle darüber, welche Plugins und Bindungen aktiviert sind? Insbesondere würde mich interessieren, ob die Python2-Bindungen enthalten sind (und funktionieren: können Sie versuchen, import kdb
in einem Python-Interpreter auszuführen)?
Können Sie die README.md des Homebrew-Elektra aktualisieren, um diese längere Beschreibung zu enthalten?
Okay, Sie können sich hier die aktualisierte ReadMe ansehen.
Haben Sie einige Build-Protokolle darüber, welche Plugins und Bindungen aktiviert sind?
Die Liste der Plugins sollte ziemlich umfangreich sein, da ich viele der optionalen Elektra-Abhängigkeiten auf meinem Computer installiert habe. Hier ist das Protokoll , das von brew install --build-from-source -debug -verbose elektra
erstellt wurde.
Insbesondere würde mich interessieren, ob die Python2-Bindungen enthalten sind (und funktionieren: können Sie versuchen,
import kdb
in einem Python-Interpreter zu verwenden)?
Sie sollten eingebunden werden (siehe Log oben), trotzdem meldet import kdb
den folgenden Fehler sowohl in der Systemversion von Python ( /usr/bin/python
) als auch in der per Homebrew installierten ( /usr/local/bin/python
):
import kdb
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named kdb
.
Okay, Sie können sich die aktualisierte ReadMe ansehen
Grosses Dankeschön!
Die Liste der Plugins sollte ziemlich umfangreich sein, da ich viele der optionalen Elektra-Abhängigkeiten auf meinem Computer installiert habe.
-DBINDINGS=ALL
benötigenkdb gen
würde Python-Geparden benötigen, um zu funktionieren, und --install-layout
. Scheint schwer zu beheben zu sein (lassen Sie das jetzt besser und deaktivieren Sie einfach gen von TOOLS).Sie sollten enthalten sein (siehe Protokoll oben)
Ich denke, Sie haben Python-Bindungen und Plugins verwechselt, die Bindungen sind nicht vorhanden (kein -- Include Binding swig_python2
).
- Ronn scheint zu fehlen (also keine Manpages)
Es scheint nur zu fehlen. Ich habe ronn
über rbenv installiert . Es sieht so aus, als ob die Homebrew-Umgebung einen anderen Wert für PATH
verwendet, der ~/.rbenv/shims
nicht enthält. Nach einiger Recherche habe ich einen Weg gefunden, ronn
als optionale Ruby- Abhängigkeit hinzuzufügen. Im Moment erkennt die Formel meine Installation von ronn
nicht. Hoffentlich finde ich eine Lösung für dieses Problem.
- Sie scheinen keine Bindung (außer cpp) einzuschließen, es scheint, als würden Sie
-DBINDINGS=ALL
benötigen
Sie haben recht, danke. Ich habe die Option zu den CMake-Argumenten der Formel hinzugefügt.
Ich denke, Sie haben Python-Bindungen und Plugins verwechselt, die Bindungen sind nicht vorhanden (kein
-- Include Binding swig_python2
).
Du hast wieder Recht :o). Ich werde später prüfen, ob die Bindungen funktionieren.
Ich habe hier ronn
als erforderliche Abhängigkeit für den Build-Prozess hinzugefügt. Ich denke nicht, dass es ein Problem ist, ronn
für den Build zu benötigen, da die meisten Leute sowieso nur die abgefüllte Version der Formel verwenden werden.
Sie fragen sich vielleicht, warum ich ronn
nicht als optionale Abhängigkeit hinzugefügt habe. Die Ursache dafür war die Ausgabe von brew info
, die irgendwie albern und auch super falsch aussieht, wenn ich das Tag :optional
hinzufüge:
…
==> Dependencies
Build: cmake ✔
==> Requirements
Build: ronn (ruby module) ✔
Optional: ronn (ruby module) ✔
==> Options
--with-languagemodule
Build with languagemodule support
…
. Der folgende Text zeigt die aktuelle Ausgabe von brew info elektra
:
elektrainitiative/elektra/elektra: stable 0.8.19 (bottled), HEAD
Configuration Framework
https://web.libelektra.org
Not installed
From: https://github.com/ElektraInitiative/homebrew-elektra/blob/master/Formula/elektra.rb
==> Dependencies
Build: cmake ✔
==> Requirements
Build: ronn (ruby module) ✔
.
Nachdem ich -DBINDINGS=ALL
zu den CMake-Optionen der Formel brew audit --strict elektra
hinzugefügt habe, wird folgende Meldung angezeigt (nachdem ich Elektra installiert habe):
elektrainitiative/elektra/elektra:
* python modules have explicit framework links
These python extension modules were linked directly to a Python
framework binary. They should be linked with -undefined dynamic_lookup
instead of -lpython or -framework Python.
/usr/local/Cellar/elektra/0.8.19/lib/python2.7/site-packages/_kdb.so
/usr/local/Cellar/elektra/0.8.19/lib/python3.5/site-packages/_kdb.so
Error: 1 problem in 1 formula
. Wenn ich import kdb
in der Hombrew-Version von Python versuche, stürzt der Python-Interpreter ab und zeigt die folgende Fehlermeldung an:
Fatal Python error: PyThreadState_Get: no current thread
fish: '/usr/local/bin/python' terminated by signal SIGABRT (Abort)
Dies scheint normal zu sein, da ninja test
– in meinem üblichen Build-Verzeichnis – ebenfalls fehlschlägt und die folgenden Fehler anzeigt:
31 - testpy2_kdb.py (OTHER_FAULT)
32 - testpy2_key.py (OTHER_FAULT)
33 - testpy2_keyset.py (OTHER_FAULT)
34 - test_kdb.py (OTHER_FAULT)
35 - test_key.py (OTHER_FAULT)
36 - test_keyset.py (OTHER_FAULT)
40 - testruby_kdb (OTHER_FAULT)
41 - testruby_key (OTHER_FAULT)
42 - testruby_keyset (OTHER_FAULT)
. Ich habe den folgenden Befehl verwendet, um das Ninja-Projekt zu generieren:
cmake .. \
-GNinja \
-DENABLE_TESTING=ON \
-DENABLE_DEBUG=ON \
-DENABLE_LOGGER=OFF \
-DBUILD_PDF=ON \
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
-DPDFLATEX_COMPILER=`which latexmk` \
-DPDFLATEX_COMPILER_OPTIONS='-pdf;-f;-quiet' \
-DCMAKE_PREFIX_PATH=/usr/local/opt/qt5 \
-DTOOLS=ALL \
-DBINDINGS=ALL
. Die Lua-Bindungen scheinen gut zu funktionieren. Mindestens require 'kdb'
zeigt keine Fehlermeldungen an.
Vielen Dank für Ihre Mühe!
Mannseiten
Ja, ich stimme zu, dass die Leute die Flaschenversion bevorzugen werden. Und keine Manpages zu haben, ist wirklich ein großes Usability-Problem, also ist die Anforderung angemessen.
Absturz von
import kdb
@manuelm lm hast du eine Idee warum die Bindungen abstürzen?
@sanssecours Vielleicht ist die Schluckversion zu alt oder ein falscher Schluck verwendet?
Sie sollten mit -undefined dynamic_lookup anstelle von -lpython oder -framework Python verknüpft werden.
Vielleicht sollten wir im Falle von APPLE einfach -framework
an target_link_libraries übergeben. Laut cmake docu scheint es eine Sonderbehandlung für -framework
zu geben.
Vielleicht ist die cmake-Datei für Python kaputt? Hier ist eine lange Diskussion über kaputte Python-CMake-Dateien. (Könnte aber nichts damit zu tun haben) Ich kann hier nicht wirklich helfen, das Problem ist ziemlich Mac OS X spezifisch.
@sanssecours Vielleicht ist die Schluckversion zu alt…
Nein, ich habe die neueste Version von swig
( 3.0.10
) über Homebrew installiert.
…, oder ein falscher Schluck verwendet?
Das glaub ich nicht. Bei der Schnellsuche über locate swig
wird nur die über Homebrew installierte Version angezeigt.
@markus2330 ja es geht! vielen Dank für die Homebrew-Formel, @sanssecours :ok_hand:
Ich hatte ein kleines Problem, aber das könnte daran liegen, dass sudo make uninstall
Elektra nicht sauber deinstalliert:
> brew install elektra
==> Installing elektra from elektrainitiative/elektra
==> Downloading https://github.com/ElektraInitiative/homebrew-elektra/releases/download/0.
==> Downloading from https://github-cloud.s3.amazonaws.com/releases/76387201/caf85aac-c307
######################################################################## 100.0%
==> Pouring elektra-0.8.19.sierra.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink share/elektra/test_data/lua/batterytotracker.lua
/usr/local/share/elektra/test_data/lua is not writable.
You can try again using:
brew link elektra
==> Summary
🍺 /usr/local/Cellar/elektra/0.8.19: 2,668 files, 54.1M
> brew link elektra
Linking /usr/local/Cellar/elektra/0.8.19...
Error: Could not symlink lib/elektra/libelektra-storage.so
Target /usr/local/lib/elektra/libelektra-storage.so
already exists. You may want to remove it:
rm '/usr/local/lib/elektra/libelektra-storage.so'
To force the link and overwrite all conflicting files:
brew link --overwrite elektra
To list all files that would be deleted:
brew link --overwrite --dry-run elektra
Nach dem Ausführen brew link --overwrite elektra
funktioniert es jedoch einwandfrei.
Wenn ich versuche, kdb in der Hombrew-Version von Python zu importieren, stürzt der Python-Interpreter ab und zeigt die folgende Fehlermeldung an:
Schwerwiegender Python-Fehler: PyThreadState_Get: kein aktueller Thread
fish: '/usr/local/bin/python' beendet durch Signal SIGABRT (Abbruch)
python -c "import kdb"
gibt also den obigen schwerwiegenden Fehler aus? Klingt komisch, weil die Bindungen (im Gegensatz zum Plugin) überhaupt keine Thread-Zustände oder Interpreter berühren.
Schauen Sie sich übrigens https://github.com/ElektraInitiative/libelektra/blob/master/.travis.yml#L52 an
python -c "import kdb"
gibt also den obigen schwerwiegenden Fehler aus?
Ja, der Befehl /usr/local/bin/python -c "import kdb"
gibt diese Fehlermeldung aus, wenn ich Elektra mit einer alten Version der Formel installiere. Die gute Nachricht ist, dass /usr/local/bin/python3 -c "import kdb"
funktioniert.
Schauen Sie sich übrigens https://github.com/ElektraInitiative/libelektra/blob/master/.travis.yml#L52 an
Wenn ich die zusätzlichen Definitionen hinzufüge und pyenv deaktiviere, laufen die Python-Tests - in meinem üblichen Build-Verzeichnis - einwandfrei. Danke.
Danke, tolle Arbeit!
Für alle Interessierten: Ich habe kürzlich einen Pull-Request für Elektra 0.8.21 bei homebrew-core
hier eröffnet.
So toll, dass die Homebrew-Formel angenommen wurde! https://github.com/Homebrew/homebrew-core/pull/22049
Eine Kleinigkeit: In http://brewformulas.org/Elektra ist die Beschreibung "A repository for sharing configuration snippets" etwas falsch, kann man das über die Formel ändern? Oder müssen wir ein Problem in ihrem Tracker einreichen, um diesen Text zu ändern?
Ich glaube nicht, dass http://brewformulas.org eine offizielle Homebrew-Seite ist. Die korrekte Beschreibung der Formel finden Sie unter:
Framework für den Zugriff auf Konfigurationseinstellungen in einer globalen Schlüsseldatenbank
auf der offiziellen Homebrew-Homepage .
Danke, anscheinend hat die andere nicht offizielle Seite mit der falschen Beschreibung einen höheren Rang in meiner Internetsuche bekommen. Dann gibt es kein Problem mit der Beschreibung von unserer Seite.
Nochmals vielen Dank für Ihre Hartnäckigkeit, die Homebrew-Formel offiziell zu machen.
Können Sie bitte doc/INSTALL.md
aktualisieren und klarstellen, wann die offizielle Formel und wann unser Tap zu verwenden ist?
Können Sie bitte
doc/INSTALL.md
aktualisieren und klarstellen, wann die offizielle Formel zu verwenden ist…
Ich habe das bereits in meiner lokalen Version des Repositorys getan. Pull Request Nr. 1777 enthält diese Änderungen.
…und wann verwenden Sie unseren Wasserhahn?
Die Readme unseres Taps enthält diese Informationen bereits.
Wie wäre es damit, dies offen zu halten, um den Status der Homebrew-Formel für jede Veröffentlichung zu verfolgen? Auf Wunsch können wir auch ein neues Problem für das Tracking hinzufügen.
Wie wäre es damit, dies offen zu halten, um den Status der Homebrew-Formel für jede Veröffentlichung zu verfolgen?
Wie Sie bereits durch das Posten hier gezeigt haben 😊, müssen wir dieses Thema nicht offen halten, um neue Kommentare hinzuzufügen.
Hilfreichster Kommentar
Ich habe das bereits in meiner lokalen Version des Repositorys getan. Pull Request Nr. 1777 enthält diese Änderungen.
Die Readme unseres Taps enthält diese Informationen bereits.