staging.inyokaproject.org

Hallo Wikiteam,

eigentlich sollte dieser Post im Forenbereich forum:projekte erstellt werden. Da der Diskussionbutton aber hierher verlinkt ist das wohl fehl am Platze. Kann man dies bitte ändern, Danke.

Hi RapaNui,

sehr schönes Programm und gute Projektidee! Ich fände es praktisch, wenn du für den Code mit einer Versionsverwaltung nutzt (git oder bzr bieten sich an, mercurial weniger, da damit momentan von sourceforge aus nicht nach Launchpad importiert werden kann). Wenn du möchtest helfe ich dir dabei und auch ein eintsprechendes Debian/Ubuntu-Quellpaket aufzusetzen.

Was aus deinem Eingangspost nicht ganz deutlich wird: Das Projekt steht unter der Affero GPL. Und welcher Teil steht unter CC BY-NC-SA ?

Zum Projekt: Nicht alle haben so breite Monitore, deswegen wäre eine Option für eine für eine kleinere Terminalweite optimierte Ausgabe imho sinnvoll. Oder so wie bei lsblk, dass man die Spalten auch vollständig frei wählen kann. Außerdem können momentan die Kurzoptionen nicht kombiniert werden. Da lsdisk nur die existierenden Werte von Systemwerkzeugen wie parted oder fdisk nutzt, wäre es ein enormer Geschwindigkeitsboost, die entsprechenden Libraries zu nutzen, also das Ganze in C aufzusetzen.

Gruss Lasall

Hallo Lasall,

Danke für die anerkennenden Worte. Natürlich ist das Ganze noch verbesserungswürdig, aber es ist bereits ein Anfang.

Lasall schrieb:

Hi RapaNui,

sehr schönes Programm und gute Projektidee! Ich fände es praktisch, wenn du für den Code mit einer Versionsverwaltung nutzt (git oder bzr bieten sich an, mercurial weniger, da damit momentan von sourceforge aus nicht nach Launchpad importiert werden kann). Wenn du möchtest helfe ich dir dabei und auch ein eintsprechendes Debian/Ubuntu-Quellpaket aufzusetzen.

Mit Bazaar habe ich schon mal gearbeitet. Z.Zt. habe ich die Skripte auch dort in einer Verzeichnisstruktur liegen, aber noch nicht geaddet, da ich mich doch etwas schwer damit tue. Ich hab noch keinen Plan, wie ich die Verzeichnisse aufteilen bzw. benennen soll.

• Mein Wunsch wäre eben, dass dabei GRUB (mein Hauptverzeichnis) und os-prober-efi (Unterverzeichnis) irgendwie im Namen bzw. der Struktur mit aufgeführt werden, um die Zugehörigkeit besser zu erkennen.

• Wahrscheinlich kann man das auch beim Hochladen nach launchpad realisieren (Ich hab dort z.Zt. lsdisk als Einzelprojekt liegen, muss mich aber noch einlesen wie man weitere Projekte anlegt etc.).

• Zu den DEB-Paketen können wir ja später immer noch schreiten, dass wäre natürlich super.

• Wichtig wäre dabei aber auch eine gute readme, die das wichtigst eben auf Englisch beschreibt.

Das größte Problem meinerseits ist eben die sprachliche Barriere, da hapert es gewaltig. Ich muss n-mal das Englische lesen, oft ein Wörterbuch zu Hilfe nehmen und dann hab ich es immer noch falsch interpretiert 😮, geschweige denn, dass ich mich in Englisch verständlich mache. 😢

Ich hatte auch schon mal angedacht das Projekt unter dem Namen (Account) ubuntuusers.de veröffentlichen zu lassen bzw. an Euch zu übertragen. Dank meines Alters 😉 und einer gewissen lmaA-Einstellung muss ich das nicht unbedingt als "mein Kind" in der Welt vertreten. 😇

Was aus deinem Eingangspost nicht ganz deutlich wird: Das Projekt steht unter der Affero GPL. Und welcher Teil steht unter CC BY-NC-SA ?

