Libelektra: Fügen Sie Homebrew-Formel für Elektra hinzu

Erstellt am 18. Feb. 2016  ·  28Kommentare  ·  Quelle: ElektraInitiative/libelektra

Homebrew ist einer der beliebtesten Paketmanager für OS X. Es wäre schön, wenn wir eine offizielle Homebrew-Formel – auch bekannt als Paket – für Elektra bereitstellen würden. Jemand hat hier schon eine Grundformel gemacht. Vielleicht können wir unsere Arbeit darauf aufbauen.

enhancement usability

Hilfreichster Kommentar

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.

Alle 28 Kommentare

@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.

  1. Bitte führen Sie brew doctor aus und entfernen Sie alle Fragmente von Elektra, die der Befehl meldet.
  2. Tippen Sie auf das Repository: brew tap ElektraInitiative/homebrew-elektra .
  3. Wenn Sie installieren möchten

    • die Flasche verwendet brew install elektra .

    • Geben Sie 0.8.19 aus dem Quellcode frei und verwenden Sie dann brew install --build-from-source elektra .

    • die neueste Version von Elektra, dann verwenden brew install --HEAD elektra .

  4. Um zu überprüfen, ob die Installation funktioniert, können Sie den Befehl 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.

  • Ronn scheint zu fehlen (also keine Manpages)
  • Sie scheinen keine Bindung (außer cpp) einzuschließen, es scheint, als würden Sie ein -DBINDINGS=ALL benötigen
  • kdb 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.

Aktualisieren

Mannseiten

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) ✔

.

Bindungen

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.

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

dmoisej picture dmoisej  ·  3Kommentare

markus2330 picture markus2330  ·  3Kommentare

mpranj picture mpranj  ·  3Kommentare

sanssecours picture sanssecours  ·  3Kommentare

sanssecours picture sanssecours  ·  3Kommentare