ubuntuusers.de

ingo2 schrieb:

Die kann ich wirklich nicht finden, vielleicht ein Fehler beim Paketbau passiert und deshalb die Version um 1 hoch gesetzt?

Äh, da: https://launchpad.net/~dtl131/+archive/mediahacks?field.series_filter=lucid

diff -Nru mountall-2.15.3~mediahacks1/debian/changelog mountall-2.15.4~mediahacks1/debian/changelog
--- mountall-2.15.3~mediahacks1/debian/changelog	2010-09-18 16:11:04.000000000 +0000
+++ mountall-2.15.4~mediahacks1/debian/changelog	2010-10-08 03:39:21.000000000 +0000
@@ -1,8 +1,17 @@
-mountall (2.15.3~mediahacks1) lucid; urgency=low
+mountall (2.15.4~mediahacks1) lucid; urgency=low
 
   * Suggest plymouth instead of demanding it
 
- -- Dave Lentz <dtl131@gmail.com>  Sat, 18 Sep 2010 12:10:45 -0400
+ -- Dave Lentz <dtl131@gmail.com>  Thu, 07 Oct 2010 23:38:54 -0400
+
+mountall (2.15.3) lucid-proposed; urgency=low
+
+  [ Colin Watson ]
+  * Fix infinite loop when one of mountall's private mount options is
+    followed by a comma, and guard against other reasons why cut_options
+    might end up comparing a zero-length option (LP: #649591).
+
+ -- Scott Moser <smoser@ubuntu.com>  Thu, 30 Sep 2010 03:35:23 -0400
 
 mountall (2.15.2) lucid-security; urgency=low
 
diff -Nru mountall-2.15.3~mediahacks1/src/mountall.c mountall-2.15.4~mediahacks1/src/mountall.c
--- mountall-2.15.3~mediahacks1/src/mountall.c	2010-09-01 22:31:55.000000000 +0000
+++ mountall-2.15.4~mediahacks1/src/mountall.c	2010-10-06 17:09:39.000000000 +0000
@@ -626,7 +626,7 @@
 
 		va_copy (options, args);
 		while ((option = va_arg (options, const char *)) != NULL) {
-			if (! strncmp (opts + i, option, j))
+			if (j && ! strncmp (opts + i, option, j))
 				break;
 		}
 		va_end (options);
@@ -634,8 +634,6 @@
 		if (option) {
 			memmove (opts + (i ? i - 1 : 0), opts + i + j + k,
 				 strlen (opts) - i - j - k + 1);
-			if (i)
-				i--;
 		} else {
 			i += j + k + 1;
 		

}

So, neue Nummern machen noch lange kein neues Programm. Papier und Versionsnummern sind geduldig. Können wir uns drauf einigen, die diffs zu betracheten, anstatt auf Versionsnummern abzuheben?

Ich war ja schon dreist, dass ich schon vor Ubuntu proposed nach main genommen habe, das ganze aber noch mit einer neuen . Version zu versehen, erzeugt bei mir einen gewissen Unmut.

agaida schrieb:

.... Können wir uns drauf einigen, die diffs zu betracheten, anstatt auf Versionsnummern abzuheben?

So tief steige ich eigentlich garnicht ein und die Sourcen brauche ich auch nicht. Das geht ganz einfach mit Bordmitteln des Systems. Außer Download des Binär-Paketes und dem Editor 'nano' (der legt keine Sicherheitskopien an, die dann im Paket landen würden) braucht es nur ein paar Befehle auf der Konsole im Verzeichnis, in dem das Original *.deb liegt. Hier am Beispiel der letzten Version mountall_2.15.3:

dpkg -x mountall_2.15.3_i386.deb ./build
dpkg -e mountall_2.15.3_i386.deb ./build/DEBIAN
nano ./build/DEBIAN/control
dpkg -b ./build mountall_2.15.3-0ingo_i386.deb
rm -rf ./build

Das Verzeichnis ./build braucht nicht vorher zu existieren, wird beim Entpacken automatisch angelegt, ebenso ./build/DEBIAN. In 'nano' braucht man nur zu ändern:

Zeile 2: (Paketname)
Version: 2.15.3   ->   Version: 2.15.3-0ingo

Zeile 6: (Abhängigkeiten, plymouth entfernen)
Depends: makedev, udev, plymouth, ...     ->    Depends: makedev, udev, ....

Kann also jedermann in 5 Minuten selbst nachvollziehen.

Ingo

Ingo, dass war auch garantiert nicht auf Dich gemünzt, das ging ganz klar an unseren jungen schweizer Freund. Ich meine auch nur, dass es angebracht wäre, in einem Fall, wo eine offensichtlich irrsinnige Versionsnummer vorliegt, erst einmal zu schauen, wo die herkommt.

Dann hätte man sehen können, dass der Bube eine recht eigenwillige Zählweise für führende Versionen hat. Das wäre eine Änderung für ~mediahacks2 gewesen

agaida schrieb:

Ingo, dass war auch garantiert nicht auf Dich gemünzt,

schon ok, Alf - war ja auch nicht böse gemeint ☺

Du machst dir natürlich noch etwas mehr Mühe beim "befreien" und führst plymouth als Recommends auf, was absolut korrekt ist. Könnte da eventuell plymouth doch wieder über Synaptic installiert werden? Denn soviel ich weiß, installiert Synaptic (auch der Update-Manager?) in der Default-Einstellung Pakete, die als "recommended" referenziert sind.

P.S.: Heute wäre John Lennon 70 Jahre alt geworden 😢

Definitiv - mache ich nicht, einzige Änderung in der control ist plymouth ersatzlos gestrichen, changelog angepasst mit einem neuen Eintrag und -gcNN. Aus genau den von Dir genannten Gründen 😉

ingo2 schrieb:

Daher Alf, habe ja letzthin die 2.19 für Maverick gebaut!

Damit ich's nicht vergesse, hier schon mal vorab die zugehörige Lucid-Version. Wird sicher bald auch → Lucid-Updates wandern.

Ingo

Hallo Ingo,

hast du die deb-Dateien auch für Maverick?

Oder ist es einfacher das PPA von agaida zu verwenden, klingt auch ganz gut nur bei den Anfängen mit Lucid wollte sich Plymouth aus dieser Quelle wieder installieren was ich ja mit meinem älteren Notebook nicht möchte.

Anfangs - gaaanz am Anfang hatte ich das Zeug auch noch als suggest drin.

Hallo agaida,

Sorry das ich dich nicht direkt angesprochen habe.

Wenn ich das richtig verstehe hast du in deinem PPA alle Dateien ohne Plymouth Abhängigkeiten auch für Maverick?

Wie zählst du die Dateien hoch: cryptsetup - 2:1.1.2-1ubuntu1-gc01mm ? Immer weiter mit -gc02mm, -gc03mm usw.? Wäre für mich wichtig um diese Dateien zu sperren, damit nur die installiert werden können.

Pro Ubuntu-Version und Build. Im Normalfall -gc01RR RR-Release

DeKa schrieb:

Wäre für mich wichtig um diese Dateien zu sperren, damit nur die installiert werden können.

Dann sollte es reichen, in der /etc/apt/preferences diese eine Zeile so anzupassen:

Pin: version *gc*

und du kannst immer aus dem PPA updaten ohne das dir die Ubuntu-Versionen in die Quere kommen.

Ich werde wohl noch Alf's PPA im Wiki-Artikel nachtragen - du hast doch da keine Einwände, Alf?

Hallo,

habe die Dateien aus dem PPA von Alf eingebunden, dabei ließ sich nur mountall installieren bei cryptsetup gibt es diesen Fehler:

E: /var/cache/apt/archives/cryptsetup_2%3a1.1.2-1ubuntu1-gc01mm_i386.deb: Versuche, »/etc/bash_completion.d/cryptsetup« zu überschreiben, welches auch in Paket bash-completion 1

W: Pinning-Typ cryptsetup kann nicht interpretiert werden
W: Pinning-Typ mountall kann nicht interpretiert werden

Wie sieht das ohne Pinning aus?

agaida schrieb:

Wie sieht das ohne Pinning aus?

Mit:

deka@deka-laptop:~/Downloads$ sudo dpkg -i cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb
(Lese Datenbank ... 186951 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereiten zum Ersetzen von cryptsetup 2:1.1.2-1ubuntu9 (durch cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb) ...
Entpacke Ersatz für cryptsetup ...
dpkg: Fehler beim Bearbeiten von cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb (--install):
 Versuche, »/etc/bash_completion.d/cryptsetup« zu überschreiben, welches auch in Paket bash-completion 1:1.2-2ubuntu1 ist
Verarbeite Trigger für man-db ...
Verarbeite Trigger für ureadahead ...
Fehler traten auf beim Bearbeiten von:
 cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb

Ohne:

deka@deka-laptop:~/Downloads$ sudo dpkg -i cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb
(Lese Datenbank ... 186951 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereiten zum Ersetzen von cryptsetup 2:1.1.2-1ubuntu9 (durch cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb) ...
Entpacke Ersatz für cryptsetup ...
dpkg: Fehler beim Bearbeiten von cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb (--install):
 Versuche, »/etc/bash_completion.d/cryptsetup« zu überschreiben, welches auch in Paket bash-completion 1:1.2-2ubuntu1 ist
Verarbeite Trigger für man-db ...
Verarbeite Trigger für ureadahead ...
Fehler traten auf beim Bearbeiten von:
 cryptsetup_1.1.2-1ubuntu1-gc01mm_i386.deb

Bei Ingo seiner Datei mußte "cryptsetup_2.1.1.2-1ubuntu1-0ingo_i386.deb" in "cryptsetup_2.1.1.2-1ubuntu9_i386.deb" geändert werden.

Ich vermute, da prüft Ubuntu den Paketnamen und interpretiert das 2te '-' Zeichen als ein Dorwngrade oder zumindest nicht als Update/Upgrade.

Dazu habe ich bisher leider keine Dokumentation gefunden, der Paketname ist laut Debian-Richtlinien aber völlig korrekt. Vermutlich bleibt uns nur "try and error" ☹