Die GPL hab ich aus den normalen GRUB-Skripten übernommen, damit sie eben zu GRUB kompatibel werden. Das CC BY-NC-SA ist z.Zt. noch zusätzlich eingetragen (Reminiszenz an ubuntuusers.de, die ich im Quelltext mit benenne). Genau genommen hab ich auch dort keinen direkten Überblick und wäre auf Eure Aussagen bzw. Vorschläge angewiesen.

Zum Projekt: Nicht alle haben so breite Monitore, deswegen wäre eine Option für eine für eine kleinere Terminalweite optimierte Ausgabe imho sinnvoll.

Meine Tests auf einem alten Röhrenbildschirm bei 1024 haben dabei gute Ergebnisse erzielt, daher diese Aufteilung bei lsdisk. Mein Ansatz dabei war, möglichst kompakt viele Infos unterzubringen. Bei dem os-prober-efi liegt die Ausgabe ja unter der Grenze und wurde von mir mehr als boot-info-skript-Ergänzung Rund um EFI gesehen.

Oder so wie bei lsblk, dass man die Spalten auch vollständig frei wählen kann.

Dazu müsste ich mich tiefer in das wie bewerkstelligen hinein knien, ich kann leider nur Shellskripte.

Grundsätzlich sah ich eben diese Form der Anzeige nicht als problematisch an, da sie ja nicht als tägliche Anwendung gedacht war. Die Auswertungen wurden zur Anlayse geschaffen, um selbst schnell und einfach viele Informationen zu erhalten bzw. um sie zu posten (u.a. hier im Forum), damit der Helfer die Daten zum Systen auswerten kann. Da ich die Auswertung davon auch bei der EFI-Analyse als wichtig und informativ ansah, hab ich es mit os-prober-efi verknüpft. Man könnte es aber auch einfach wieder herauslösen und legt es als als zusätzliche Auswertungsmöglichkeit mit bei.

Außerdem können momentan die Kurzoptionen nicht kombiniert werden.

Da ich eine Mischung von Kurz- und Langoptionen nutze, habe ich nicht auf getopts gesetzt. Eine Mischung aus beiden wäre aber umsetz- und realisierbar - ich mach mir ein paar Gedanken dazu.

Da lsdisk nur die existierenden Werte von Systemwerkzeugen wie parted oder fdisk nutzt, wäre es ein enormer Geschwindigkeitsboost, die entsprechenden Libraries zu nutzen, also das Ganze in C aufzusetzen.

1. Nein, lsdisk wertet komplett die Daten aus dem sysfs (/sys) aus, daher braucht es eben keine Rootrechte um diese Informationen zu liefern.

2. Die Partitonstabellen-Auswertung mache ich komplett mit hexdump, daher Rootrechte.

3. partprobe setze ich zur Unterstützung bei der eindeutigen Ermittlung des Partitionstabellen-Typs ein. Es gibt ja neben msdos und GPT noch weitere Typen, die ich nicht ohne weiteres mit Hexdump extrahieren kann - wäre also nicht unbedingt zwingend.

4. Die integrierten Aufrufmöglichkeiten von gparted, fdisk und gdisk habe ich, sozusagen als Schmankerl, mit eingebaut. Ich wollte nur eine einheitliche Aufrufmöglichkeit (ein PGM-Name) für die verschiedenen Auswertungsformen realisieren. Der eine bevorzugt die Darstellung von parted und andere die von fdisk, wobei man für die GPT nun noch auf gdisk setzen sollte. Alle drei PGMs sind eigtl. kein muss und könnten komplett entnommen werden.

5. Auch hier nochmals der Hinweis: Ich bin ein Hobbyskripter, der gerne analysiert, organisiert und die Ergebnisse möglichst einfach bewerkstelligen möchte. Hochsprachen sprengen mein bescheidenes Wissen, daher eben auch eine möglichst freie Lizenz, damit Andere aus meinem Anfang einfach etwas "besseres" schaffen können.

Ich hoffe, ich habe mich verständlich ausgedrückt 😉

Saludos aus Chile
RapaNui

RapaNui,

sorry, ich hatte die Wikiseite noch nicht gelesen und bezog mich nur auf das lsdisk auf sourceforge, weswegen mein Kommentar an manchen Stellen nicht passend war.

Du schriebst:

• Mein Wunsch wäre eben, dass dabei GRUB (mein Hauptverzeichnis) und os-prober-efi (Unterverzeichnis) irgendwie im Namen bzw. der Struktur mit aufgeführt werden, um die Zugehörigkeit besser zu erkennen.

• Wahrscheinlich kann man das auch beim Hochladen nach launchpad realisieren (Ich hab dort z.Zt. lsdisk als Einzelprojekt liegen, muss mich aber noch einlesen wie man weitere Projekte anlegt etc.).

Neue Projekte werden genauso wie die Alten erstellt.

• Wichtig wäre dabei aber auch eine gute readme, die das wichtigst eben auf Englisch beschreibt.

Sollte möglich sein.

Ich hatte auch schon mal angedacht das Projekt unter dem Namen (Account) ubuntuusers.de veröffentlichen zu lassen bzw. an Euch zu übertragen. Dank meines Alters 😉 und einer gewissen lmaA-Einstellung muss ich das nicht unbedingt als "mein Kind" in der Welt vertreten. 😇

Das imho beste ist, wenn du die Lizenz ganz normal bei dir hälst.

Sobald du die Versionsverwaltung eingerichtet hast, bitte melden.

Gruss Lasall

Lasall schrieb:

• Wichtig wäre dabei aber auch eine gute readme, die das wichtigst eben auf Englisch beschreibt.

Sollte möglich sein.

Das hab ich mich gedacht ☺

Das imho beste ist, wenn du die Lizenz ganz normal bei dir hälst.

• Wie sollte das generell aussehen?

• Was sollte ich als Lizenz angeben?

  • Reicht die GRUB-Lizenz und eine neue Zeile Copyrigth: Meienrseits und was mach ich dann mit den Helfern (die sollen ja auch namentlich erscheinen)

    # grub-mkconfig helper script.
    # Copyright (C) 2006,2007,2008,2009,2010  Free Software Foundation, Inc.
    #
    # GRUB is free software: you can redistribute it and/or modify
    # it under the terms of the GNU General Public License as published by
    # the Free Software Foundation, either version 3 of the License, or
    # (at your option) any later version.
    #
    # GRUB is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with GRUB.  If not, see <http://www.gnu.org/licenses/>.

  • Sollte ich weitere Lizenzen mit einbeziehen, wenn ja wie?

  • Was sollte ich dann an der lsdisk-Lizenz ändern, damit es konform ist (Hab da damals den Vorschlag von launchpad genommen, darum AGPL)

Sobald du die Versionsverwaltung eingerichtet hast, bitte melden.

Bazaar ist installiert. Nach meinen Vorstellungen geh ich nun wie folgt vor:

• ins Verzeichnis zu os-prober wechseln (liegt im bzr-Hauptverzeichnis so wie lsdisk)

• bzr init mit dem Jetzt-Stand oder doch bzr init-repo .

Nun gehts los: Mein Wunsch wäre, dass es evtl. so aussieht, ist das gut/realistisch/sinnvoll? Projekt os-prober-efi und als trunc dann grub.

• bzr init???

• ???

• ???

• bzr launchpad-login

  • Da brauch ich wohl keinen Benutzernamen mehr, da ich ja noch aus lsdisk initialisiert bin, oder?

  • bzr export grub/os-prober.version.tar.gz

  • bzr push lp:~..... # erster Upload nach launchpad

• nach jeder Änderung dann lediglich ein

  • bzr commit -m "was hab ich getan"

  • neues export und hochladen

Saludos aus Chile

Hi RapaNui,

du schriebst:

Das imho beste ist, wenn du die Lizenz ganz normal bei dir hälst.

• Wie sollte das generell aussehen?

An alle relevanten Dateien oben einen Disclaimer anfügen.

• Was sollte ich als Lizenz angeben?

