From markus.weygand at mpikg-golm.mpg.de  Tue Oct  5 15:55:14 2004
From: markus.weygand at mpikg-golm.mpg.de (Markus Jan Weygand)
Date: Tue Oct  5 15:55:15 2004
Subject: [buug-l] valarray
Message-ID: <20041005135514.GA647@mpikg-golm.mpg.de>

Hallo,

weisz jemand ob ich bei debian numerische Funktionen in valarray
benutzbar sind; sie scheinen zu fehlen.

   #include <iostream>
   #include <valarray>
   using namespace std;
...
   valarray<double> vc;
   vc = sqrt(va) + vb/2.0 - 1.0;

sqrt() scheint zu fehlen.


Grusz Markus

-- 
   Dr. Markus Jan Weygand
   MPI Golm Institut für Kolloid und Grenzflächen   
    
    _             Tel: +49 (0)331 567 9210
   ( )   
    X   ASCII ribbon campaign
   / \   - against HTML email
From mw at miwie.in-berlin.de  Tue Oct  5 21:01:15 2004
From: mw at miwie.in-berlin.de (Michael Wiedmann)
Date: Tue Oct  5 20:53:57 2004
Subject: [buug-l] valarray
In-Reply-To: <20041005135514.GA647@mpikg-golm.mpg.de>
References: <20041005135514.GA647@mpikg-golm.mpg.de>
Message-ID: <20041005190115.GA3131@miwie.in-berlin.de>

* Markus Jan Weygand <markus.weygand@mpikg-golm.mpg.de> wrote [041005 15:55]:

> weisz jemand ob ich bei debian numerische Funktionen in valarray
> benutzbar sind; sie scheinen zu fehlen.

Sicherstellen, dass dies auch unter mit dem aktuellsten
'libstdc++5-3.3-dev' passiert (ich habe das hier mit
'1:3.3.4-6sarge1.2' verifiziert, in unstable gibnt es aber
'1:3.3.4-13' ) und Bugreport schreiben.

Michael
-- 
mw@miwie.in-berlin.de                              http://www.miwie.org
From mw at miwie.in-berlin.de  Tue Oct  5 21:05:18 2004
From: mw at miwie.in-berlin.de (Michael Wiedmann)
Date: Tue Oct  5 20:57:58 2004
Subject: [buug-l] Versionierung / GNU autoconf
Message-ID: <20041005190518.GA3300@miwie.in-berlin.de>

Gegeben sei ein Binary 'foo' in der Version 'x.y.z', das mittels GNU
autoconf (configure, etc.) gebaut wird. 

Wie ist die gängige Praxis bzgl. der Versions-Nr., wenn nun an der 
Funktionalität des Binary 'foo' _nichts_ geändert wird, sondern 
'lediglich' Änderungen an 'configure(.in)' etc. vorgenommen werden 
(ggf. weil darin Fehler enthalten waren) ?

Michael
-- 
mw@miwie.in-berlin.de                              http://www.miwie.org
From mw at miwie.in-berlin.de  Wed Oct  6 09:26:17 2004
From: mw at miwie.in-berlin.de (Michael Wiedmann)
Date: Wed Oct  6 09:26:19 2004
Subject: [buug-l] Nachtrag: valarray/g++
Message-ID: <1097047577.41639e1940d43@webmail.in-berlin.de>

Folgendes funktioniert zumindest unter cygwin/g++ 3.3.3 (was anderes habe ich
z.Z. leider nicht "zur Hand"):

#include <valarray>
#include <iostream>

using namespace std;

int main(void)
{
  std::valarray<float> va(1), vb(1);

  vb[0] = 1.1f;
  va = sqrt(vb);

  cout << "va = " << va[0] << endl;

  return 0;
}

Michael
-- 
From nico at ngolde.de  Wed Oct 13 17:50:27 2004
From: nico at ngolde.de (Nico Golde)
Date: Thu Oct 14 01:52:46 2004
Subject: [buug-l] intention eines maintainers
Message-ID: <20041013155027.GA3177@ngolde.de>

hi,
ich halte demnächst einen vortrag über die erstellung eines debian
pakets.
ich suche noch gründe für das bauen von paketen, bis jetzt hab ich:
- Eingliederung von SW in das Debian-Paketsystem
- Ziel offizieller Maintainer
- Software ist nicht als Debian-Paket verfügbar
- Erweiterung (patches etc.) vorhandener Pakete
- Spezielle Konfiguration der SW
- Leichte De- und Installation von Programmen

fällt noch jemandem was ein?
Gruß Nico

