Log from the Debian Installer team meeting of Dec. 14th 2005, 21:00UTC
----------------------------------------------------------------------

People who speak below:

attilio   : Attilio Fiandrotti
bouz      : Denis Barbier
bubulle   : Christian Perrier
eugen     : Eugenyi Meschscheryakov
fjp       : Frans Pop
fs        : Frederik Schueler
joeyh     : Joey Hess
Kamion    : Colin Watson
kmuto     : Kenshi Muto
makx      : Maximilian Attems
minghua   : Ming Hua
Mithrandir: Tollef Fog Heen
stappers  : Geert Stappers
tyuyu     : Hidetaka Iwai
vorlon    : Steve Langasek
zinosat   : Davide Viti
zinoviev  : Anton Zinoviev

Otavio Salvador was absent with notification.

Hours are European Time (UTC +0100):

22:00 -!- bubulle changed the topic of #debian-boot to: Team meeting in progress: Preparation of Etch installer beta 2 | GTK installer status (font handling)
22:00 < bubulle> OK here we are....
22:00 < bubulle> and immediately with the first topic
22:00 < bubulle> GTK installer status (font handling)
22:00 < fjp> First I'd like to say thanks to everybody who's worked on this.
22:01 < bubulle> who can summarize?
22:01 < zinosat> http://wiki.debian.org/DebianInstallerGUIFonts
22:01 < fjp> I feel we're making real progress.
22:01 < bubulle> both directions, right? Font reduction and font/language dependency?
22:01 < bubulle> both techniques will be used?
22:01 < fjp> zinosat: ?
22:01 < Kamion> bubulle: I'm sort of here but need to go to bed early tonight - I only got three hours of sleep last night so catching up is kind of urgent
22:02 < zinosat> yes, we  have started playing with those things
22:02 < bubulle> will things be usable soon?
22:03 < zinosat> first goal IMO is to cover all langs, then reduce as much as we can
22:03 < fjp> Who thinks we should do new daily images with "current font status"?
22:03 < bubulle> not sure we can cover all langs for a beta2
22:03 < zinosat> I just found out for example that there are no fonts for bengali: will post more infos asap
22:04 < bubulle> zinosat: when needed, we'll ping the debian-in folks
22:04 < zinosat> so we need to see if everything is there: basically we need reports from native language speakers
22:04 < minghua> BTW the new screenshots for Chinese kmuto posted all look reasonable to me
22:04 < fjp> bubulle: Yes, I'd like to see someone involved and trying things from Indic languages pov
22:04 < bubulle> which means that new daily images should have "the current font status" as fjp said
22:05 < bubulle> fjp: OK, I'll do my best to push the Indic ppl in
22:05 < zinosat> I can provide screenshot and isos
22:05 < bubulle> "the current font status" is the tarball, right?
22:05 < zinosat> mostly
22:05 < fjp> Does anybody know good/bad Cyrillic, Hebrew and Greek look using FreeFont?
22:06 < eugen> bad
22:06 < zinosat> hebrew seems ok
22:06 < zinosat> http://lists.debian.org/debian-boot/2005/12/msg00511.html
22:06 < bubulle> eugen: ideas for a good font?
22:06 < zinoviev> eugen: why bad?
22:06 < bubulle> eugen: with a correct "k" of course
22:06 < eugen> DejaVuSans
22:06 < minghua> dejavu covers cyrillic preetty well
22:06 < eugen> last version, not in debian now
22:07 < vorlon> (half-here, btw)
22:07 < bubulle> who maintains the package?
22:07 < eugen> zinoviev: there are not hints in it
22:07 < fjp> OK. That means we need to delete cyrrilic from FreeFont. Can someone provide unicode ranges on wiki?
22:07  * stappers remembers vaguely that Hebrew and Arab fonts are related
22:07 < minghua> the problem with dejavu is that it build-depends fontforge
22:07 < eugen> bubulle: new version requires new fontforge
22:07 < zinosat> I would suggest mailing on d-boot about these details and I'll link the messages in the wiki (or fill the wiki directly)
22:07 < minghua> the dejavu maintainer would like to update the debian package, but has to wait for new fontforge
22:08 < bubulle> OK for cyrillic. I think we have the needed info
22:08 < bubulle> what about CJK?
22:08 < bubulle> kmuto, tyuyu: anything? good or wrong?
22:08 < bubulle> minghua ^^^
22:09 < kmuto> I wrote summary, http://people.debian.org/~kmuto/d-i/cjk/cjk.html. For Japanese, current xfonts-wqy is bad for us.
22:09 < fjp> I think current situation for CJK was described very will in latest mail from kmuto
22:09 < minghua> The problem about Japanese using Chinese fonts looks ugly is really a concern
22:09 < fjp> That's the codepoint overlap issue, right?
22:09 < kmuto> fjp: yep
22:09 < minghua> I looked at kmuto's summary, all look reasonable.  I have some preference, but probably just personal
22:10 < bubulle> so, in short we can say you ppl are converging towards a solution for a correct Japanese?
22:10 < fjp> minghua: Please reply anyway and ask friends for comments.
22:10 < zinosat> kmuto, what about Korean?
22:10 < minghua> kmuto: does the Japanese Windows use outline font or bitmap font for the UI?
22:10 < bubulle> we should think about pinging the -chinese lists
22:10 < bubulle> minghua: will you?
22:11 < kmuto> zinosat: I couldn't read Korean, but shrinked font works also, I think.
22:11 < bubulle> zinosat: IIRC, Korean was said to be OK....
22:11 < minghua> fjp: yes, will reply, but have to wait until today
22:11 < bubulle> OK, then, let's avoid to go forward....anything to add about fonts?
22:12 < minghua> s/today/tonight/
22:12 < kmuto> minghua: outline font.
22:12 -!- bubulle changed the topic of #debian-boot to: Team meeting in progress: Preparation of Etch installer beta 2 | GTK installer status (releasable or not?)
22:12 < fjp> Just that the option of switching fonts in the rc file still looks problematic.
22:12 < eugen> are there any g-i images?
22:12 < fjp> Help there is probably welcome
22:12 < bubulle> so....is the g-i releasable along with beta2?
22:13 < minghua> kmuto: I think that's the problem, as the Chinese version uses bitmap.  People are just accustomed to that
22:13 < fjp> Releasable: Depends on solving the udeb dependency issue.
22:13 < bubulle> fjp: I would say releasing it would be likely....
22:13 < bubulle> ...but delaying beta2 is probably unlikely, right?
22:13 < minghua> bubulle: I'll send mails in Chinese to the -chinese lists
22:13 < fjp> IMO we cannot release if for building we depend on having udebs in localudebs.
22:13 < zinosat> as for the libs I think it'll take a while mainly for burocracy
22:13 < fjp> (as that means you cannot autobuild)
22:14 < bubulle> fjp: OK...means we will still release it aside of D-I as a kind of "alpha2"?
22:14 < fjp> I gave the dpkg-dev solution a try, but failed misserably.
22:14  * bubulle would vote for not delaying beta2 for g-i
22:14 < fjp> joeyh: We're probably going to need professional help there...
22:14 < minghua> kmuto: for now I would say go with outline fonts (uming?) in g-i and make Japanese pretty at first, Chinese in outline fonts is reasonably good
22:14 < fjp> bubulle: Ack.
22:15 < fjp> bubulle: We can try doing CD images this time though.
22:15 < joeyh> well, I can try to play around with it
22:15 < zinosat> probably wise choice not to delay it
22:15 < bubulle> So, that brings the conclusion. If we want to releas an official g-i, some investment has to be done..:)
22:15 < bubulle> Kamion: no hope for "professionnal help" from the Ubuntu side?
22:15 < fjp> joeyh: Alternative is probably fixing all udebs by doing depends manually so that build system does not choke.
22:16 < Kamion> bubulle: it's unlikely I'm afraid, we're concentrating on a liveCD-based installer this release
22:16 < bubulle> ok
22:16 < joeyh> have you tried just fixing up the deps in the Packages files and see it that satisfies apt?
22:16 < fjp> joeyh: Let's discuss tomorrow or something.
22:16 < joeyh> ok
22:16 -!- bubulle changed the topic of #debian-boot to: Team meeting in progress: Preparation of Etch installer beta 2 | target release date
22:17 < fjp> One more g-i issue please...
22:17 < bubulle> *this* will define our goals for the next topics...
22:17 < bubulle> ooops sorry
22:17 < fjp> Option of live meeting in Extremadura
22:17 -!- bubulle changed the topic of #debian-boot to: Team meeting in progress: live meeting in Extremadura?
22:17 < bubulle> I give you 5 mins..:-)à
22:18 < fjp> There was an announcement that sponsored meetings can be held for development work / discussion.
22:18 < bubulle> *that* would be a very good idea yes
22:18 < kmuto> at Spain?
22:18 < fjp> I think it would be a nice idea and given current status of g-i I think a lot of work could be done at such a meeting.
22:18 < fjp> kmuto: Yes.
22:18 < bubulle> kmuto: unfortunately for you yes
22:19 < bubulle> fjp: stockholm gave a few slots: January, March.....would this be possible?
22:19 < fjp> I'd prefer sooner rather than later myself.
22:19 < bubulle> fjp or zinosat do you launch the idea in -boot?
22:19 < bubulle> so I guess January
22:20 < fjp> zinosat: Would you like to see who's initerested and set it up?
22:20 < zinosat> ok. I have no experience with it but I'm interested
22:20 < fjp> stockholm has already said OK in principle.
22:21 < bubulle> this would be January 18-22
22:21 < bubulle> zinosat: basically it needs recording interested people and coordinate with local folks I guess
22:21 < fjp> zinosat: It's mostly finding out who wants to go, maybe set some goals for the meeting and arranging practical things with stockholm and local contacts.
22:21 < bubulle> OK, zinosat got his mission..:)
22:21 < zinosat> Ok I jump on the boat :)
22:22 < bubulle> fjp: OK to move to next topic?
22:22 < fjp> Any more questions/comments on g-i?
22:22 < fjp> Last chance...
22:22 -!- bubulle changed the topic of #debian-boot to: Team meeting in progress: Preparation of Etch installer beta 2 | target release date
22:22 < fjp> Too late ;-)
22:22 < bubulle> fjp: up to you here
22:22 < fjp> K.
22:23 < fjp> As noted in the agenda, this probably will depend very much on kernel and initrd-generator status. We'll have to watch that.
22:23 < bubulle> your target was end January, right?
22:24 < fjp> 2.6.14 still has a few RC bugs and yaird and initramfs-tools have problems with quite a few configurations
22:24 < fjp> Yes.
22:24 < makx> 2.6.14 was decided to default on yaird
22:24 < fjp> But there is no use releasing without 2.6.14 or .15 in testing.
22:24 < makx> next will be for initramfs-tools
22:24 < bubulle> which means we should stop risky changes right now and refocus on a release
22:24 < fjp> joeyh: Agree?
22:25 < joeyh> unless we have some other good improvements and the kernel is very delayed
22:25 -!- bubulle changed the topic of #debian-boot to: Team meeting in progress: Preparation of Etch installer beta 2 | 2.6.14 (or 15?) kernel status
22:25 < fjp> bubulle: There is still some things we need to finish, but on d-i side I think things are generally going OK.
22:25 < bubulle> seems obvious..:-)
22:25 < makx> klibc need some polish on various archs
22:25 < makx> jbailey has done some real nice work in that area
22:26 < makx> and i'll expect more.
22:26 < Kamion> is it worth sticking with klibc?
22:26 < fjp> makx: Yes, there is definite progress on all fronts and load of good work being done.
22:26 < bubulle> would a common d-i team/kernel team meeting help?
22:26 < makx> busybox doesn't build on sarge glibc atm
22:26 < Kamion> I understood from jbailey and others that switching to glibc was the long-term plan
22:27 < fjp> bubulle: Doubt it at this point.
22:27 < bubulle> k
22:27 < Kamion> (because klibc is only a win if *everything* that you might ever want to put in the initramfs is built against klibc, and that isn't feasible at the moment and arguably won't ever be)
22:27 < bubulle> can we summarize: what currently blocks 2.6.14 for testing?
22:27 < makx> well the klibc based as obvious advantages for upgrade
22:28 < makx> but shure there is no klibc based mdadm or evms or.. in sight
22:28 < fjp> makx: About initrd generators: ATM d-i only has support for initramfs-tools in base-config postinst script although yaird seems to work OK mostly when pulled in as dependency.
22:28 < Kamion> s/base-config/base-installer/
22:29 < fjp> makx: We'll probably want to choose one or the other with current preference for initramfs-tools because of size
22:29 < bubulle> more stuff to add about kernel status?
22:29 < fjp> I guess we can use different initrd tool for different arches though.
22:29 < makx> powerpc arch split isn't worket out afaik
22:29 < bubulle> (nothing is really clear for me but hope it is for you folks!)
22:29 < fjp> makx: That's 2.6.15 right?
22:30 < makx> fjp: not that was nacked by Manoj arch specific k-p snippets.
22:30 < fjp> Ah.
22:30 < makx> fjp well it began for 2.6.14 but most work is in 2.6.15
22:30 < bubulle> hmmmm, another subtopic?
22:31 -!- bubulle changed the topic of #debian-boot to: Team meeting in progress: Preparation of Etch installer beta 2 | network interfaces issue
22:31 < bubulle> who can explain?
22:31 < fjp> makx: Are you saying different initrd-generator for different arches is not an option?
22:31 < makx> yes
22:31 < fjp> joeyh: ?
22:32 < fjp> Let me try then...
22:32 < joeyh> if the system has two interfaces there seems to be a very good chance d-i will make one eth0 and the installed system will make the other eth0..
22:32 < joeyh> I don't think anyone knows why, though it certianly involves udev
22:32 < Kamion> I suggest dragging in Scott James Remnant on this
22:33 < Kamion> if no-one else does it I'm going to collar him on Monday anyway to sort out network interface plugging in Ubuntu, so ...
22:33 < fjp> Kamion: That would be great.
22:33 < joeyh> we're still using discover1 in d-i, perhaps that's the problem
22:33 < eugen> it should be possible to use ifrename, is not it?
22:33 < Kamion> (he maintains Ubuntu's udev and in general knows what's going on there)
22:33 < Kamion> eugen: ifrename has issues renaming eth0
22:33 < bubulle> joeyh: which brings us to the next subtopic: dropping discover: before or after beta2?
22:33 < Kamion> it *might* be possible, but IMO doing it directly in udev is a much cleaner solution
22:34 -!- bubulle changed the topic of #debian-boot to: Preparation of Etch installer beta 2 | dropping discover: before or after beta2?
22:34 < Kamion> I have no evidence at the moment of whether it's possible to use ifrename properly with current kernel/udev
22:34 < fjp> Yes, we could try dropping discover and see what that does. I'm afraid for support of devices that do not have sysfs support though.
22:34 < Kamion> I think sbus is still lagging there
22:34 < bubulle> fjp: would this be reverted in case it's too broken?
22:35 < bubulle> s/would/could
22:35 < fjp> And some ide and scsi devices.
22:35 < makx> Kamion concerning sbus hch proposed to do a patch if a tester comes up
22:35 < fjp> bubulle: Sure.
22:35 < Kamion> macio has decent sysfs support upstream now AFAIK, although we've been prodding that by hand anyway
22:35 < bubulle> fjp: so given that we're anyway waiting for the kernel, we can probably try, no?
22:35 < Kamion> fjp: most of those devices won't work anyway if the kernel doesn't know the id
22:35 < fjp> makx: trave11er I'd guess, or else ask on d-sparc
22:35 < makx> also our kernel is carring a patch around that breaks modular ide.
22:35 < Kamion> apart from the ide-generic grabbing devices it shouldn't thing
22:36 < makx> the patch is removed in latest svn
22:36 < Kamion> (you *have* to load all specific IDE drivers before you load ide-generic, otherwise you'll lose DMA and that sort of thing)
22:36 < Kamion> and I think in some cases it just flat-out doesn't work if ide-generic grabs the device
22:36 < bubulle> (we're late) so, drop or not drop?
22:37 < makx> indeed ide-generic can be faster than the real driver
22:37 < fjp> Kamion: What about the loads of reports where no cdrom if SATA driver loaded before generic drivers?
22:37 < Kamion> fjp: how many of those are with >= 2.6.14?
22:37 < fjp> Kamion: Good question...
22:37 < Kamion> this stuff has been changing very fast
22:38 < bubulle> fjp: all this seems to be a release manager call...which probably needs deeper thinking, don't you think?
22:38 < Kamion> frankly our lives will be a lot easier if we use udev for this, because that's basically what everyone else on these kernel versions is doing
22:38 < Kamion> otherwise we're just going to be playing catch-up with hacks in hw-detect
22:38 < fjp> Kamion: Ack.
22:38 < makx> a good dialogue with the udev maintainer would be a plus
22:39 < fjp> joeyh: Objections to dropping discover before beta2?
22:39 < makx> i know some of his wishlist and already discussed them with fs for the next .config
22:39 < fjp> (or at least testing)
22:39 < joeyh> I'm fine with the idea of dropping it to see how it goes
22:39  * bubulle would vote for an attempt to drop discover
22:39 < fjp> K.
22:40 < bubulle> So, let's move on
22:40 < Kamion> note that if we drop discover we have to arrange to pull in pciutils-udeb for netcfg interface name display
22:40 < Kamion> but at least that's available now (hi bubulle!)
22:40 -!- bubulle changed the topic of #debian-boot to: Preparation of Etch installer beta 2 | release date
22:40 < joeyh> okay. is the rest of the code ready?
22:40 < Kamion> still need readlink -f ideally
22:40 < Kamion> (but busybox stuff is later on the agenda)
22:40 < fjp> Kamion: Do we need that in initrd? probably yes for network based installs and less of an issue for other methods.
22:40 < Kamion> fjp: exactly
22:41 < bubulle> Kamion: we can move busybox stuff right now if you feel it's appropriate
22:41 < fjp> waldi: Here?
22:41 < Kamion> no it's ok, I have to go nowish anyway
22:42 < bubulle> fjp: given all these uncertain things do you still plan end January?
22:42 < fjp> waldi has been main maintainer for busybox, correct?
22:42 < Kamion> yes
22:42 < joeyh> yes, but I don't think he will mind an nmu
22:42 < joeyh> its maintainer is set to debian-boot
22:43 < Kamion> it also wants the umount -a fix
22:43 < joeyh> and some stuff for partman-crypto
22:43 < fjp> OK. Let's ask if waldi can do a new release (probably including new upstream?) or else try find someone else.
22:43 < Kamion> I don't think new upstream's necessary, but YMMV
22:44 < Kamion> not sure there *is* a new upstream actually
22:44 < joeyh> 1.01 is current upstream
22:44 < fjp> Kamion: I thought the readlink -f thing was included upstream?
22:44 < Kamion> fjp: yes, but on trunk rather than the 1.0 branch
22:44 < joeyh> there's a prerelease..
22:45 < Kamion> it's not a large patch though, busybox features rarely are
22:45 < bubulle> so as a summary for the busybox topic: we'd like to have a new release...with or without upstream sync, preferably sync if a new release exists...right?
22:46  * bubulle assumes he's right..:-)
22:46 < fjp> new upstream may be risky. backporting may be safer given our timeframe
22:46 < bubulle> speaking of timeframe....we still haven't decided if end January is realistic or not
22:47 < bubulle> maybe you prefer we move this at the end of the "beta2 preparation"?
22:47 < fjp> Depends on kernel progress IMO.
22:48 < fjp> makx: How does 2.6.15 release look? Soon?
22:48 < makx> yeah pretty much stabilising
22:48 < makx> next 2 weeks
22:48 < stappers> RSN
22:48 < stappers> :-)
22:49  * makx opts for christmas present
22:49 < fjp> I'll post a proposed schedule soon to the list.
22:49 < joeyh> I think that dec 25th might be a bit ambitious :-)
22:49 < bubulle> fine...this is what I expected..:-)
22:49 < fjp> And already preparing to allow some udebs into testing.
22:50 < fjp> Let's move to ports status.
22:50 < bubulle> so can we carve in stone "n o mor erisky changes"?
22:50 -!- bubulle changed the topic of #debian-boot to: Preparation of Etch installer beta 2 | ports status
22:51 < bubulle> wow, /me falls asleep
22:51 < bubulle> porters?
22:51  * fjp disappointed with replies to kernel status mail
22:51 < fjp> Except m68k of course.
22:52  * Kamion -> bed, will read minutes
22:52 < bubulle> yep: general feeling is low motivation from porters
22:52 < fjp> x86, sparc, ppc, amd64 generally in good shape. ia64 has enough attention too.
22:52 < fjp> Main problem is ports that have no 2.6 kernel support in d-i.
22:53  * makx will work on alpha
22:53 < fjp> makx: Cool.
22:53 < bubulle> hppa?
22:53 < fjp> hppa will probably be done by bdale JIT (just in time)
22:53 < bubulle> as usual..:-)
22:54 < bubulle> So, the conclusion of "ports status" is "everybody's sleeping...
22:54  * fjp proposes not to worry too much about arches, but also not be afraid of dropping them when they fail to keep up or ask for help.
22:54 < fs> what is the mips/mipsel status?
22:55 < fjp> Stuck on 2.4?
22:55 < makx> no kernel upgrade since longer but nice upstream work for 2.6.15
22:55 < bubulle> anything to add on ports?
22:55 < stappers> GGG what an i386 only attiude
22:55 < fjp> stappers: Wrong!
22:56 < makx> the powerpc issue was already noted, i may need to look into that too
22:56 -!- bubulle changed the topic of #debian-boot to: Preparation of Etch installer beta 2 | string freeze
22:56 < makx> because setting the arch with k-p may nicely allow to build uml from the linux-2.6
22:56 < fjp> d-i cares very much for ports but ports can't expect d-i core ppl to do all the work for them.
22:56 < bubulle> ok, we move....
22:56  * bubulle puts i18n hat on
22:56 < bubulle> in short, I think beta2 deserves a string freeze
22:57 < fjp> makx, fs: if you can help promote d-i work amongst porters, that would be very welcome.
22:57 < bubulle> fjp: will you grant us one?
22:57 < fjp> bubulle: I've been thinking about this.
22:58 < fjp> I think a lot of languages don't really need a full freeze.
22:58 < bubulle> usually a string freeze can be mixed with a feature freeze
22:58 < fs> fjp: I'll remember everyone during the next days, when I ask them about 2.6.15-rc config updates ;)
22:58 < joeyh> bubulle: how long a freeze do you think?
22:58 < bubulle> joeyh: 2 weeks is usually needed just to leave me time to awake translators
22:58 < minghua> if no string freeze, what about a guaranteed date that translations updated before this date will appear in beta2?
22:58 < fjp> I do think though that we should do a new upload for translation updates for all packages.
22:59 < fjp> minghua: ^^ :-)
22:59 < zinosat> I really would like to see wrong vars on level1 fixed for this release. level2 is mostly clean
22:59 < bubulle> anyway, we can make exceptions to string freezes (we did in the past)
22:59 < fjp> Maybe excepting packages that had recent updates but have changes pending that cannot go into the beta.
22:59 < bubulle> the only constraint is asking before changing a string
23:00 < fjp> bubulle: There is not a high rate of change in string anyway; nothing like for Sarge.
23:00 < bubulle> fjp: yep, we can make such exceptions.....
23:01 < bubulle> a few translators are more or less waiting for an "official" moment for their updates. This is why I suggest we formalize one
23:01 < fjp> I'll discourage string changes anyway and mention time frame for updates in plan.
23:01 < bubulle> that's fine by me then
23:02 < makx> bubulle: sidetopic the k-p strings seems very long now in debconf, have you gone throw cutting them done before translating?
23:02 < makx> uuh too many typos..
23:02 < stappers> call the "discourage string changes" a "freeze"
23:03 < fjp> stappers: "soft freeze" :-)
23:03 < bubulle> makx: I don't know that much about k-p strings..:)
23:03 < stappers> :-)
23:03 < fjp> Like: don't go skating
23:03 < bubulle> makx: bu I plan to have a look at it "at some moment"
23:03 < makx> please cut them down to a groggable amount ;)
23:03 < stappers> ut ken net
23:03 < bubulle> Well, folks, the next topic was "General release schedule" but I think that fjp will propsoe one...which is probably better
23:04 -!- bubulle changed the topic of #debian-boot to: Preparation of Etch installer beta 2 |status of partman-crypto and partman-auto-lvm
23:04 < joeyh> ok, on pal, there are at least 2 problems...
23:04 < bubulle> should these go in beta2?
23:04 < joeyh> it's extra priority, so it is not available by default (and as it's not a menu item, you cannot manually select it either)
23:04 < fjp> joeyh: partman-auto-lvm ready and should have priority change?
23:05 < makx> is partman-auto-lvm pressedable?
23:05 < joeyh> and it seems to be a bit broken if made available, it didn't seem to set up a root partition when I tried it
23:05 < joeyh> yes, it's preseedable
23:05 < makx> cool
23:05 < joeyh> anyway, I want to make it standard and then people can try it and see if it works
23:05 < fjp> If we want it in, I think we should make it available now.
23:05 < fjp> We can always keep it in unstable.
23:06  * bubulle agrees (though I have never used LVM..:-))
23:06 < joeyh> and if it doesn't, we don't copy it to testing of course..
23:06 < bubulle> we should expose new features to criticism anyway
23:06 < fjp> Let's add a note on d-i today that it is experimental.
23:06 < bubulle> what about -crypto?
23:06 < joeyh> partman-crypto has a nice status page, dunno if its maint is here
23:06 < fjp> Nope.
23:07 < bubulle> he recently said that it's not that ready
23:07 < fjp> -crypto is waiting on some external things, so may not be ready in time.
23:07 < bubulle> so it probably doesn't qualify for beta2
23:08 < makx> initramfs-tools needs some work for crypto root support.
23:08 < Mithrandir> it was waiting on custom widgets, wasn't it?  That's in, at least in svn
23:08 < bubulle> but we should encourage its maintainer to release it, no?
23:08 < CIA-7> debian-installer: joeyh * r32967 packages/partman/partman-auto-lvm/debian/ (changelog control): * Set priority to standard so it will be available in standard installs.
23:08 < joeyh> well, it's waiting on bustbox and gnupg
23:08 < bubulle> anything mor eon this topic?
23:09 < fjp> Don't think so.
23:09 < bubulle> Preparation of Etch installer beta 2 | instalaltion guide
23:09 < CIA-7> debian-installer: joeyh packages * r32968 /partman/partman-auto-lvm/7/: tagging version 7
23:09 < bubulle> arf
23:09 < fjp> I have already announced plan to string freeze the manual now for last updates for shared sarge/etch version
23:10 < bubulle> are there features that still need to be properly documented?
23:10 < fjp> Will do release for both sarge and etch early jan and then we stop development for Sarge and concentrate on updating for Etch
23:10 < joeyh> the new preseed docs are incomplete iirc
23:10 < fjp> Yes, everyting that is being moved to first stage.
23:11 < joeyh> oh yes, indeed
23:11 < fjp> Also installation-reports, rescue, and some others.
23:11 < vorlon> makx: was there consensus to drop the initramfs-tools conflict on the alpha kernel images?
23:12 < bubulle> antyhing more for install guide (looks like the general interest is decreasing...:-)
23:12 < makx> vorlon: nobse sent a very interested bug report concerning initramfs-tools
23:12 < makx> but there was no consesus.
23:12 < attilio> Sorry faor having arrived home late (just after g-i topic was over).
23:12 < bubulle> ahem, meeting *not* finished; folks
23:13 < makx> vorlon: regarding our failure to exec init, that is noted as yaird bug too.
23:13 < makx> i'm not sure why we picked the conflict.
23:13 -!- bubulle changed the topic of #debian-boot to: D-I meeting in progress: d-i bug squashing party
23:13 < bubulle> joeyh: ?
23:14 < joeyh> unfortunatly my holiday schedules have made scheduling it hard
23:14 < vorlon> makx: the conflict is complete crap; it makes it unnecessarily difficult for me to work on the initramfs-tools problem (which, btw, I apparently can't reproduce here yet)
23:14 < joeyh> I'll try to do it sometime
23:14 < makx> vorlon: need to send him a patch for inclusion of strace in his initramfs-tools than we'll hopefully see better why it fails.
23:14 < bubulle> joeyh: how do you see it?
23:14 < makx> vorlon: nobse set the conflict
23:14 < vorlon> makx: ok.
23:15 < bubulle> makx, vorlon: grmbl, meeting still in progress..:-)
23:15 < fjp> General note: with kernel DSA's out we may have to spend some time on stable d-i update because of kernel ABI changes planned next
23:15 < joeyh> still not sure really
23:15 < makx> bubulle: well it's bug squashing pleasure :)
23:15 < vorlon> bubulle: you wouldn't want to discourage porters from participating, would you? =)
23:16 < stappers> nope
23:16 < vorlon> (done, anyway)
23:16 < bubulle> joeyh: something like a full week of bug suqashing only (and no mor efeatures)?
23:16 < joeyh> no, more like a weekend
23:16 < joeyh> like a normal bsp except workin on the d-i bug ist instead of the rc one
23:16 < joeyh> s/ist/list/
23:17 < makx> vorlon: you tested initramfs-tools on your box?
23:17 < bubulle> joeyh: several bugs are wishlist bugs so we might have two kind of BSP: one for killing bugs and another one after a release for new often minor features
23:17 < joeyh> thus the scheduling trouble, if you look at the upcoming weekends
23:18 < bubulle> a week-end in January, then?
23:18 < joeyh> seems likely
23:18 < bubulle> 7-8?
23:19 < bubulle> on Jan 14th we will have the next meeting and 21-22 could be the G-I meeting
23:19 < joeyh> hard to choose so far ahead, but sure.
23:19 < bubulle> let's records this..:-)
23:19 < bubulle> Well, I had two more topics but I feel it's too much
23:20 < bubulle> Do everyone agree to close down the meeting?
23:20 < attilio> Would help in debugging fonts issues updating the test g-i miniiso images so that they include the new improvements to rootskel-gtk and installation-report that allow to save screenshots via web?
23:20  * stappers agrees to close the meeting
23:20 < bubulle> fjp: OK to skip the UTF-8 and console issues (not that important anyway)?
23:21 < bubulle> The next D-I meeting will be on Sat January 14th.
23:21 < bubulle> Last Saturday we used 16:00UTC which was not very successful
23:21 < fjp> bubulle: Sure. Suggest you coordinate with bouz, amck, zinoviev and other interested parties and keep list informed.
23:22 < bubulle> bouz: sorry if you came in for this....:-)...same for zinoviev (but glad to see you back)
23:22 < bubulle> I suggest 17:00 for next neeting
23:22 < bouz> bubulle: np
23:23 < bubulle> joeyh: will that be late enough for you?
23:23 < bubulle> anyway, we'll have time to slightly change this...
23:24 < fjp> bubulle: 17:00 OK with me.
23:24 < bubulle> So, I hereby close this meeting. Thanks to all people who came in and a special thanks for our now frozen friends from Japan, kmuto and tyuyu 
23:24 < zinosat> thanx *
23:24 < kmuto> :)
23:24  * fjp was very happy too to see Japanese and Chinese ppl here at this hour.