Ich verwende immer GPL-3+, aber AGPL-3+ ist auch gut und auch kompatibel (mit GPL-3+): Affero_General_Public_License

• Reicht die GRUB-Lizenz und eine neue Zeile Copyrigth: Meienrseits und was mach ich dann mit den Helfern (die sollen ja auch namentlich erscheinen)

Den Disclaimer so übernehmen nur deine eigenen Daten (Datum, Name, evtl. Email, Projektname) ändern.

Bazaar ist installiert. Nach meinen Vorstellungen geh ich nun wie folgt vor:

• ins Verzeichnis zu os-prober wechseln (liegt im bzr-Hauptverzeichnis so wie lsdisk)

• bzr init mit dem Jetzt-Stand oder doch bzr init-repo .

Nun gehts los: Mein Wunsch wäre, dass es evtl. so aussieht, ist das gut/realistisch/sinnvoll? Projekt os-prober-efi und als trunc dann grub.

Wenn du gerne verschiedene Unterabschnitte hättest empfiehlt sich das shared-Repository (init-repo) (siehe hier 🇬🇧) ansonsten wenn du alles in einem Projektteil haben möchtest ein normales Repo anlegen (init). Dabei würde ich aber lsdisk und die efi-Sachen in 2 unterschiedliche Projekte trennen oder ist das so verzahnt?

• bzr launchpad-login

Nicht mehr benötigt, wenn die Datei ~/.bazaar/authentication.conf schon angepasst ist.

• bzr export grub/os-prober.version.tar.gz

Wieso exportieren?

• bzr push lp:~..... # erster Upload nach launchpad

+1.

• nach jeder Änderung dann lediglich ein

  • bzr commit -m "was hab ich getan"

Am Besten den interaktiven Commit nutzen, also ohne -m. Dann kann man auch über mehrere Zeilen schreiben. Layout ist: Erste kurze Zeile (~70 Zeichen) mit knapper Beschreibung. Folgendes ist dann ausführliche Beschreibung zum Commit, z.B. mit Aufzählung usw. (am Besten auf 80 Zeichen Zeilenbreite beschränken).

• neues export und hochladen

Was möchtest du mit dem Exportieren erreichen? Pushe einfach in den Branch: "bzr push" (:push) oder "bzr push :parent" /:push/:submit oder "bzr push LOCATION" für z.B. lp:...

Gruss Lasall

Hola Lasall,

Danke für die Infos.

Lasall schrieb:

Ich verwende immer GPL-3+, aber AGPL-3+ ist auch gut und auch kompatibel (mit GPL-3+): Affero_General_Public_License

Ich hatte die AGPL gewählt, da sie etwas offener bei Servern (?) sein soll.

Wenn du gerne verschiedene Unterabschnitte hättest empfiehlt sich das shared-Repository (init-repo) (siehe hier 🇬🇧) ansonsten wenn du alles in einem Projektteil haben möchtest ein normales Repo anlegen (init).

War nur so eine Idee, also der einfachere Weg (nur init).

Dabei würde ich aber lsdisk und die efi-Sachen in 2 unterschiedliche Projekte trennen oder ist das so verzahnt?

Nein, absolut nicht. Ich hatte das Teil nur mit integriert, da es umfangreiche Infos über angeschlossene Datenträger liefert - eben auch ohne root. Wenn es nicht installiert ist, dann wird es auch nicht aufgerufen. Da würde dann in der Doku ein Verweistext auf die Zusammenhänge und das lsdisk-Projekt reichen.

• bzr export grub/os-prober.version.tar.gz

Wieso exportieren?

Um ein tar zu erstellen - hatte ich so verstanden. Von wo aus soll ich den Rohcode pushen, was wäre besser/übersichtlicher? a) Aus dem Übergeordnenen Verzeichnis, so dass /os-prober mit den darin liegenden Dateien hochgeladen wird, oder b) direkt aus dem Verzeichnis, indem die Dateien liegen?

Ich lese dann mal weiter 😉 und danach geht es los.