-- 
Nico Golde - 310777820@ICQ
nico@ngolde.de | nion@gmx.net | http://www.ngolde.de
GPG: FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF
Is there life after /sbin/halt -p?
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde geschreddert...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : http://coredump.buug.de/pipermail/buug-l/attachments/20041013/78974275/attachment.pgp
From fr at openoffice.de  Thu Oct 14 09:10:34 2004
From: fr at openoffice.de (Frank Ronneburg)
Date: Thu Oct 14 09:10:37 2004
Subject: [buug-l] intention eines maintainers
In-Reply-To: <20041013155027.GA3177@ngolde.de>
References: <20041013155027.GA3177@ngolde.de>
Message-ID: <20041014071034.GA3326@openoffice.de>

Quoting Nico Golde <nico@ngolde.de>:
> ich halte demnächst einen vortrag über die erstellung eines debian
> pakets.
> ich suche noch gründe für das bauen von paketen, bis jetzt hab ich:

Ich sortiere das mal.

> - Software ist nicht als Debian-Paket verfügbar

Das ist ein Grund ein Paket zu bauen. 

> - Eingliederung von SW in das Debian-Paketsystem

Das bedeutet: vor alle Debian-Anwender leicht verfügbar.

> - Leichte De- und Installation von Programmen

Vorteil eines Paketmanagements, kein Grund ein Paket zu bauen. Leg alles was
zu der SW gehört nach /blabla und du kannst einfach das Verzeichniss löschen.
Auch einfach :-)

> - Spezielle Konfiguration der SW
> - Erweiterung (patches etc.) vorhandener Pakete

Die beiden Punkte sind spezielle Anpassungen für "private" Pakete. Sowas
landet ja nicht auf einem Debian Server.

> - Ziel offizieller Maintainer

Das ist eine private Sache...


Ich denke über das bauen von Paketen kommt man schnell dazu offizielle oder
inoffizielle (private) Pakete zu haben. Bei letzteren solltest Du was zu
Debian-Repositories erzählen (wie mache ich meine Pakete verfügbar via APT).

Gründe ein Paket zu bauen wären:
 - Update der Konfiguration über pre-/postinst Skripte
 - keine Backups nötig ;-) Das Zeug liegt ja auf hunderten Servern im Netz.
 - Abhängigkeiten werden mit installiert
 - Konflikte werden gelöscht
 - Emfehlungen als Vorschläge für sinnvolle Pakete
 
Weiteres:

Interessant wäre auch ein Überblick was es an Paketformaten gibt und was die
Unterschiede sind.

alien, debconf


muss jetzt los.... sorry.

fr
-- 
Debian GNU/Linux Anwenderhandbuch: http://debiananwenderhandbuch.de
GPG Key:887EB817 2000-12-12 FD97 87F0 A948 E412 E2AF  F742 5F9D D632 887E B817
Debian - DEvelopment Belongs to Interlinked and Active Networks
From nico at ngolde.de  Thu Oct 14 13:08:24 2004
From: nico at ngolde.de (Nico Golde)
Date: Thu Oct 14 13:38:49 2004
Subject: [buug-l] intention eines maintainers
In-Reply-To: <20041014071034.GA3326@openoffice.de>
References: <20041013155027.GA3177@ngolde.de>
	<20041014071034.GA3326@openoffice.de>
Message-ID: <20041014110824.GB2324@ngolde.de>

Hallo Frank,

* Frank Ronneburg <fr@openoffice.de> [2004-10-14 12:47]:
> Quoting Nico Golde <nico@ngolde.de>:
> > ich halte demnächst einen vortrag über die erstellung eines debian
> > pakets.
> > ich suche noch gründe für das bauen von paketen, bis jetzt hab ich:
[...] 
> > - Eingliederung von SW in das Debian-Paketsystem
> 
> Das bedeutet: vor alle Debian-Anwender leicht verfügbar.

vor? was meinst du?

> > - Leichte De- und Installation von Programmen
> 
> Vorteil eines Paketmanagements, kein Grund ein Paket zu bauen. Leg alles was
> zu der SW gehört nach /blabla und du kannst einfach das Verzeichniss löschen.
> Auch einfach :-)

mhm, hast recht.

> > - Spezielle Konfiguration der SW
> > - Erweiterung (patches etc.) vorhandener Pakete
> 
> Die beiden Punkte sind spezielle Anpassungen für "private" Pakete. Sowas
> landet ja nicht auf einem Debian Server.

geht ja auch nicht darum. ist ja auch fuer private anwedender der
vortrag.

