Frans Pop wrote:
=== D-I STRING FREEZE: Thu 12 Okt, 00:00 UTC - Sun 22 Okt, 00:00 UTC ===
Hi folks,
This mail really should have gone out at least two and probably three
weeks earlier. Blame goes to the discussions on d-{private,vote,wherever}
which resulted in a serious drop in my motivation in recent weeks and in
me dragging my heels on preparing the release.
My apologies for letting you all down.
GENERAL STATUS
==============
The most important work planned for RC1 has been done and the installer in
general works well, although some finishing touches and testing are still
planned in the run up to Release Candidate 1 of the installer.
I don't have a hard planned release date yet, but it will probably be
first week of November. Detailed planning and updates will be sent to
d-boot and d-release lists.
General status and preparations for Etch RC1 can be found on [1].
As it looks now RC1 will be released with kernel 2.6.17, unless 2.6.18 is
ready to migrate to testing in time for us to make the switch before the
release. If not, we plan to switch to 2.6.18 ASAP after RC1 and release
RC2 ASAP after 2.6.18 does migrate to testing.
How can you help?
-----------------
If you have some time, please help us by testing the installer. We need
testing especially for the non-mainstream architectures and new features
recently introduced in the installer (e.g. encrypted partitioning).
Especially welcome is also specific testing by e.g. maintainers of
packages/functionality used in the installer: RAID/LVM support, PCMCIA,
filesystems (JFS, XFS, ...), bootloaders, etc.
Please check if the bits *you* care about are supported well!
Watch out for calls for testing on d-d-a!
GRAPHICAL INSTALLER
===================
The graphical installer now, for the first time, uses udebs built from
official GTK library packages (2.8.x), which means we will be able to
drop the various unofficial packages we have been using up to Beta 3.
Thanks to Dave Beckett, Loïc Minier and Josselin Mouette for helping us
get this far!
The GNOME maintainers have decided to stay with 2.14 and GTK 2.8.x for
Etch. This means that g-i will also stay with the current 2.8.x libs, so
until the release we need to focus on that and leave work on 2.10.x for
post-Etch.
There is one RC issue that will need to be resolved before RC1: #390683.
Just today mike emmel fixed the "boom" bug, it should technically
possible switching to GTK+ 2.10.x.
Moreover, after some debugging from my side yesterday mike possibly
found where to look to fix #390683.
If mike manages to fix #390683, we should be able to backport the fix
into our patch tarball for GTK 2.8.20, unless (i guess) the fix is
located in that huge block of code added in july to corrctly implement
painters, which our tarball currently does not include because it's
dated May 2006.
In the latter case, we should perform a from scratch backport of the
gtkdfb backend found in current GTK 2.10 CVS to 2.8.20.
In the case a clean backport should be overcomplicated (i failed in this
some weeks ago), would this be a valid reason to switch to a clean GTK
2.10.x set of libs for the d-i only?
cheers
Attilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