P.S. An den zusammengefassten Kurzoptionen bin ich dran. Lösung bereits fertig, ich muss sie nur noch einbauen.

P.P.S. Bei lsdisk möchte ich einen eindeutigeren usage Text machen, der darauf hinweis, dass gparted, fdisk und gdisk nur "Goodies" sind, etwa so was - allerdings in english:

        Options:
                  foo bar
        Special Goodies:
        Sofern die Programme gparted, fdisk/gdisk (ja nach Partitionstyp) installiert sind, lassen
        sich diese zu Listzwecken ebenfalls über lsdisk aufrufen. Die Optionen dazu sind:

Hättest Du da einen Vorschlag?

Nochmals gracias
RapaNui

Hi RapaNui,

du schriebst:

• bzr export grub/os-prober.version.tar.gz

Wieso exportieren?

Um ein tar zu erstellen - hatte ich so verstanden. Von wo aus soll ich den Rohcode pushen, was wäre besser/übersichtlicher? a) Aus dem Übergeordnenen Verzeichnis, so dass /os-prober mit den darin liegenden Dateien hochgeladen wird, oder b) direkt aus dem Verzeichnis, indem die Dateien liegen?

Wenn du mit einem VCS arbeitest, braucht es erstmal keine Tarballs. Das kann man immer dann machen, wenn released wird. Arbeite einfach im Bazaarcode, committe bei zusammenhängenden Codeänderungen und pushe dann.

P.S. An den zusammengefassten Kurzoptionen bin ich dran. Lösung bereits fertig, ich muss sie nur noch einbauen.

☺

P.P.S. Bei lsdisk möchte ich einen eindeutigeren usage Text machen, der darauf hinweis, dass gparted, fdisk und gdisk nur "Goodies" sind, etwa so was - allerdings in english:

        Options:
                  foo bar
        Special Goodies:
        Sofern die Programme gparted, fdisk/gdisk (ja nach Partitionstyp) installiert sind, lassen
        sich diese zu Listzwecken ebenfalls über lsdisk aufrufen. Die Optionen dazu sind:

Hättest Du da einen Vorschlag?

If gparted or fdisk/gdisk (depending on partition type) are installed you can also invoke them with lsdisk. The following options are supported:

Gruss Lasall

Hola Lasall,

Danke für den Text, ist eigtl. ganz einfach, wenn man sich ein wenig mehr an die Schulausbildung erinnern würde. 🙄

Die Baustelle zum Projekt habe ich überarbeitet, u.a. neue Kurzoptionen (-Beschreibung) und die Links zu Launchpad gelegt. Optionen funktionieren nun auch in Kombinationen und die Langoptionen haben Gegenstücke als Kurzoptionen bekommen.

• lsdisk ist nun überarbeitet und nicht mehr als tar hochgeladen, sondern die Sourcen direkt.

• os-prober-efi habe ich neu angelegt (aber irgendwie ohne den User-Zusatz und trunk) und hochgeladen.

Und das Alles mit mit meinem Englisch beschrieben 😊 .

Saludos aus Chile

Hi RapaNui,

siehe merge-proposal. Kurz Zusammengefasst:

• Codeeinrückungen vereinheitlicht (2 Leerzeichen je logischem Block)

• alle Tabs durch Leerzeichen ersetzt (erstmal alle Tabs durch je 4 Leerzeichen und anschließend manuell nachgebessert)

• fast alle Variablen/Ausdrücke gequoted (bei den eval-Sachen habe ich erstmal nichts gemacht)

• die Testabfragen [ Ausdruck ] && durch if-Konstrukte ersetzt, weil das imho die Lesbarkeit verbessert

• Ein Kommentar soll entweder important (wichtig) oder imported (importiert) heißen, da habe ich ein FIXME hingemacht (in der Merge-Beschreibung habe ich fälschlicherweiße zwei anstatt nur eines FIXME-Tags erwähnt).

Bei den Einrückungen der Kommentare bin ich nach folgendem Schema vorgegangen: Blockbezogene Kommentare direkt in den Code gesetzt, variablenbezogene Kommentare rechts neben der Variable gelassen