> Ich denke über das bauen von Paketen kommt man schnell dazu offizielle oder
> inoffizielle (private) Pakete zu haben. Bei letzteren solltest Du was zu
> Debian-Repositories erzählen (wie mache ich meine Pakete verfügbar via APT).

das ist eine gute idee. danke!

> Gründe ein Paket zu bauen wären:
>  - Update der Konfiguration über pre-/postinst Skripte
>  - keine Backups nötig ;-) Das Zeug liegt ja auf hunderten Servern im Netz.
>  - Abhängigkeiten werden mit installiert

^^ hab ich überlegt, andererseits muss man die ja rausfinden, wenn man
das paket nur fuer sich baut und dann kann man auch das tar nehmen und
die abhängigkeiten vorher selber installieren.

>  - Konflikte werden gelöscht

das gleiche problem.

>  - Emfehlungen als Vorschläge für sinnvolle Pakete

? versteh ich nicht :)

> Weiteres:
> 
> Interessant wäre auch ein Überblick was es an Paketformaten gibt und was die
> Unterschiede sind.

hab mich zu wenig mit rpm und anderen pakete beschäftigt.

> alien, debconf

alien ist ne super idee. debconf hab ich noch nie benutzt, zumindest
nicht in einem eigenen paket.
gruß und danke
nico
-- 
Nico Golde - 310777820@ICQ
nico@ngolde.de | nion@gmx.net | http://www.ngolde.de
GPG: FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF
Is there life after /sbin/halt -p?
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde geschreddert...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : http://coredump.buug.de/pipermail/buug-l/attachments/20041014/e154f29c/attachment.pgp
From mw at miwie.in-berlin.de  Thu Oct 14 13:47:42 2004
From: mw at miwie.in-berlin.de (Michael Wiedmann)
Date: Thu Oct 14 13:47:46 2004
Subject: [buug-l] intention eines maintainers
In-Reply-To: <20041014110824.GB2324@ngolde.de>
References: <20041013155027.GA3177@ngolde.de>
	<20041014071034.GA3326@openoffice.de>
	<20041014110824.GB2324@ngolde.de>
Message-ID: <1097754462.416e675e94328@webmail.in-berlin.de>

Zitat von Nico Golde <nico@ngolde.de>:

> >  - Emfehlungen als Vorschläge für sinnvolle Pakete
> 
> ? versteh ich nicht :)

Gemeint sind IMHO die "Recommends" bzw. "Suggests" Einträge im "control"-file.

Michale
-- 
From mw at miwie.in-berlin.de  Mon Oct 25 12:38:15 2004
From: mw at miwie.in-berlin.de (Michael Wiedmann)
Date: Mon Oct 25 12:38:17 2004
Subject: [buug-l] Java: System.load("...")
Message-ID: <1098700695.417cd7979c2e7@webmail.in-berlin.de>

Hat jemand schon einmal versucht mit "java.lang.System.load(/path/to/file.so);"
ein shared object mit nativem Code zu laden und kann sagen, ob der notwendige
absolute Pfadname auch in "ld.so.conf" konfiguriert werden muß?

Michael
-- 
From cbiedl at gmx.de  Sun Oct 31 01:09:08 2004
From: cbiedl at gmx.de (Christoph Biedl)
Date: Sun Oct 31 01:22:01 2004
Subject: [buug-l] netfilter-Probleme mit 2.6.9
Message-ID: <1099175141@msgid.manchmal.in-ulm.de>

Es wurde schon geunkt, Linux Kernel 2.6.9 wäre mal wieder ein brown
paper bag release, und zumindest im Bereich netlink fliegt bei mir
ein Rechner ohne patch reproduzierbar auf die Nase, und beim Laden von 
maestro oopste es, allerdings ohne weitere Folgen.

Nun aber macht netfilter einigen Ärger und zuerst die Frage, ob jemand
ähnliches berichten kann oder gehört hat.

Beobachtung: Ziemlich viel "invalid" Zeugs.

Wer sinngemäß "-m state --state INVALID -j LOG --log-prefix 'invalid: '"
in den chains hat, der sieht dann gelegentlich was im Logfile. Soweit
erkennbar, passiert das dann, wenn jemand meine IP spooft und damit ein
Paket in die Welt schickt, das zurückkommt und mein Kernel von nichts
weiß - so weit, so gut.

Nun allerdings passiert mir das erheblich häufiger, aber ohne
erkennbares Muster: In einer stehenden (tcp-)Verbindung nennt der Kernel
ein Paket plötzlich "invalid", und darüber bricht danach die Verbindung
zusammen. Als nächstes werde ich wohl solchen Paketen ein '-j ACCEPT'
spendieren, aber das ist keine Lösung.

