[linux-l] par2 unter Linux

[Mike Dornberger]

Hi,

On Sun, Jan 06, 2008 at 11:48:01PM +0100, Steffen Dettmer wrote:

> * Mike Dornberger wrote on Sun, Jan 06, 2008 at 17:28 +0100:

> > Vielleicht hast du ja auch andere Bibliotheken,
> 
> (ja na klar, ganz andere glibc natürlich und so weiter, alles anders...)
> 
> >  die zusätzlich oder anstatt einer anderen genutzt werden, die
> >  configure erkennt, aber im Bauprozeß Probleme verursachen. Hast du
> >  mal versucht, den Debian-Maintainer von par2cmdline, Bart Martens,
> >  deswegen anzuschreiben? (Siehe:
> >  http://packages.debian.org/source/lenny/par2cmdline )
> 
> Ich habe nach Deinem Tipp vorherige Mail die patches `gefunden', die
> fixen auch Sachen, die im par2 project auf sf.net noch offen sind (hab
> das dann mal als Kommentar in die Bugtracker geschrieben). Der
> Debian-Maintainer soll doch eigentlich keine par2 Bugs rausmachen,
> sondern den Kram bauen, oder? Wenn ich maintainer wäre, würde ich
> vermutlich sagen, tja, da passt halt eine lib nicht, nimm doch debian,
> wir achten drauf, dass die passen oder sowas :)

Ich hab glaube ich nicht ganz verstanden, was du sagen willst. Der
Debian-Maintainer soll sein(e) Paket(e) pflegen, sodaß sie lauffähig (und
natürlich auto-compilierfähig) sind. Ein "geht gar nicht mehr" dürfte wohl
ein veröffentlichungskritischer Fehler (release crititalc; RC-bug) sein.
Wenn das nicht behoben wird, dann fliegt das Paket auch schonmal aus testing
(und somit letztlich aus dem kommenden stable) raus. Es werden öfter Patches
eingepflegt, die (noch) nicht von Upstream angenommen wurden. (Meist werden
die dann aber so oder in leicht geänderter Form von Upstream aufgenommen.
Die unstable/sid und experimental-Distributionen sind ja auch zu
"großflächigen" Austesten da.)

> Mir ist ja schon klar, dass man mit einem zwei Jahre alten Linux heute
> nix mehr reissen kann, aber das funktioniert halt wenigstens noch daher
> bleibts auf'm Server :)

Hm, wenn das Debian-Projekt einige gutbezahlte Softwareentwickler hätte,
würden sie wahrscheinlich auch noch Sicherheitsunterstützungen für
oldoldstable, old^3-stable oder noch länger geben. Das Zurückportieren von
Sicherheitspatches ist halt sehr aufwendig, deswegen gibt es nur oldstable,
das so lange unterstützt wird, bis testing stable und stable oldstable wird.
Da hat man dann so wenigstens so ca. 2 Jahre Zeit, seine Server zu
aktualisieren.

Für die Mozilla-Geschichten gibt es aber keine Sicherheitsunterstützung
mehr, da sich die Fixes aus den 2er-Versionen praktisch überhaupt nicht mehr
zurückportieren lassen. (Aber da könnte man selbst versuchen, in einem
oldstable chroot die aus stable zu bauen, wenn man es dann unbedingt will.
Vielleicht gibt es da auch schon was auf backports.org.)

> > Ansonsten, da das wohl nur von Standard-Sachen abhängt, versuch doch
> > einfach, daß .deb auszupacken und die Exe darin zu benutzen unter Suse.
> > (Abhängigkeiten siehe z. B.: http://packages.debian.org/lenny/par2 ) Die
> > debs sind ar-Archive in denen jeweils ein tar für die Buchhaltung
> > (Maintainer-Scripts udgl.) und ein tar für den jeweiligen eigentlichen
> > Inhalt enthalten. 
> 
> ahh, das ist ja mal eine fiese Idee und brutale Methode, gefällt mir :)
> Ich hab sicherheitshalber nicht lenny sondern sarge genommen (da stand
> oldstable dran und old passt vielleicht besser), das mit ar und tar
> ausgepackt, das binary in die make-check-Umgebung kopieret und 
> 
>          ES GEHT!!
> 
> :-)

Du kannst auch das aus etch oder lenny probieren, das was halt geht, geht.
:)

Naja, es funktioniert wohl auch nur, weil sich die ABI der entsprechenden
Bibliotheken nicht oder nur minimal geändert haben. Dank der Bemühungen um
LSB und so sollte sowas relativ häufig klappen. Ist zwar eher für den
Einsatz "kommerzieller" Software gedacht, aber es kann ja dann auch
"andersherum" klappen. :)

Mir fällt da übrigens noch eine viel "fiesere und brutalere" Methode ein:
Auf http://snapshot.debian.net (vgl. auch
http://debiananwenderhandbuch.de/sources.list.html#snapshot ) finden sich so
ziemlich alle Versionen von Software, die jemals zu Debian hochgeladen
wurden. (Einschränkung: Wenn sich später herausgestellt hat, daß die Lizenz
eine entsprechende Verbreitung verbietet, dann wird das da wohl gelöscht.)
Da das letztlich alles ganz normales HTTP ist, kann man sich da auch die
Sourcen so ziehen.

Da kann man sich zur Not vielleicht ein woody-, ham- oder bo-chroot bauen
und da dann Binaries zusammenklöppeln, die dann mit den entsprechend
ABI-kompatiblen Binaries unter Suse laufen. Ist zugegebenermaßen vielleicht
etwas friemelig, könnte aber funktionieren. :)

> > > Ja, aber das sind doch eher debian-spezifische Sachen, glaube ich. Bei
> > > mir geht ja sozusagen nichtmal die Basisfunktion :(
> > 
> > Da die Patches erstmal Debian-spezifisch sind, sollten sie da auch
> > Erwähnung finden.
> 
> ... sorry, die patches (bis auf einen) sind nicht debian-spezifisch, da
> hatte ich falsch geguckt. Zwei sollten IMHO auf jeden Fall in par2 rein,
> weil es fixes sind. Scheinbar wird par2cmdline seit 2004 nicht mehr
> gewartet (bzw. nur von den Maintainern :)).

Mit Debian-spezifisch meinte ich eher, daß sie halt nicht von Upstream
aufgenommen wurden. Der Debian-Maintainer hat sie aufgenommen, um (i. d. R.)
Bugs im Debian-BTS zu schließen. Hätte mich da etwas klarer ausdrücken
sollen.

Hm, wenn du par2 häufiger verwendest und dich da nun ja auch schon etwas mit
den Sourcen rumgeärgert hast, frag doch mal bei Bart Martens an, ob ihr zwei
das Projekt auf sf nicht übernehmen wollt. Wäre ja eigentlich sogar toll,
wenn mit Hilfe der Programmierer der GUI-Varianten da evt. sogar eine
frontend-unabhängige Bibliothek (shared library) rausspränge, auf die alle
Projekte zugreifen können. Macht die Arbeit für die Sicherheits-Leute ja
dann auch einfacher. Ein Buffer Overflow oder sowas müßte dann nur noch an
einer Stelle gefixt werden. :)

> > Meist kommen die ja rein, da sie vorher jemand im Debian-BTS abgelegt
> > hat und im Changelog taucht dann evt. nur die Bug-Nummer auf, die mit
> > anbringen des Patches geschlossen wurde. Die Diskussion dort führt
> > ggf.  zu weiteren Erkenntnissen.
> 
> Ja, so war das da auch, stehen auch schön die Namen dran und so,
> wirklich vorbildlich, wirklich schön dokumentiert und alles. Hatte bloss

*G* Ja die Debian-Policy, die dies ja nun fordert, entsteht, soweit ich das
gelesen habe, im wesentlichen dadurch, daß "Best Practise" dann irgendwann
und sehr vorsichtig zur Forderung wird. Das find ich persönlich auch das
Schöne an Debian: Es wird (i. a.) versucht, Dinge _richtig_ zu machen und
nicht eine schnelle Lösung zu finden. Und an allen Ecken und Enden wird
versucht, sich wiederholende Sachen zu vereinfachen und/oder zu
automatisieren. (Vgl. lintian, linda, debhelper, $VCS-buildpackage (for VCS
in svn cvs tla bzr hg git), cdbs, dh-make uvam.) Naja gut zugegeben, habe
ich mir andere Distributionen nicht so wirklich genau angesehen und bin da
wohl ein wenig voreingenommen. Andererseits ist mir jetzt aber auch keine
andere Distribution bekannt, die auf 11 verschiedenen Architekturen
kompiliert/läuft.

... Oh, ich verfalle wohl schon wieder in technische Begeisterung und sollte
evt. aufhören, so viel OT zu schreiben. :)

> Ja, danke für Deine Gedult und Deine Ideen, die mir am Ende ja auch
> geholfen haben, prima!

Gerne doch. Wenn ich Zeit und Ahnung habe, kein Problem, dafür sind wir ja
hier auf der Liste, dachte ich. ;)

Gruß,
 Mike