Bei den 2 großen for-Schleifen habe ich vorher i auf nichts gesetzt, damit beim sourcen der Skripte nichts ungewolltes übernommen wird.

Wie du siehst, sind erstmal keine inhaltlichen Änderungen vorgenommen worden 😉 . Und ein großes Sorry, weil ich zu faul war die einzelnen Änderungen in unterschiedliche Commits zu packen!

Fragen bisher:

• Geht es nicht ohne export in der GRUB-Konfigdatei? Die ganzen Werte dort werden doch auch nicht exportiert?

• Du verwendest größtenteils $(), wird das immer unterstützt?

Gruss Lasall

Hola Lasall,

da hab ich mir was angetan, ich bin halt totaler Neuling bei der Versionsverwaltung und muss alles zusammensuchen 😊. Branch holen, mergen, Konflikt erzeugt und behoben ..., aber die neuste Version ist hochgeladen. Muss ich egtl. bei Deinen merge-Sachen noch irgend etwas über Bazaar machen, damit die auf launchpad als erledigt/bearbeitet gekennzeichnet werden? Habs auf der Seite auf "Approved" gesetzt.

• Deine Modifizierungen sind so tatsächlich besser lesbar, Danke.

• Hab noch ein paar Quotes mehr gesetzt, wenn schon, dann alles, auch die 'root'-Abfragen und die eval-Sachen. (P.S. in den Grubskripten wird nicht alles gequoted, egal.)

• Der Kommentar (FIXME-Tag) sollte "nicht mehr wichtig" bedeuten.

• Hab noch ein paar kleinere Texte verändert, Return-Code weiter implementiert und ein vorzeitiges Beenden eingebaut.

Lasall schrieb:

Und ein großes Sorry, weil ich zu faul war die einzelnen Änderungen in unterschiedliche Commits zu packen!

Das war schon so wie Du es gemacht hast ok, ich muss mich eh erst da hinein finden und habs bei launchpad anzeigen lassen 😉.

Fragen bisher:

• Geht es nicht ohne export in der GRUB-Konfigdatei? Die ganzen Werte dort werden doch auch nicht exportiert?

1. Es sind eigene Variablen, die werden von der "grub-mkconfig_lib" z.Zt. nicht ausgewertet, eben nur weitergegeben.

2. Ich weiß, dass "eval" eigtl. "evil" ist, aber hier brauche ich sie, da die Einträge der Loader ja immer anders heißen können und ich den Inhalt irgendwie abfragen muss. Diese variablen Variablen werden auch nicht ALLE über die "grub-mkconfig_lib" abgedeckt werden können, daher auch hier export.

• Du verwendest größtenteils $(), wird das immer unterstützt?

Ist POSIX und werden von der bash, dash, zhs oder der ksh ordnungsgemäß verarbeitet. Von der alternativen Schreibweise mit `backticks` wird mittlerweile abgeraten (auch das eigene Wiki), da sie sich u.a. schlecht schachteln lassen.

Saludos aus Chile

Hi RapaNui,

mir ist gerade aufgefallen, dass sich im Branch jeweils zwei Versionen befinden. Einmal in der Wurzel des Working Trees und einmal in Ordner trunc. Imho ist es am besten, wenn du den Ordner trunc entfernst, der Branch heißt ja schon so. Außerdem kannst du in der ~/.bazaar/ignore die Dolphin-Datenen eintragen, damit die nicht gesynct werden.

Gruss Lasall

Lasall schrieb:

Hi RapaNui,

mir ist gerade aufgefallen, ...

Mir auch, nachdem ich das kontrolliert habe. Für die Zukunft ist dieser Teil bereits gelöscht.

Außerdem kannst du in der ~/.bazaar/ignore die Dolphin-Datenen eintragen, damit die nicht gesynct werden.

Das schnall ich im Mom. nicht. Klar, in der Config zu bazaar, erledigt.

Hallo, wie geht's hier weiter? Gruss

Bitte löschen, Danke.