Aktuelle Version von octave

[dnoob]

beim Installieren von octave auf debian 10 über die Paketverwaltung wird Version 4.4.1 installiert.

Ich würde gerne die aktuelle Version 5.1.0 benutzen: https://www.gnu.org/software/octave/

Es gibt ein Backport aus der Bullseye-Version: https://packages.debian.org/search?keywords=octave

Ich habe deb http://deb.debian.org/debian buster-backports main zur sources.list hinzugefügt, apt-get update ausgeführt und octave dann mit

Code: Alles auswählen

apt-get -t buster-backports install octave octave-common octave-doc

installiert (vorher natürlich octave deinstalliert).

Leider ist das dann immer noch Version 4.4.1

[KP97]

In Deinem Link ist aber keine Rede von Backports. Die Version 5.1 ist die Version aus Testing.
Dann kann Dein Befehl auch nicht funktionieren.

[dnoob]

Ich habe (auf einer virtuellen Maschine) selbst ein Backport erstellt (https://wiki.debian.org/SimpleBackportCreation)

Das hat dort funktioniert und auch das Installieren hat geklappt.

Also habe ich die Dateien auf meinen Host kopiert und da gehts nicht
40931
Funktioniert ein so erstelltes Backport nur auf dem PC, auf dem es erstellt wurde?

[dnoob]

Ich habe es nochmal nach dieser Anleitung probiert: https://wiki.debian.org/SimpleBackportCreation
Das Ausführen von

Code: Alles auswählen

$ fakeroot debian/rules binary

führt zu einer unglaublich langen Terminal-Ausgabe und dauert ewig. Die letzten paar Zeilen und die Fehlermeldung sehr ihr hier:
41174

Der nächste Schritt führt auch zu Fehlermeldungen:

Code: Alles auswählen

$ dpkg-buildpackage -us -uc
dpkg-buildpackage: Information: Quellpaket octave
dpkg-buildpackage: Information: Quellversion 5.2.0-3
dpkg-buildpackage: Information: Quelldistribution unstable
dpkg-buildpackage: Information: Quelle geändert durch Sébastien Villemot <sebastien@debian.org>
dpkg-buildpackage: Information: Host-Architektur amd64
 dpkg-source --before-build .
dpkg-source: Information: Optionen aus octave-5.2.0/debian/source/options werden verwendet: --extend-diff-ignore=.*\.pdf|.*\.dvi|.*\.png|.*\.eps|.*\.ps|.*\.texi|.*\.info.*|stamp-.*|libinterp/parse-tree/oct-gperf\.h|AUTHORS|doc/interpreter/doc-cache|oct-tex-lexer\.cc|.*\.html|config\.guess|config\.sub|config\.log|.*\.qch|.*\.qhc
dpkg-checkbuilddeps: Fehler: Nicht erfüllte Bauabhängigkeiten: debhelper-compat (= 13) debhelper (>= 12.8~)
dpkg-buildpackage: Warnung: Bauabhängigkeiten/-konflikte nicht erfüllt; Abbruch
dpkg-buildpackage: Warnung: (Verwenden Sie -d, um sich darüber hinwegzusetzen.)

Es fehlen zwei Pakete:

Code: Alles auswählen

$ apt-get install debhelper-compat
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Hinweis: »debhelper« wird an Stelle von »debhelper-compat« gewählt.
debhelper ist schon die neueste Version (12.1.1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Code: Alles auswählen

$ apt-get install debhelper
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
debhelper ist schon die neueste Version (12.1.1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Das eine gibt es nicht, das andere nicht in der benötigten Version.

[dnoob]

Ich habe eine neuere Version von debhelper aus den Backports installiert:

Code: Alles auswählen

$ apt-get -t buster-backports install debhelper

und nochmal probiert:
41175
Jetzt weiß ich nicht mehr weiter.

[tijuca]

Octave ist ein schlechtes Beispiel um einfach mal einen Backport der Version aus Testing zu erstellen, weil eben nicht mehr so "simple" zu machen. Aber auch nicht unlösbar.

Die Minivariante für einen passende Umgebung ein Paket zu bauen und viel flexiblere Variante gegenüber der VM Lösung ist die Benutzung von Chroots. Hierfür gibt es einige Anleitungen wie man diese erstellt und auch benutzt. Daher folgend nur ein paare Kommentare zu den genannten Problemen.

Ich habe (auf einer virtuellen Maschine) selbst ein Backport erstellt (https://wiki.debian.org/SimpleBackportCreation)

Das hat dort funktioniert und auch das Installieren hat geklappt.

Also habe ich die Dateien auf meinen Host kopiert und da gehts nicht
40931
Funktioniert ein so erstelltes Backport nur auf dem PC, auf dem es erstellt wurde?

Code: Alles auswählen

   dh_dwz
dwz: Too few files for multifile optimization
objcopy: 'debian/liboctave7/usr/lib/debug/.dwz/x86_64-linux-gnu/liboctave7.debug': No such file
dh_dwz: objcopy --compress-debug-sections debian/liboctave7/usr/lib/debug/.dwz/x86_64-linux-gnu/liboctave7.debug returned exit code 1
make: *** [debian/rules:56: binary] Fehler 2

Das Problem an sich liegt an dieser Stelle. Hier wird versucht DWZ (DWARF-Fehlerinformationen) auszuführen, was aber misslingt. dh_dwz wurde mit debhelper 12 automatisiert (heißt man muss es nicht mehr explizit in debian/rules aufführen) eingeführt. Der hier auftretende Fehler kommt leider recht häufig vor wenn man versucht einen Backport zu erstellen. In diesem Fall hat der Fehler keine Auswirkungen auf das bzw. die zu erstellenden Pakete. Man kann auf die Ausführung verzichten, also muss man einen override in debian/rules platzieren.

Ich habe eine neuere Version von debhelper aus den Backports installiert:

Code: Alles auswählen

$ apt-get -t buster-backports install debhelper

und nochmal probiert:
41175
Jetzt weiß ich nicht mehr weiter.

Dieser Fehler liegt darin begründet, dass Deine Quellen sich gegenüber den Archiven geändert haben und dpkg daraus folgerichtig die weitere Ausführung verweigert. Warum das so war kann man jetzt nicht mehr nachvollziehen.

Das eigentliche Problem warum Du keinen eigenen Backport erstellen kannst ist das schon erkannte Versionsproblem bei debhelper-compat.
Die Paketmaintainer haben sich bisher nur die Auflösung der Abhängigkeiten für den Bau des Paketes in unstable gekümmert, also musst Du das hier selber etwas anpassen bzw. wissen wie das zu umschiffen ist.

debhelper-compat selber ist nur ein virtuelles Paket.

Code: Alles auswählen

$ apt show debhelper-compat
Package: debhelper-compat
State: kein reales Paket (virtuell)
N: Es kann kein Installationskandidat von Paket »debhelper-compat« ausgewählt werden, da kein solcher existiert.
N: Es können keine Versionen von Paket »debhelper-compat« ausgewählt werden, da es rein virtuell ist.
N: Keine Pakete gefunden

Dieses virtuelle Paket wird wiederum von debhelper bereit gestellt.

Code: Alles auswählen

$ apt show debhelper | grep -E 'Provides|Version'

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Version: 13.2.1
Provides: debhelper-compat (= 9), debhelper-compat (= 10), debhelper-compat (= 11), debhelper-compat (= 12), debhelper-compat (= 13), dh-sequence-dwz, dh-sequence-elf-tools, dh-sequence-installinitramfs, dh-sequence-systemd

Hier ist die Version 13.2.1 am Start, also die Version aus testing bzw. unstable, die Version in stable ist aber "nur" 12.1.1 und kann somit auch nur debhelper-compat 12 zur Verfügung stellen, debian/control will aber Version 13 erfüllt haben. Daher Dein Versionskonflikt.

Es gibt aber noch einen kleinen zusätzlichen Pitfall in debian-control von octave, dort ist auch noch debhelper (>= 12.8~) als Abhängigkeit aufgeführt, was auch eine größere Version wie 12.1.1 ist, kann also nicht erfüllt werden wenn man nicht die Version aus Backports installiert hat. Allerdings ist diese Konstellation hier aus debhelper-compat und zusätzlichem debhelper als Abhängigkeiten etwas sinnfrei. Entweder man benutzt debhelper-compat oder eben debhelper. Ist am Ende aber egal da der Bau von Octave Abhängigkeiten zu anderen externen Paketen hat die momentan nur in buster-backports aufgelöst werden können.

So wie kommt man doch zu einem rückportierten Paket Octave?
Es sind ein paar wenige Anpassungen nötig damit die Binärpakete gebaut werden können. Folgender Diff zeigt die Änderungen die ich hier lokal durchgeführt habe um einen Backport bauen zu können.

Code: Alles auswählen

$ git diff debian/rules debian/changelog
diff --git a/debian/changelog b/debian/changelog
index f1266cb12..ab46c0807 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+octave (5.2.0-2~bpo10+1) buster-backports; urgency=medium
+
+  * Rebuild for buster-backports.
+
+ -- Hanz Dampf <bill.gates@meine-domain.org>  Sun, 25 Oct 2020 06:38:25 +0100
+
 octave (5.2.0-3) unstable; urgency=medium
 
   * Rename /etc/octave.conf to /etc/octaverc, for consistency with upstream
diff --git a/debian/rules b/debian/rules
index c2de09cb8..478ea767d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -109,3 +109,5 @@ override_dh_makeshlibs:
 # Make liboctaveN provide the virtual package octave-abi-MM
 override_dh_gencontrol:
        dh_gencontrol -- -Voctave-abi:Provides=octave-abi-$(API_VERSION)
+
+override_dh_dwz:

Und, ganz wichtig, zusätzlich benötigt man auch buster-backports in den Paketquellen da eben einige andere Abhängigkeiten in Buster schon zu alt sind!

[dnoob]

Octave ist ein schlechtes Beispiel um einfach mal einen Backport der Version aus Testing zu erstellen, weil eben nicht mehr so "simple" zu machen. Aber auch nicht unlösbar.

Es wäre mir auch lieber, ich müsste das nicht. Aber die Version aus den Paketquellen ist einfach uralt. Das nervt mich grundsätzlich an debian, aber irgendwie bin ich mit anderen Distris auch nicht glücklicher

So wie kommt man doch zu einem rückportierten Paket Octave?
Es sind ein paar wenige Anpassungen nötig damit die Binärpakete gebaut werden können. Folgender Diff zeigt die Änderungen die ich hier lokal durchgeführt habe um einen Backport bauen zu können.

Code: Alles auswählen

$ git diff debian/rules debian/changelog
diff --git a/debian/changelog b/debian/changelog
index f1266cb12..ab46c0807 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+octave (5.2.0-2~bpo10+1) buster-backports; urgency=medium
+
+  * Rebuild for buster-backports.
+
+ -- Hanz Dampf <bill.gates@meine-domain.org>  Sun, 25 Oct 2020 06:38:25 +0100
+
 octave (5.2.0-3) unstable; urgency=medium
 
   * Rename /etc/octave.conf to /etc/octaverc, for consistency with upstream
diff --git a/debian/rules b/debian/rules
index c2de09cb8..478ea767d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -109,3 +109,5 @@ override_dh_makeshlibs:
 # Make liboctaveN provide the virtual package octave-abi-MM
 override_dh_gencontrol:
        dh_gencontrol -- -Voctave-abi:Provides=octave-abi-$(API_VERSION)
+
+override_dh_dwz:

Und, ganz wichtig, zusätzlich benötigt man auch buster-backports in den Paketquellen da eben einige andere Abhängigkeiten in Buster schon zu alt sind!

Danke für die ausführliche Antwort. Aber was ich genau ändern soll habe ich leider nicht verstanden

Code: Alles auswählen

deb http://deb.debian.org/debian buster-backports main

ist in der sources.list eingetragen.

[tijuca]

Naja, wenn einem was nervt in Debian ist es immer sinnvoll sich an die Paketmaintainer zu wenden. Sich einem Backport wünschen ist ja auch nichts ungewöhnliches. Wenn die Maintainer nichts von den Wünschen wissen kann man auch nicht gegensteuern.

Danke für die ausführliche Antwort. Aber was ich genau ändern soll habe ich leider nicht verstanden

Naja, anwenden und benutzen.
Wenn Du nicht genau weißt was hier nun zu tun ist dann bleiben Dir noch folgende Optionen.

1. Dich weiter mit Paketbau unter Debian beschäftigen, oder

2. Mit den Paketverantwortlichen in Kontakt treten und freundlich nachfragen welche Optionen noch bestehen.

3. Wenn das nichts bringt auf der ML debian-backports nachfragen ob jemand anderes bereit ist den Backport zu erstellen.

[dnoob]

Wenn Du nicht genau weißt was hier nun zu tun ist dann bleiben Dir noch folgende Optionen.

Angeblich sind doch nur ein paar wenige Anpassungen nötig. Es gäbe da auch noch die Option, mir zu verraten welche diese wenigen Anpassungen sind. Am besten so, dass nicht-Paket-Entwickler sie auch verstehen,

anwenden und benutzen

können.

Aber das wäre vermutlich viel zu einfach und würde dem ungeschriebenen Gesetz, es den unwissenden Fragestellern möglichst schwer zu machen, widersprechen.

Trotzdem Danke für die Mühe.

[tijuca]

Angeblich sind doch nur ein paar wenige Anpassungen nötig. Es gäbe da auch noch die Option, mir zu verraten welche diese wenigen Anpassungen sind. Am besten so, dass nicht-Paket-Entwickler sie auch verstehen,

anwenden und benutzen

können.

Aber das wäre vermutlich viel zu einfach und würde dem ungeschriebenen Gesetz, es den unwissenden Fragestellern möglichst schwer zu machen, widersprechen.

Trotzdem Danke für die Mühe.

Paketbau von Debian Paketen ist nichts was man mal so eben "einfach" erklären kann, so dass es eine Person, die bisher noch nie Pakete gebaut hat, direkt die mehrschichtigen Zusammenhänge versteht, der Prozess des Paketbaus ist (leider) ein komplexer Vorgang was in der Natur der Dinge begründet liegt. Es müssen viele Dinge passend zusammen spielen damit am Ende auch alles zusammen passt. Das ist alles, aber nicht einfach. Wenn es einfach wäre gäbe es wohl auch keine Probleme mit veralten Versionen. Oben stehen alle Änderungen die nötig sind um erfolgreich einen Backport von Octave erstellen zu können. Der Rest ist Wissen wie Debian Systeme und die Paketarchive funktionieren.

Ich kann Deine Frustration jedoch verstehen und ich stand auch mal an der Stelle. Und mit nun reichlich gesammelten Erfahrungen über Jahre hinweg kann ich aber auch sagen, dass Backports vorzubereiten allerdings nicht die passende Einstiegsstelle sind um sich mit Paketierung von Software für Debian zu beschäftigen. Der ganze Prozess das alles zu verstehen und zu verinnerlichen ist eher ein Marathon wie mal drei Tage was zu lernen. Es hat seinen Grund warum die Anerkennung als Debian Maintainer oder dann auch als Debian Developer ein recht langer Prozess ist.

[tijuca]

FTR: octave basierend auf der aktuellen Version in testing ist in der Zwischenzeit für Backports vorbereitet worden und wartet auf die Akzeptanz der FTP-Master.

[schwedenmann]

Hallo

beim Installieren von octave auf debian 10 über die Paketverwaltung wird Version 4.4.1 installiert.

Ich würde gerne die aktuelle Version 5.1.0 benutzen: https://www.gnu.org/software/octave/

Buster und aktuelle SW ist nun mal ein Widerspruch in sich, das sollte ma bei der Instalaltion von Buster bedenken.

mfg
schwedenmann

P.S.
neben backports käme ja noch testing oder arch in einer VM in Frage, dann hat man ein aktuelles octave, wenn man es unbedingt beötigt.