Re: beta 2 and beyond
Am Don, den 15.01.2004 schrieb Joey Hess um 04:33:
> I've gone ahead and started the beta 2 release process. CD images are in
> place and I will send out the release announcement once the web site has
> updated. (Some install media won't appear in sarge until tomorrow's
> dinstall.)
>
OK, beta2 is out now. So I suppose powermac test are no longer needed.
> I have to say that this release took longer to get done than I'd hoped.
> We started out strong, the compromise was unavoidable and was handled as
> well as can be expected, the string freeze went well, the holiday
> slowdown was worse than I expected, and then it felt to me as if things
> trailed off at the end instead of us making a big push to finish the
> release. I'm going to think about this and try to figure out things that
> went wrong and how to avoid them, and I'd appreciate any insights anyone
> might have.
Sorry I did not have much spare time to spend on d-i since christmas.
Unfortunately this is not going to change soon. I will try to do my
best.
>
> I. NEW udebs (partman, etc), that are not present in sarge.
> II. Any changes necessary for mips, alpha, and powerpc subarches,
> targeted at beta 2.
> III. udebs that are only for architectures that do not plan to
> release with beta 2 (such as boot loader installers for
> unreleased architectures)
> IV. udebs that are only for architectures that have already
> released for beta 2
> But is still closed to uploads of:
>
> X. Developmental changes of udebs that are in beta2. (busybox,
> build/, base-installer, main-menu, anna, etc, etc)
I request you to make an exception for discover as the next upload
should have no impact on d-i and fixes quite important bugs in the deb.
We might delay the next discover-data upload some day as this is more or
less cosmetic and the really important fixes are in the archive.
>
> - discover 2
> I guess all the hard work has been done. IIRC the plan is to
> upload it with a different name, so we can test installs using
> it before swtiching overything away from discover 1. If this
> does not involve renaming the existing discover udeb, it will
> meet requirement I., and can be uploaded to unstable soon.
This is already in the archive. But I jus discovered it did not build on
the autobuilders due to a problem with the build depends:
discover2 depends on kernel-headers-2.4.20-386 | kernel-headers which
yields "E: Couldn't find package kernel-headers-2.4.20-386". How can I
best solve this? Should I include the relevant kernel headers in the
package or build-depend on a kernel-headers package for every arch?
If I can't build-depend on a virtual package this is going to cause
headaches as these headers change their package name with every new
kernel released.
> - 2.6 kernel
> For some arches at least, possibly not as the default but
> available as an alternate boot on the CDs. Blocked by discover 2.
How is this connected to discover2?
Someone simply has to come up with a discover-data list for 2.6. I think
we should not put to much energy in 2.6 support as I hope most/all
hardware will be supported by 2.4 for some time. So changing to a 2.6
kernel can be done after the installation.
> - udebs and debs with same namea
> Some key changes in base-config are being blocked because we
> cannot add debs of choose-mirror, etc to the archive. At the
> same time, there is some uglyness in the initrd builds that
> could be avoided if we could have a udeb named libc6. This seems
> doable, but will require the assistance of the ftp-master and
> has the potential to cause unanticipated problems.
I'm looking forward to this.
> - switch to subversion
> It would be good to reorganise the tree, and some things are
> waiting on that being done. Since this has the potential to
> disrupt everything else during the transition, we'll have to be
> very cautious.
This would be a good idea.
> - better wireless support
> I think that a wireless-tools udeb just went in, but a frontend
> to that is needed.
yes, the wireless-tools udeb is available now. The first step would be
to include it on the netboot images.
wireless-tools-udeb should probably be priority standard so anna pulls
it in by default.
Gaudenz
Reply to: