Wann wird Etch eingefroren?

[mase76]

Hallo!
Ich will demnächst mein Debian Notebook neu einrichten. Weiss jemand, wann
Etch nun eingefroren wird, sodass sich eine Installation lohnt, ohne dass sich
grossartig was ändert? Ich habe was vom 7. August gelesen. Da sollen sämtliche
Programme vorerst eingefroren werden. Ist da was dran?
Momentan hab ich noch Sid drauf, aber dass wird mir allmählich zu instabil, wegen
der momentanen Abhängigkeiten.
Wenn ich jetzt schon Etch draufmache, was passiert dann bei dist-upgrades bis
Oktober?

[armin]

Grad zu faul nen Link zu der Mail rauszusuchen, hier aber das wichtigste:

Timeline
========

Reviewing our old schedule:

Thu 15 Jun 06: (a month ago)

last chance to switch to gcc 4.1, python 2.4
[ switch happened/happening, only some issues left ]
review architectures one more time
[ Done, added s390, sparc to release architectures again ]
last chance to add new architectures
[ Nothing ]

RC bug count less than 300
[ around ~275 for two weeks now. Actually ~390 RC bugs in testing (due
to fixes waiting for the transition) ]

Now to our next steps (and with more BSPs to come):

N-117 = Mon 30 Jul 06:

freeze essential toolchain, kernels
[ kernel freeze is probably a bit delayed ]

RC bug count less than 200


N-110 = Mon 7 Aug 06:

freeze base, non-essential toolchain (including e.g. cdbs)
review architectures one more time (only remove broken archs)

RC bug count less than 180


Fri 11 - Sun 13 Aug 06:

real-life BSP in Gütersloh, Germany, and online BSP world-wide


N-105 = Mon 14 Aug 06:

d-i RC [directly after base freeze]

RC bug count less than 170


Fri 8 - Sun 10 Sep 06:

real-life BSP in Wien (Vienna), Austria, and online BSP world-wide


Fri 6 - Sun 8 Oct 06:

real-life BSP in Espace Autogéré des Tanneries, Dijon, France,
and online BSP world-wide


N-45 = Wed 18 Oct 06:

general freeze [about 2 months after base freeze, d-i RC]
review architectures last time (only remove broken archs)
final d-i build; chance to change the kernel version

RC bug count less than 80


N = Mon 4 Dec 06:
release [1.5 months for the general freeze]

no RC bugs left!

[garibaldi]

Wenn ich jetzt schon Etch draufmache, was passiert dann bei dist-upgrades bis Oktober?

Schreib einfach "etch" statt "testing" in die /etc/apt/sources.list. Dann installierst du jetzt etch und hast keine Probleme damit, dass etch(testing) zu etch(stable) wird.

Gruß, garibaldi

[armin]

So, kam gerade rein:

Toolchain and base freeze
=========================

The toolchain is mostly in the stable state we would like to see it in
for etch. There are, however, some issues on hppa which cause us some
worries.


We have frozen the essential toolchain. Here's the list of frozen
packages:
* binutils
* build-essential
* dpkg
* gcc-defaults
* gcc-4.1
* gcc-4.0
* glibc
* make-dfsg

We will also soon freeze non-essential toolchain packages that are commonly
used in the build process. The initial list of non-essential toolchain
packages is:
* debhelper
* cdbs
* bison
* python2.4
* gcj


Packages with priority required or important are expected to be frozen next
week. The number of involved packages is 110 [3].

The canonical list of frozen packages is available from
http://ftp-master.debian.org/testing/hints/freeze

[mase76]

In der sources.list etch anstatt testing zu benutzen war mir schon klar.
Ich wusste halt nur nicht, wie viel sich noch ändert.

[apulix]

Welcher Kernel soll (wird) denn in etch verwendet werden?

[nepos]

Soweit ich weiss, soll 2.6.17 reinkommen.

[mase76]

Jo, 2.6.17 soll vorerst reinkommen.
Ich hoffe, dass es zumindest 2.6.18 wird. Da wird dann auch ivtv drin sein und der
neueste alsa-Treiber drin sein.

[jhr-online]

Offiziell ist, dass es 2.6.17 wird. So aus der Mail von Joey Schulze zu entnehmen...

jhr

[Snoopy]

Jo, 2.6.17 soll vorerst reinkommen.
Ich hoffe, dass es zumindest 2.6.18 wird. Da wird dann auch ivtv drin sein und der
neueste alsa-Treiber drin sein.

2.6.18 wird afaik wieder eine neue udev Version benötigen.
Ob das so eintritt, dass das Alles noch zu Testing rutscht...naja das bezweifele ich etwas.

[H4kk3r]

Mit der rc4 haben sie doch das mit udev zurückgenommen.

[cosmac]

Wie zurückgenommen? Beim rc4 von was?
Bitte bitte einen Link *bettel*

Besteht etwa Hoffnung, dass udev nur optional oder gar extra wird ?

[Manfred]

Wie zurückgenommen? Beim rc4 von was?
Bitte bitte einen Link *bettel*

Besteht etwa Hoffnung, dass udev nur optional oder gar extra wird ?

Was hast du gegen udev?

[cosmac]

Lies einfach mal in debianforum.de die Beiträge in denen udev
erwähnt wird. Dazu kommen noch die Klagen, dass etwas nicht
geht wo nur noch keiner gemerkt hat, dass mal wieder udev
dazwischen funkt.

udev macht einfach zuviele Probleme als dass es defaultmässig
installiert werden sollte. Mag ja sein, dass für Hotplug-CPUs echt
was bringt, aber die sind doch nicht soo verbreitet.

Dazu kommt noch, dass mir noch keiner gesagt hat, wofür es
überhaupt nötig ist. USB-Geräte, PCMCIA-Karten, mehrere Netzwerke
usw. funktionieren schon immer ohne udev. Es ist für den nicht
erkennbaren Nutzen einfach zu komplex. Wenn ich sowas haben
will, kauf´ ich mir einen Windows-PC.

[gms]

Besteht etwa Hoffnung, dass udev nur optional oder gar extra wird ?

udev war noch nie mandatory

Gruß
gms

[cosmac]

ah, o.k., es ist ja nur optional, aber warum ist es dann fast
überall installiert? Also muss es heissen: besteht Hoffnung,
dass es nicht mehr automatisch installiert wird?

[gms]

wahrscheinlich hast du dir fast überall einen Debian Standardkernel installiert. Diese hängen in Etch von den initramfs-tools ab und diese wiederum von udev.

Du wirst dir also einen eigenen Kernel bauen müssen, wenn du kein udev verwenden möchtest. "hal" darfst du auch nicht verwenden, dieses Paket ist auch abhängig von udev.

[cosmac]

wahrscheinlich hast du dir fast überall einen Debian Standardkernel installiert. Diese hängen in Etch von den initramfs-tools ab und diese wiederum von udev.

Ja klar, genau um die Standard-Installation geht es mir ja.
Da gehört kein udev rein.

Du wirst dir also einen eigenen Kernel bauen müssen, wenn du kein udev verwenden möchtest.

Ganz so "schlimm" ist es nicht. yaird ist ein ganz guter Ersatz
für die initramfs-tools und yaird hängt nicht von udev ab.
Also geht es auch mit Bordmitteln, ist ja schliesslich Debian

[gms]

yaird ist ein ganz guter Ersatz

möchte ich nicht bestreiten, für viele Anwendungsfälle mag "yaird" ein ganz guter Ersatz sein.
Manche "yaird" Anwender werden aber wahrscheinlich in erstaunen versetzt, wenn sie erstmalig den offiziellen!!! Kernelparameter "root=" benötigen würden, dieser aber unter "yaird" stillschweigend ignoriert wird.

Hier die entsprechende Bugmeldung die jedoch unter "Wishlist" eingestuft wurde:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340759