Beispiel:
kernel: invalid: IN=eth0 OUT= MAC= SRC=$(src) DST=$(dst) \
LEN=52 TOS=0x10 PREC=0x00 TTL=63 ID=18300 DF PROTO=TCP SPT=42804 DPT=22 \
WINDOW=16022 RES=0x00 ACK URGP=0  

Es liegt, mit tcpdump nachgeprüft, _nicht_ am window scaling problem.
Das hatte ich neulich schon anderswo, ich weiß, wie sich sowas anfühlt.
Details: http://lwn.net/Articles/92727/
Sowieso sind alle beteiligten Rechner ($src, router, $dst) Linux.

Irgendjemand, bei dem es jetzt klingelt?

So nebenbei, gibt es irgendwo eine Dokumentation, was der "INVALID"
state eigentlich genau ist? Ich für mich übersetze es mit "Der Kernel
müßte zu diesem Paket eine Vorgeschichte (via conntrack) haben und dann
wäre es RELATED und/oder ESTABLISHED. Weil nichts davon zutrifft, ist
mit diesem Paket was faul." Ist das sinngemäß richtig?
Der Blick in die Kernelsourcen ist ohne Wissen um das Drumherum wenig
hilfreich.

Achja, Downgrade auf 2.6.8.1 ist leider keine Option - es sei denn, ich
mache mal für die Unterstützung bestimmter Hardware einen Backport.
Dafür ist der Leidensdruck (noch) nicht hoch genug.

    Christoph
From cbiedl at gmx.de  Sun Oct 31 13:20:44 2004
From: cbiedl at gmx.de (Christoph Biedl)
Date: Sun Oct 31 13:20:57 2004
Subject: [buug-l] netfilter-Probleme mit 2.6.9
In-Reply-To: <1099175141@msgid.manchmal.in-ulm.de>
References: <1099175141@msgid.manchmal.in-ulm.de>
Message-ID: <1099225021@msgid.manchmal.in-ulm.de>

Christoph Biedl wrote...

> Beobachtung: Ziemlich viel "invalid" Zeugs.

Ich erhöhe um:

# iptables -vnL OUTPUT
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source    destination         
    1    40 LOG        all  --  *      *       0.0.0.0/0 0.0.0.0/0           state INVALID LOG flags 0 level 4 prefix `invalid: ' 
    1    40 ACCEPT     all  --  *      *       0.0.0.0/0 0.0.0.0/0           state INVALID
(...)

Sprich: Der Kernel selbst erzeugt Pakete, die er anschließend für
"invalid" hält. Vor der weiteren Benutzung von 2.6.9 möchte ich
persönlich deshalb abraten.

> Achja, Downgrade auf 2.6.8.1 ist leider keine Option - es sei denn, ich
> mache mal für die Unterstützung bestimmter Hardware einen Backport.

Der wird jetzt gleich getestet.

    Christoph
From debacle at debian.org  Sun Oct 31 23:17:50 2004
From: debacle at debian.org (W. Borgert)
Date: Sun Oct 31 23:18:22 2004
Subject: [buug-l] Debian automatisch installieren: d-i preseed vs. FAI
Message-ID: <20041031221749.GA18798@k6.in-berlin.de>

Da Flamewars ueber Emacs vs. vi und Linux vs. BSD etwas aus
der Mode gekommen sind, schlage ich ein eher esoterisches
Thema vor: Automatische Installation von Debian.

Ich habe mich vor ca. einem Jahr etwas mit FAI (Fully
Automatic Install) beschaeftigt und weiss, dass es einige
FAI-Power-User auf dieser Liste gibt.  Stoerend fuer meine
Zwecke finde ich bei FAI die Notwendigkeit einer relativ
komplexen Infrastruktur.  Ein alternativer Ansatz ist die
Verwendung des neuen Debian Installers ("d-i") und
"pre-seeding" der debconf-Werte.

Man kommt damit weder an die Vollautomatisierung von FAI
heran, noch an die Flexibilitaet, aber fuer viele Zwecke
duerfte d-i reichen.  Man koennte das "to a greater or
lesser extent automatic install (TAGOLEAI)" nennen.

Frage: Wer hat schon mit d-i und den Tricks zur
Automatisierung gearb^H^H^Hspielt?  Wie sind Eure
Erfahrungen im Vergleich zu Anaconda/Kickstart, autoinstall,
FAI, replicator, systemimager, ...?  Was fuer Methoden setzt
Ihr ein (pre-seed, installer-hooks, eigene udebs)?

Cheers,
-- 
W. Borgert <debacle@debian.org>, http://people.debian.org/~debacle/
