Moin,
Mal wieder eine Fragensammlung, die hoffentlich nicht so stark zusammenhängt, wie letztes Mal.
1. Die Büchse hat als MTA einen postfix am Laufen. Der Übertragungsweg smtp ist während der offline-Zeit auf "defer" gesetzt. In der master.cf steht für dem qmgr.
#========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (50) #========================================================================== qmgr fifo n - - 0 1 qmgr
also wakeup auf 0. Trotzdem wacht das Teil alle 2000 Sekunden auf, stellt fest, daß der transfer-Status defer ist und schläft wieder ein. Die 0 sollte doch IIRC sagen, daß er gar nicht aufwachen soll...
2. Meine XFree86-4 wird von debconf gemanaged. Wie kann ich dort einzelne Modelines einfügen (die mittels xvidtune erzeugt wurde), ohne daß das nächste Mal ein "dpkg-reconfigure xserver-xfree86" die Modelines wieder raushaut. Der Versuch, davor ### END DEBCONF SECTION und dahinter ### BEGIN DEBCONF SECTION zu schreiben war nicht so der Bringer.
3. Ich wollte das Source-Paket von Perl selber bauen. Also perl_5.6.1-8.2.dsc und perl_5.6.1-8.2.diff.gz besorgt, orig.tar.gz kopiert, Sourcen ausgepackt und "fakeroot debian/rules binary" im Buildtree getippt. Build geht durch, aber der file-Test schlägt fehl. Kann das jemand nachvollziehen (evntl. auf 'nem Autobuilder)? Meine Logs liegen auf http://rudi.urz.tu-dresden.de/~hille/perl/ .
Jo, das wars erstmal. Für Ideen dankbar. Hilmar
Hi,
* Hilmar Preusse [02-12-19 17:45:26 +0100] wrote:
- Die Büchse hat als MTA einen postfix am Laufen. Der
Übertragungsweg smtp ist während der offline-Zeit auf "defer" gesetzt.
Muesste das nicht "defered" heissen? "Defer" gibt es auch als Daemon, der sich um zurueckgehaltene Mails kuemmert.
In der master.cf steht für dem qmgr.
#========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (50) #========================================================================== qmgr fifo n - - 0 1 qmgr
also wakeup auf 0. Trotzdem wacht das Teil alle 2000 Sekunden auf, stellt fest, daß der transfer-Status defer ist und schläft wieder ein. Die 0 sollte doch IIRC sagen, daß er gar nicht aufwachen soll...
qmgr(8) (...meiner Uralt-Installation) sagt, dass man qmgr triggern kann; zum Beispiel soll lt. Manpage der master-Daemon sowas bei Diensten machen, die er selbst fuer absolut ueberlebenswichtig haelt: "... that should not go away forever". Vielleicht ist das ja der Grund.
Ausserdem: Was stoert dich daran, dass der qmgr aller ~40 Minuten anspringt?
bye, Rocco
On 19.12.02 Rocco Rutte (s1118644@mail.inf.tu-dresden.de) wrote:
- Hilmar Preusse [02-12-19 17:45:26 +0100] wrote:
Hi,
- Die Büchse hat als MTA einen postfix am Laufen. Der
Übertragungsweg smtp ist während der offline-Zeit auf "defer" gesetzt.
Muesste das nicht "defered" heissen? "Defer" gibt es auch als Daemon, der sich um zurueckgehaltene Mails kuemmert.
Nö, in der main.cf steht: defer_transports = smtp Ich hab keine extra transport-maps, weil es eh nur zwei Arten von Mails gibt.
qmgr(8) (...meiner Uralt-Installation) sagt, dass man qmgr triggern kann; zum Beispiel soll lt. Manpage der master-Daemon sowas bei Diensten machen, die er selbst fuer absolut ueberlebenswichtig haelt: "... that should not go away forever". Vielleicht ist das ja der Grund.
Gut, danke. Ich hab in der Manpage was gefunden, was gut aussieht: queue_run_delay = 0s Scheint der richtige Parameter zu sein. Mal sehn, ob auch der Wert vernünftig ist.
Ausserdem: Was stoert dich daran, dass der qmgr aller ~40 Minuten anspringt?
Der Default ist 1000 sec. So stehts auch im Logfile und ich hab mich vertippt. Die Antwort ist ganz einfach der Drang nach Perfektionismus.
Thanks so far, Hilmar
On 19.12.02 Hilmar Preusse (hille42@web.de) wrote:
Moin,
- Ich wollte das Source-Paket von Perl selber bauen. Also
perl_5.6.1-8.2.dsc und perl_5.6.1-8.2.diff.gz besorgt, orig.tar.gz kopiert, Sourcen ausgepackt und "fakeroot debian/rules binary" im Buildtree getippt. Build geht durch, aber der file-Test schlägt fehl.
Mal wieder eine Selbst-Reply. Ich hab jetzt einfach den Aufruf der Test-suite aus debian/rules ausgebaut (für hppa hatte das schon jemand gemacht) und mir ein lokales Paket gebaut, was man selber backen kann. Passiert das eigentlich öfter, daß Security-Updates nicht vernünftig zu kompilieren gehen? Bei xpdf baut noch nichtmal das Originalpaket.
c++ -g -O2 -DHAVE_CONFIG_H -I.. -I./../goo -I./../ltk -I. -I/usr/X11R6/include -I/usr/include -I/usr/include/freetype2 -c FTFont.cc In file included from /usr/include/freetype2/freetype/ftrender.h:24, from /usr/include/freetype2/freetype/internal/ftobjs.h:31, from FTFont.cc:18: /usr/include/freetype2/freetype/ftmodule.h:70: `FT_Module_Constructor' was not declared in this scope /usr/include/freetype2/freetype/ftmodule.h:70: `FT_Module' was not declared in this scope /usr/include/freetype2/freetype/ftmodule.h:70: parse error before )' /usr/include/freetype2/freetype/ftmodule.h:70: typedef declaration includes an initializer /usr/include/freetype2/freetype/ftmodule.h:70: confused by earlier errors, bailing out
Da fragt man sich doch, wie die Leute das Paket kompiliert haben...
H.
On Saturday 11 January 2003 14:53, Hilmar Preusse wrote:
Mal wieder eine Selbst-Reply. Ich hab jetzt einfach den Aufruf der Test-suite aus debian/rules ausgebaut (für hppa hatte das schon jemand gemacht) und mir ein lokales Paket gebaut, was man selber backen kann. Passiert das eigentlich öfter, daß Security-Updates nicht vernünftig zu kompilieren gehen? Bei xpdf baut noch nichtmal das Originalpaket.
Wenn die Build-Dependencies in Ordnung sind, sollte das soch funktionieren. Unverständlich sind aber z.B. unterschiedliche Interfaces der glibc auf einerseits x86 und andererseits ppc. Da gibt's noch viel zu tun für die Maintainer :) Für xpdf hab ich keinen Bugreport bezüglich Compilierung gefunden - erstell einfach einen und warte auf Reaktion.
c++ -g -O2 -DHAVE CONFIG H -I.. -I./../goo -I./../ltk -I. -I/usr/X11R6/include -I/usr/include -I/usr/include/freetype2 -c FTFont.cc In file included from /usr/include/freetype2/freetype/ftrender.h:24, from /usr/include/freetype2/freetype/internal/ftobjs.h:31, from FTFont.cc:18:
Falsche FT-Version? Es gibt 1.x und 2.x.
Josef
On 15.01.03 Josef Spillner (dr_maux@users.sourceforge.net) wrote:
Moin,
c++ -g -O2 -DHAVE CONFIG H -I.. -I./../goo -I./../ltk -I. -I/usr/X11R6/include -I/usr/include -I/usr/include/freetype2 -c FTFont.cc In file included from /usr/include/freetype2/freetype/ftrender.h:24, from /usr/include/freetype2/freetype/internal/ftobjs.h:31, from FTFont.cc:18:
Falsche FT-Version? Es gibt 1.x und 2.x.
Nö! Hatte noch libttf-dev installiert und xpdf hat ein Build-Conflicts auf dieses Paket. Nach dem Purgen ging es dann. Sorry!
H.
lug-dd@mailman.schlittermann.de
-
Hilmar Preusse -
Josef Spillner -
Rocco Rutte