Log from the Debian Installer team meeting of March 4th 2006, 17:00UTC
----------------------------------------------------------------------

People who speak below:

bubulle   : Christian Perrier
fjp       : Frans Pop
joeyh     : Joey Hess
Kamion    : Colin Watson
makx      : Maximilian Attems
ninou     : Sylvain Ferriol
[-oskar-] : Xavier Oswald
otavio    : Otavio Salvador
sc        : Stefano Canepa
Stevie    : ?
svenl     : Sven Luther
waldi     : Bastian Blank
zinosat   : Davide Viti

Hours are European Time (UTC +0100):

18:00 < bubulle> the D-I meeting for March is now opened
18:00 < [-oskar-]> hi
18:00 < bubulle> For this meeting, we will innovate: for each part, I will give the lead to someone who is in charge of keeping the discussion alive
18:00 < bubulle> In case, the mentioned person is not here, I'll do it, of course
18:00 < bubulle> Please do you best to respect the schedule. We'll close topics after the allocated time
18:00 < bubulle> and don't talk off-topic, of course....
18:00 < bubulle> fjp: Go for introduction, please
18:00 < fjp> There have been some d-i build problems due to new localudebs handling. The last upload yesterday solved these. Currently only hppa and sparc builds missing.
18:00 < fjp> Major other delay has been a misunderstanding on my side of CD building. Let's blame that on inexperience and complexity.
18:00 < fjp> An issue with tasks for full CD installs was probably solved yesterday.
18:00 < fjp> Tests of beta2 images show no real problems so far, so yesterday's upload looks to be the final one and we can release later this week.
18:01 < bubulle> like saturday in the worst case?
18:01 < fjp> Yes, hopefully earlier.
18:01 -!- bubulle changed the topic of #debian-boot to: Beta2 release (5mins)
18:01 < bubulle> I'm a bit annoyed by the bug in Russian
18:02 < bubulle> I fear that all non UTF-8 installs half-fail
18:02 < fjp> Well, it was a known issue...
18:02 < bubulle> yep, maybe...should be in post-beta2 priorities to fix
18:02 < bubulle> I hope we'll have more ppl liek eugen or bouz involved
18:03 < bubulle> fjp: what about the floppy build failure?
18:03 < fjp> That's not a beta2 problem.
18:03 < bubulle> ah, ok
18:03 < bubulle> anything else?
18:03 < fjp> Not from me.
18:04 < bubulle> then we close that topic
18:04 < bubulle> bubulle: This part will be lead by you, please...
18:04 -!- bubulle changed the topic of #debian-boot to: Next release: beta3 or RC1? (10mins, max 15mins)
18:04 < bubulle> oops
18:04 < bubulle> OK, my part...
18:04 < svenl> fjp: tg3 modules are missing in the powerpc kernel .udebs.
18:04 < fjp> svenl: errata.
18:04 < svenl> fjp: ok.
18:04 < bubulle> The point is: will the next release be still adding new features or the first attempt to stabilize things?
18:04 < fjp> Same as prep and floppy issues.
18:05 < waldi> bubulle: new features
18:05 < fjp> me hopes ppc comminity will get active on that straight after the release.
18:05 < bubulle> in short, we need about 3-4 months for a release so we have room for only TWo releases before etch
18:05 < otavio> bubulle: we'll have the possibility to change the partitioner in g-i?
18:05 < svenl> i would vote for beta3, let's have one beta with the merged graphical installer before going to rc.
18:05 < fjp> otavio: OT
18:05 < bubulle> otavio see other topics, later
18:05 < otavio> fjp: sorry, ok
18:06 < bubulle> I also tend to think mor e"beta3" but not too much new features..:-)
18:06 < fjp> There is one reason to go for a very quick beta.
18:06 < svenl> bubulle: upcoming features are mostly g-i related :
18:06 < fjp> That is the mirror reorganisation that is planned for this month.
18:06 < svenl> - graphical partitioner for example.
18:06 < bubulle> fjp: that one was also supposed to be a very quick beta..:-)
18:07 < svenl> fjp: what is the status of the g-i build issues and the possible merge ?
18:07 < bubulle> fjp: which release date do you have in mind?
18:07 < otavio> and if we use beta3 just for g-i and errata fixes?
18:07 < fjp> Will make current mirror-chooser do the wrong thing for all arches except i386 and probably ppc.
18:07 < fjp> Early april.
18:07 < otavio> would be easier to have stable again if we have just those things done.
18:08 < bubulle> fjp: early april means we should touch much stuff after beta2 then
18:08 < svenl> otavio: i guess the g-i merge may have impact on d-i also.
18:08 < bubulle> s/should/should not
18:08 < fjp> bubulle: EPARSE
18:08 < otavio> svenl: yes, that's why I propose to use beta3 just of those and errata thinks
18:08 < fjp> Well, we should try to do the important stuff quickly.
18:09 < bubulle> OK, so message to all D-I contributors...leave minor stuff quiet even after beta2..:-)
18:09 < svenl> bubulle: huh ?
18:09 < bubulle> fix stuff in errata and focus on choose-mirror changes. Right, fjp?
18:10 < svenl> there is important things coming concerning the non-free firmware or modules that should go in beta3, but should we not raise this topic after having discussed the individual issues ?
18:10 < fjp> Not really. Just go ahead for next 2/3 weeks but concentrate on important stuff if you have to make choices.
18:11 < bubulle> so, to summarize: the next release is a beta3, will be due out April and is mostly motivated by mirror reorg.
18:11 < fjp> Yes.
18:11 < bubulle> OK, then...we have a few minutes left for that topic if ppl want to add something about beta3 and general plans
18:11 < bubulle> before we enter more specific topics
18:12 < svenl> beta3 may be in time to move to 2.6.16 kernel, not sure.
18:12 < fjp> BTW. I'm not sure if I can manage that release as I have VAC plans; no fixed dates yet though.
18:12 < bubulle> fjp: uh...actually noone else can manage a release except joeyh and you
18:13 < svenl> fjp: when do you come back from VAC ?
18:13 < fjp> Sure they can. Point is, is anybody willing?
18:13 < fjp> svenl: Depends on when, where, how long I go... :-)
18:13 < bubulle> .....big silence.....
18:14 < fjp> Anyway, let's shelve that for now.
18:14 < bubulle> and to make it clear: *i* can't (technically speaking)
18:14 < bubulle> svenl: This part will be lead by you, please
18:14 -!- bubulle changed the topic of #debian-boot to: Kernel .udeb and the way to handle out-of-tree and non-free modules (10mins, max 15mins)
18:14 < otavio> fjp: but why not to use a team to manage the release?
18:14 < svenl> i guess i would not be welcomed to it.
18:14 < svenl> ok, that is my part.
18:14 < svenl> The problematic of non-free and third party modules, as well kernel modules with non-free firmware.
18:14 < svenl> We need some way to load such non-free or third-party modules or firmware into d-i.
18:14 < svenl> Currently only one apt-source is possible, and loading from floppies is not always possible.
18:15 < otavio> svenl: this have to be fixed in anna, right?
18:15 < svenl> Well, not very speaking, but pending a GR which would allow us to ship non-free firmware in etch/main, it is well probable that important modules will be removed from main for etch, or at least their firmware.
18:15 < waldi> yes, and lib-di
18:15 < svenl> this includes tg3, the ql ones and so one.
18:16 < svenl> We have to make plans to make this happen right, and probably have them done sooner rather than later, good target for beta3.
18:16 < bubulle> has someone already begun to work p, such changes?
18:16 < bubulle> s/p,/on
18:16 < waldi> yes
18:16 < svenl> bubulle: not really, i mailed d-b, but was mostly ignored.
18:17 < waldi> (the libd-i part of the technical implementation)
18:17 < bubulle> svenl: logical as the low manpower we have was focused on beta2
18:17 < otavio> svenl: looks like beta3 is the last release that kinda of change could enter, no?
18:17 < svenl> bubulle: yeah, i know.
18:17 < fjp> svenl: The ignored part is nonsense.
18:17 < svenl> waldi: what would be needed libd-i/anna wise
18:17 < svenl> ?
18:18 < svenl> fjp: well, nobody replied to my post on d-b, i guess nobody ignored the issue, but nobody commented.
18:18 < fjp> I thought there were voices that said to make an exception for the installer for non free firmware, at least for Etch?
18:18 < fjp> svenl: There was a long thread about this in Jan.
18:18 < svenl> fjp: yeah, some mentioned making exceptions, but this means a 3:1 GR to pass.
18:18 < bubulle> speaking for myself, I just didn't comment mostly because it was not a priority for me...i guess that's the same for others...
18:18 < waldi> svenl: libd-i: support reading of more than on packages file, anna: allow selection of the components, ftp.d.o: experimental udeb section
18:18 < Stevie> GR?
18:19  * bubulle suggest we focus on technical stuff
18:19 < bubulle> we can't do political discussions right now...let's assume that something will have to be done
18:19 < waldi> bubulle: we can implement experimental support at the same time
18:19 < svenl> Stevie: we had a GR to ship non-free stuff in sarge only, if we want to prolong that for etch, we need to revote. I am not sure it will pass so we need a technical solution.
18:19 < bubulle> well, these proposals sound fair to me
18:20 < bubulle> (lib-di, anna and experimental udeb)
18:20 < Stevie> what is a GR?
18:20 < otavio> waldi: right. That would make new development easier to deal in future. Did you had any work done about it ?
18:20 < bubulle> Stevie: general Resolution...but not now please
18:20 < waldi> Stevie: read the constitution, general resolution
18:20 < Stevie> oh
18:20 < otavio> Stevie: General Resolution
18:20 < Stevie> lol, okay, thanks :)
18:20 < waldi> otavio: not in form of code
18:20 < svenl> waldi: we also need to be able to load not only non-free modules, but also have hotplug or whatever it is auto-load firmwares, and maybe trigger an anna auto-loading of the right firmware module.
18:21 < otavio> waldi: oh ok
18:21 < waldi> svenl: hrm, should be possible
18:21 < svenl> who is familiar with our udev implementation in d-i ? Kamion you there ?
18:21 < bubulle> svenl: a first step with non-free modules as target would be already a big progress, sin't it?
18:21 < Kamion> our udev implementation can load firmware, just dump it in /lib/firmware/ as usual
18:21 < Kamion> I only just arrived, catching up
18:21 < svenl> Kamion: right on time :)
18:22 < svenl> Kamion: can it trigger loading of additional .udebs ?
18:22 < fjp> joeyh has made the point that it is very hard to support loading of non-free modules for all installation methods, especially if these modules are required to access the archive or installation media
18:22 < waldi> svenl: no
18:22 < Kamion> I don't think that's a good idea
18:22 < Kamion> it happens far too asynchronously
18:22 < svenl> Kamion: why ?
18:22 < waldi> svenl: don't even think about such things
18:22 < Stevie> oh, this is #debian-boot, not #debian. Sorry, I'm getting my windows confused
18:22 < waldi> no locking in any way
18:22 < Kamion> that would cause additional udebs to be installed at utterly arbitrary times
18:22 < svenl> waldi: can the udev firmware process be made in two steps.
18:22 < svenl> ?
18:22 < Kamion> much better to control it
18:22 < waldi> svenl: yes
18:22 < Kamion> I also don't think it's particularly necessary
18:23  * fjp remembers some follow-up to http://lists.debian.org/debian-release/2006/01/msg00116.htm, but can't find it.
18:23 < Kamion> just include udebs for all the firmware we can think of and make d-i load everything it can find *shrug*
18:23 < svenl> waldi: once we get info from the driver it is needed, we download it and later get udev to install them or whatever ?
18:23 < Kamion> it's not as if there's all that much of it
18:23 < Kamion> udev will do it itself, you don't have to get it to do anything
18:23 < waldi> svenl: later, please
18:23 < svenl> Kamion: this doesn't solve the issue of folk providing their own home-made firmwares or whatever.
18:24 < bubulle> (moderator hat) not more than 7 minutes left
18:24 < bubulle> 6, actually
18:24 < svenl> fjp: about media, i think it is a false problem. We just build a set of non-free images, and maybe a non-free business-card or netinst.
18:24 < Stevie> before what?
18:24 < Kamion> svenl: they can dump it on a driver disk and we can come up with a way of loading it
18:24 < bubulle> Stevie: before we switch to another topic
18:24 < Stevie> oh, okay
18:24 < fjp> I would very much like to see a fully worked out implementation plan instead of these ad-hoc discussions.
18:24 < waldi> svenl: we have another topic left, the udes
18:25 < svenl> Kamion: problem, floppies are going away, and this doesn't solve the problem of pure net installs.
18:25 < svenl> waldi: the udebs ?
18:25 < bubulle> OK, let's slow down the discussion on that topic. 
18:25 < Kamion> I'm with fjp on this
18:25 < fjp> That plan could then be discussed openly.
18:25 < waldi> svenl: create udebs from linux-2.6 or not
18:25 < Stevie> well, I'm not all that knowledgable about this, but don't they only need proprietary firmware for etc. whatever network device they're using?
18:25 < bubulle> I ask all people who talked about this issue to give their current feeling about it in ONE sentence
18:26 < svenl> fjp: you want an implementation of non-free modules ?
18:26 < svenl> waldi: exact.
18:26 < svenl> let's conclude on the non-free module/firmware thingies.
18:26 < svenl> 1) we (waldi ?) will implement the needed anna/libd-i changes so more than one source is possible.
18:26 < otavio> I think I'm with fjp. We need to discuss it better before to go to implement any code for it
18:26 < bubulle> My conclusion: dedicated meeting after a plan has been presented by sven and/or waldi
18:27 < fjp> svenl: Extra images are bad for several reasons: release management complexity (testing), debian-cd mirror size, incomprehensible for users
18:27 < svenl> 2) we (the kernel team) will split out non-free modules into a non-free packages, or eventually non-free firmware only.
18:27  * Stevie thinks of a few ideas
18:27 < svenl> 3) once both are done, we come up with an test-case which shows how it works, and present it to the d-i team.
18:28 < Kamion> Stevie: sure, but we aren't going to create one d-i image per network card
18:28 < svenl> 4) we do all this in time for beta3, and everyone is happy, GR discussions about allowing non-free firmware into main becomes moot at that point :)
18:28 < bubulle> OK, then...svenl is in charge of writing this plan down and post it to -boot..:-)
18:28 < svenl> bubulle: euh.
18:28 < bubulle> and we conclude that topic
18:28 < fjp> 4) is completely irrealistic.
18:28 < svenl> bubulle: i thought you didn't want a plan but actiuon.
18:28 < svenl> fjp: bah.
18:28 < bubulle> fjp: This part will be lead by you, please
18:28 -!- bubulle changed the topic of #debian-boot to: Work about persistent devices naming (max 10mins)
18:29 < fjp> I have no real comments on this.
18:29 < svenl> fjp: don't be so negative about this, it is bad for motivating people to work on stuff if you start by telling them they do wrong things and it is unrealistic and so, reread the comments you have made here.
18:29 < otavio> uh!
18:29 < Kamion> svenl: I certainly don't want action before planning on a complex topic with several possible alternative implementations
18:29 < bubulle> fjp: ah....does someone have comment? I can't remember who proposed that topic
18:29 < svenl> Kamion: 18:24 < fjp> I would very much like to see a fully worked out implementation plan instead of these ad-hoc discussions.
18:30 < fjp> I just see more and more use cases for some kind of flexible reordering of menu items.
18:30 < svenl> Kamion: 18:24 < Kamion> I'm with fjp on this
18:30 < Kamion> persistent device naming can be handled (almost?) entirely in udev
18:30 < svenl> Kamion: you are kind of contradicting yourself.
18:30 < bubulle> svenl: we have moved to anoterh topic
18:30 < waldi> bye
18:30 < Kamion> Keybuk did some work in Ubuntu for iftab parsing, which makes it work provided that netcfg writes out /etc/iftab
18:30 < bubulle> waldi: thanks for attending
18:30 < fjp> Thanks waldi.
18:30 < Kamion> Md doesn't like that, so I doubt we'll see it in Debian
18:30 < Kamion> however Md has a plan to make some bit of udev write out rules itself to remember the name of each device it sees
18:31 < fjp> Ah. Sorry. I was at wrong subject.
18:31 < Kamion> and then all we need to do is copy those to /target in netcfg prebaseconfig
18:31 < Kamion> svenl: no I'm not
18:31 < svenl> Kamion: how does this plan influence the original naming of devices ?
18:31 < bubulle> The persistent device naming is a problem only for network devices, right?
18:31 < otavio> Kamion: udev side solution looks to be the right place to try to get it done
18:31 < svenl> Kamion: let's speak after the meeting about what is needed or not ?
18:32 < Kamion> svenl: udev picks one first time it sees the device, and then makes sure that it stays that way
18:32 < fjp> NICs is only half the problem though. We also need a solution for discs.
18:32 < svenl> bubulle: it may also cause problems for block devices, i think.
18:32 < Kamion> svenl: let's not
18:32 < otavio> bubulle: not always. usb-keys and others like cdrom could have problems too
18:33 < Kamion> NICs are the worst-affected case, although it's somewhat problematic for discs too
18:33 < bubulle> as I see, the solution would come from Md....or Kamion (because you seem to be the one understanding that stuff)...
18:33 < fjp> One case that is very bad is a USB stick coming out with sda and ths scsi disk controller with sda2+
18:33 < fjp> One case that is very bad is a USB stick coming out with sda and ths scsi disk controller with sdb+
18:33 < otavio> fjp: right
18:33 < bubulle> this seems to be time for better involving Md in d-i development, don't you think, guys?
18:34 < ninou> hi
18:34 < otavio> bubulle: hehe :-D sure
18:34 < Stevie> Hello, ninou
18:34 < fjp> Yes, I think a separate meeting with interested ppl would be a good idea.
18:34 < otavio> yes
18:34 < Kamion> fjp: we seem to have a bug at the moment in hw-detect - we load usb-storage before SCSI
18:34 < bubulle> who wants to organize it?
18:34 < Kamion> which causes USB disks to get named earlier than SCSI disks
18:35 < sc> bubulle: I think it will be hurd to involve Md
18:35 < fjp> I will.
18:35 < Kamion> fjp: that seems relatively easy to fix though, just needs some care and thought
18:35 < bubulle> sc: maybe but not a reason for not trying..:-)
18:35 < svenl> bubulle: /me not convinced about involving Md ...
18:35 < bubulle> OK, that seems to conclude the topic anyway
18:36 < fjp> We need Md for this and he's willing to cooperate.
18:36 < bubulle> fjp: This part will be lead by you, please
18:36 -!- bubulle changed the topic of #debian-boot to: Flexible way to reorder menu items (5mins, max 10 mins)
18:36 < fjp> Please see my earlier comments.
18:36 < fjp> Main thing here is that I do not see what the best way would be to implement it cleanly.
18:37 < fjp> Kamion: Do you have any ideas on how we could reorganize menu entries flexibly.
18:37 < fjp> For example based on a a "mode" set at noot time?
18:37 < Kamion> fjp: what's the driving force behind wanting this?
18:38 < fjp> reorganize would be excluding udebs and
18:38 < fjp> reordering
18:38 < bubulle> (note of some ppl: the use cases for this are described in the meeting agenda)
18:38 < bubulle> s/of/for
18:38 < Kamion> ah, one moment then
18:38 < fjp> Kamion: See use cases in http://wiki.debian.org/DebianInstaller/Meetings
18:38 < otavio> fjp: if we had a file that could be read like base-config menu files that could force a number for it?
18:38 < bubulle> http://wiki.debian.org/DebianInstaller/Meetings
18:39 < Kamion> I think I mentioned earlier that I reckon it'd be better to think about it in terms of being able to run things early, before the main menu starts up
18:39 < Kamion> so teach anna how to forcibly configure the network early, say
18:39 < Kamion> which may involve loading netcfg.udeb, which may involve configuring the CD, etc.
18:39 < Kamion> but it's doable
18:40 < bubulle> maybe joeyh has idea on this issue, also
18:40 < bubulle> ideas, even
18:40 < Kamion> for dropping menu items I think isinstallable is the right answer
18:41 < fjp> Kamion: And fall back to "normal" mode if anything fails?
18:41 < Kamion> it usually seems easiest to have the udeb itself decide whether or not it'll work
18:41 < fjp> Yes, I did not know about isinstallable when I wrote this.
18:41 < Kamion> fjp: well, display an error and fall back, yeah
18:41 < Kamion> I have an implementation of this that I used in the Ubuntu kickstart work
18:42 < Kamion> it's rather hacky and layer-violating, but it does at least work
18:42 < bubulle> it seems to me that Kamion is slowly taking responsibility for this..:-)
18:42 < fjp> If you're running before main-menu then displaying an error is not obvious.
18:42 < Kamion> fjp: you can still have a debconf frontend
18:42 < Kamion> even if it's a different one from the one that main-menu will eventually use
18:42 < fjp> Right. Not localized by definition though.
18:42 < Kamion> indeed
18:42 < bubulle> OK, only a few minutes left for that topic (1-2)
18:43 < bubulle> more?
18:43 < Kamion> bubulle: once I finally get around to committing kickseed, I'd certainly like to move some of its code to more appropriate places
18:43 < fjp> I will probably work on supporting Sarge installs again. Using isinstallable + an extra udeb should be enough.
18:44 < bubulle> Kamion: I suppose you won't have much time for such stuff in the upcoming weeks, do you?
18:44 < bubulle> (Ubuntu release and the like)
18:44 < Kamion> bubulle: I'll drop in kickseed at least; beyond that we'll see
18:44 < bubulle> OK, then, let's move
18:44 < bubulle> fjp: This part will be lead by you, please
18:44 -!- bubulle changed the topic of #debian-boot to: 2.6 based floppies? (max 5mins)
18:44 < bubulle> not sure whether this is fjp's baby
18:44 < svenl> well, powerpc already uses 2.6 floppies :)
18:45 < otavio> svenl: :-D
18:45 < fjp> I have no idea how to do this really.
18:45 < svenl> bubulle: i guess you mean 2.6 x86 floppies only there ?
18:45 < makx> is there demand for them?
18:45 < Kamion> makx: some
18:45 < bubulle> svenl: I suppose, yes, but I'm not the one proposing the topic
18:45 < svenl> makx: well, we want to kill 2.4 kernels in etch, so having 2.6 x86 floppies is a requisite for that.
18:45 < Kamion> though I'm told Smart Boot Manager is a workaround
18:45 < makx> than we need a special flavour
18:45 < fjp> I do know that current 2.4 boot floppy has run out of diskspace because of latest glibc, with no obvious way to reduce something.
18:45 < bubulle> we already have problems building floppies now....
18:45 < svenl> makx: i already do a special flavour on powerpc.
18:46 < makx> svenl: you have much less drivers there ;)
18:46 < bubulle> fjp: so I suppose that 2.6 floppies will have more space problems, then?
18:46 < svenl> BTW, would it be so difficult to have a 2 floppy configuration for x86 like we do on powerpc, we don't really need root on the same floppy as the kernel, don't we ?
18:46 < Kamion> it's a bigger kernel, yes
18:46 < svenl> makx: the drivers are in alternative root.img floppies.
18:46 < svenl> makx: and powerpc has bigger binaries.
18:47 < svenl> makx: what is the size of current i486 kernel flavour ?
18:47 < bubulle> the main problem is probably that we don't have many ppl that seem interested to work on this
18:47 < ninou> i succeed 2.6 but with load_ramdisk and prompt_ramdisk with root floppy using cramfs
18:48 < bubulle> ah, /me forgot ninou who is specialist for running DI on low-end configs..:-)
18:48 < bubulle> ninou: would you be interested in working on that 2.6 floppies issue? :-)
18:48 < fjp> jbailey once said that initramfs could help spreading things over multiple floppies, which looks like what ninou has been working on
18:48 < ninou> yes but it is not easy
18:48 < Stevie> might I interject briefly?
18:49 < fjp> Stevie: Just talk...
18:49 < bubulle> hmmm, time is running
18:49 < Stevie> I recently had to reinstall Debian on an IBM Thinkpad 240. The thing has no means to boot from anything but floppies
18:49 < makx> fjp: yes klibc got this feature as of request by tbm
18:49 < makx> although never tested it
18:49 < fjp> ninou: Can you commit what's needed in SVN in people? Or write a mail to the list with details?
18:49 < bubulle> Stevie: so, there's interest for floppies, but we already know this..:-)
18:50 < Stevie> ok then :)
18:50 < ninou> i try another solution by using klibc instead of busybox and glibc for boot floppy
18:50 < svenl> There seems to be not much interest to handle this, so let's go for the easy solution : the x86 kernels are around 1.1Mb big, which should leave plenty of space on the root.img floppy, we just put the whole root into a second floppy (or various of them) and it should work fine ?
18:50 < bubulle> and we move to next topic, which is ninou's baby
18:50 < bubulle> ninou: This part will be lead by you, please
18:50 -!- bubulle changed the topic of #debian-boot to: Sylvain Ferriol implementation of lowmem (max 5mins)
18:50 < bubulle> Sylvain==ninou...:)
18:50 < ninou> a solution for lowmem is not loading all udebs before partam but after partman-base
18:51 < bubulle> this is what you tried to implement but was reverted, am I right?
18:51 < ninou> yes
18:52 < bubulle> I think that post-beta2 could be a good place to try stuff about this. Do you agree, fjp?
18:52 < ninou> i try to implement some hooks before and after each menu configuration
18:52 < svenl> ninou: how does the fact that the Packages file gets loaded 3 times in memory influence low-mem situations ?
18:52 < Kamion> I wonder if it wouldn't be simpler to try to bring up swap much earlier
18:52 < Kamion> that's a relatively small piece to bring forward ...
18:52 < Kamion> but you still may need to load udebs in order to be able to get at the disk
18:52 < Kamion> so it can be sort of a catch-22
18:53 < Kamion> implementing whatever that cdebconf wishlist is that suggests mmaping the cdebconf databases would help too
18:53 < svenl> Kamion: how would you bring up swap before partitioning the disk ?
18:53 < fjp> The main thing about current lowmem handling is that it looks to me like a succession of hacks instead of proper integration into d-i.
18:53 < otavio> hehe
18:53 < Kamion> svenl: bring up any existing swap that happens to be on the disk (partman does this)
18:54 < Kamion> although of course a user can do this by hand
18:54 < ninou> for example loading clock-setup, base-installer, grub-installer lilo-installer, nobootloader, prebaseconfig after partman-base configuration
18:54 < otavio> svenl: but you need to know the disc and this mean to load the udebs of modules for it ...
18:54 < fjp> I can see a good case for loading some udebs only after partman. But I think we should implement that structurally rather than using hacks just for lowmem.
18:54 < Kamion> ninou: I'm a bit concerned about that
18:54 < Kamion> ninou: some of those udebs install partman sanity-check hooks
18:54 < ninou> it avoids peaks of memeory
18:54 < otavio> fjp: i think I agree with you. Do it by default in all d-i not just for lowmem case.
18:55 < Kamion> assuming that they can harmlessly be installed later is unfortunately not really accurate
18:55 < bubulle> hmm, we run out of time for this, again (sorry I made this short topics)
18:55 < svenl> Kamion: ok, would this swap be unloaded then when you repartition the disk (and possibly remove the swap) ?
18:55 < Kamion> there are some where it's ok, but not the bootloader installers - and I think those udebs are mostly pretty small anyway
18:55 < bubulle> ninou: I think that summarizing your ideas in -boot and trigger a discussion in the list is the best to do
18:56 < Kamion> so not sure whether it would actually be worth it. partman includes a great deal of stuff all by itself, I think surely the vast majority
18:56 < ninou> ok
18:56 < Kamion> svenl: yes, see the code
18:56 < bubulle> zinosat: This part will be lead by you, please
18:56 -!- bubulle changed the topic of #debian-boot to: g-i integration (max 15mins)
18:56 < bubulle> Not sure that zinost is here
18:56 < zinosat> here I am
18:56 < bubulle> OK...
18:56 < otavio> :-)
18:56 < svenl> Kamion: the least i see partman code the better :)
18:56 < zinosat> well, as for integration I think fjp has the magic formula
18:57 < zinosat> my spare time lately was all used for fonts
18:57 < otavio> nice ... :-D
18:57 < fjp> I have one thing on this. I have delayed the work on udeb lib dependency because of the release, but will now pick that up again and try to fasttrack it.
18:58 < bubulle> what are the missing items, then?
18:58 < fjp> Actually, bubulle is delaying g-i work because of the linespacing problems in freefont...
18:58 < zinosat> I wothe on d-boot what I think should be done http://lists.debian.org/debian-boot/2006/03/msg00073.html
18:58 < bubulle> yep, that linespacing problem is puzzling
18:58 < zinosat> I'd push on creating the two udebs mentioned on the message
18:58 < bubulle> unfortunately, upstreram freefont does not seem to advance on the topic
18:59 < fjp> zinosat: I'm not going to to a g-i release with beta2.
18:59 < zinosat> ttf-farsiweb (containing nazli.ttf and nazlib.ttf)
18:59 < bubulle> for farsiweb, that's easy, I'm the sponsor (or adn is)
18:59 < zinosat> fjp, no problem
18:59 < bubulle> no I am...adn is not DD
18:59 < svenl> zinosat: hey, you didn't mention the g-i games in that message :)
18:59 < bubulle> for dejavu, IIRC, I filed a BR
18:59 < zinosat> svenl, I spoke about the things that I think are vital for g-i: i.e not the games
19:00 < svenl> zinosat: :)
19:00 < bubulle> zinosat: until the line spacing problem is fixed in freefont, could we switch to dejavu?
19:00 < zinosat> we need dejavu anyway
19:00 < fjp> Only if dejavu has the same support for all scripts that are currently pushing for support in freefont.
19:00 < bubulle> several ppl told me that DejaVu are "nicer" and "better hinted" than freefont anyway
19:00 < zinosat> dejavu and farsiweb are needed both now and after that pb is fixed, so I'd start with thoise
19:01 < zinosat> the problem is that we have to test everything again
19:01 < svenl> zinosat: i am working on the fusion modules, would they be needed for something else than games ?
19:01 < bubulle> my fear is that the line spacing stuff remains unsolved for weeks. I can't do much to help upstream
19:01 < bubulle> I even tried upstream CVS but the problem is still here
19:01 < svenl> zinosat: sam hocevar also has the sdl .udebs ready or maybe even already uploaded.
19:02 < zinosat> bubulle, true. if we have most udebs there, we can use the BTS more
19:02 < zinosat> svenl, cool
19:02 < fjp> zinosat: How well does dejavue support greek, hebrew, arabic, indic scripts?
19:02 < zinosat> fjp, no idea
19:02  * joeyh arrives late
19:02 < otavio> joeyh: hello :-)
19:02 < zinosat> I could take a couple of days next week to run some tests
19:02 < bubulle> zinosat: hmm, for dejavu we *have* a udeb...or, at least, the bug requesting it is closed..:-)
19:03 < bubulle> #346563
19:03 < fjp> I'm not really going to consider dejavue untill we know more about that.
19:03 < zinosat> let's do this: next week I run some general tests with dejavu
19:03 < zinosat> just to have a feel of how well they work
19:03 < bubulle> yep, the udeb is even in testing
19:04 < bubulle> is something else needed for freefont?
19:04 < zinosat> it's just that I think we were this close >< to have 99% coverage
19:04 < zinosat> bubulle, don't think so.
19:04 < zinosat> anyway I think that at least it'll be much faster now that we have some experience
19:05 < bubulle> anything else on g-i? (except being a target for beta3, which is pretty short)
19:05 < zinosat> don't think so
19:05 < zinosat> I hope covering more languages we'll have more ppl interested in helping
19:06 < bubulle> fjp: for freefont, the deal is either have a less complete font without line spacing problem (20051102-2)
19:06 < bubulle> of a complete one with the problem (20060126-1)
19:06 < bubulle> let's move on anyway
19:06 < bubulle> [-oskar-]: Go for introduction please
19:06 -!- bubulle changed the topic of #debian-boot to: Graphical partitionner (Xavier Oswald work) (max 15mins)
19:06 < [-oskar-]> hmm ok
19:07 < bubulle> [-oskar-]: still here?
19:07 < [-oskar-]> So, I'm reimplementing gparted in C and call it gdisktool.
19:07 < [-oskar-]> You can find a first screenshot here : http://oskar-box.hd.free.fr/debian/screenshots/gdisktool.jpg
19:07 < [-oskar-]> It's in a early state of developpement. I'm finishing the hardware detection and hope to start soon ext3 and swap support.
19:07 < [-oskar-]> I don't know if this tool will be ready for etch but I will do my best to have it working ASAP.
19:07 < [-oskar-]> It will be used at the beginning to do manual partitionning and why not in the future manage lvm and raid.
19:07 < [-oskar-]> That's the idea and my goal.
19:08 < bubulle> if the work available somewhere (/me would suggest D-I SVN in people/)?
19:08 < svenl> [-oskar-]: do you think you could have a tentative udeb ready for the beta3 timeframe ?
19:09 < svenl> bubulle: its in the parted svn i believe.
19:09 < bubulle> sounds logical, yes..:)
19:09 < [-oskar-]> svenl, bubulle i will put it in the parted svn begin of next week
19:09 < [-oskar-]> svenl, ok, I can do a udeb and try it
19:09 < bubulle> fjp: what is your RM feeling about this?
19:10 < fjp> My feeling is that implementing it in g-i is post-Etch.
19:10 < svenl> [-oskar-]: i believe it is important that we have something present in beta3, so it can be tested, and eventually disabled.
19:10 < fjp> That does not mean of course that ppl can not build images using it before then.
19:10 < [-oskar-]> fjp, right, I need to test it a lot !
19:10 < bubulle> fjp: what about having it as an alternative partitioning tool (priority: optional)?
19:11 < svenl> fjp: notice that we would have had it ready for beta2 if c++ .udebs would have been allowed.
19:11 < otavio> [-oskar-]: we could move it for parted development svn and you might receive more help there too
19:11 < fjp> I think we should not even discuss that before it has been shown to work for basic functionality.
19:11 < otavio> [-oskar-]: there's also related projects there. So if you wish we might manage it for you to move to there.
19:11 < fjp> svenl: Yeah, yeah, yeah.
19:11 < svenl> fjp: :)
19:12 < [-oskar-]> otavio, suggestion ?
19:12 < svenl> fjp: seriously, we lost maybe 3-4 month of development about this.
19:12 < otavio> [-oskar-]: move the code to svn parted.
19:12 < bubulle> svenl: we can't rewrite history, you know...let's focus on the future..:)
19:12 < otavio> [-oskar-]: http://alioth.debian.org/projects/parted/
19:12 < [-oskar-]> otavio, as I say before, i will do that beginning of the next week
19:12 < otavio> [-oskar-]: ah ok
19:13 < [-oskar-]> otavio, :)
19:13 < svenl> another point, which is relative to this.
19:13 < bubulle> sounds fait by me...target being a basic working udeb allowing the build of alternate images
19:13 < bubulle> s/fait/fair
19:13 < svenl> It will probably not happen in the etch timeframe anymore, but i want to mention this.
19:14 < svenl> the graphical partitioner tool plan included at the start a partimage-client functionality, which would allow to backup partitions to disk or network.
19:15 < bubulle> yep, we talked about this with [-oskar-] at SL2006 and I think it may be an interesting feature to have
19:15 < zinosat> svenl, just realized I did not answer about fusion usage for other than games: I think it's needed if you want a WM and other things, but I don't know much about it.
19:15 < svenl> i also heard many be interested in this topic at the extremadura meeting.
19:15 < bubulle> [-oskar-]: I suggest you also make some noise around this to trigger more interested people
19:15 < [-oskar-]> bubulle, good idea !
19:15 < bubulle> and maybe Ubuntu has some interest for this, too (hint hint)
19:16 < bubulle> let's move to the last topic
19:16 < bubulle> bubulle: This part will be lead by you, please
19:16 < bubulle> -------+(Jed 0.99.16) Emacs: topic    (Text)  38/38   7:15pm------------------------------------------------------
19:16 < bubulle> oops
19:16 -!- bubulle changed the topic of #debian-boot to: Netinst image needing network (max 15mins)
19:16 < joeyh> heh
19:16 < Kamion> right now Ubuntu's more interested in installation from live CD (although still based on d-i)
19:16 < svenl> bubulle: the main problem is that it is less motivating to get people to basically work a perfectly working tool and reimplement it in C.
19:16 < bubulle> well, this issue is kinda annoying as we already talked on the list
19:16 < Kamion> svenl: gparted is far from perfectly working, as I know to my cost
19:16 < svenl> bubulle: it also means there will be more burden in the further maintenance of it later on.
19:17 < Kamion> and it's very difficult to hack on because gtkmm is so hideously painful
19:17 < svenl> Kamion: /me is speaking about partimage here, not gparted.
19:17 < bubulle> ahem, topic has changed..:)
19:17 < bubulle> joeyh: do you have comments on that netinst image issue?
19:17 < Kamion> bubulle: I think the right answer is to make choose-mirror notice that it's installing from CD and not mind if the network isn't available
19:17 < joeyh> I think it should be easy to make the network/mirror steps skippble if they arn't already
19:18 < joeyh> I'm also in favour of dropping the netinst though, probably
19:18 < bubulle> I am not..:-)
19:18 < Kamion> I did a really hacky fix for Ubuntu's choose-mirror
19:18 < Kamion> but it wouldn't work for Debian netinsts because it assumes codename == suite
19:18 < bubulle> we had users advices about it to be useful, mine included
19:19 < Kamion> that should be relatively straightforward to fix though - it already pokes about in /cdrom/
19:19 < fjp> bubulle: In that case we would need something again that can be run post-reboot to do missing stuff.
19:19 < Kamion> I checked for /cdrom/.disk/base_installable and made network failures soft failures if it exists
19:19 < Kamion> does that sound right?
19:19 < bubulle> fjp: what missing stuff?
19:19 < joeyh> yeah, sounds like it'd work.
19:20 < Kamion> I don't recall if the apt-setup side Just Worked after that, but if it didn't it was a trivial fix
19:20 < Kamion> ok, I'll merge that then
19:20 < Kamion> oh, hmm
19:20 < Kamion> I recall noting to myself that it would be easier if netcfg made a note somewhere of what it had done
19:20 < bubulle> well, then we have some plans to fix this....sounds fine
19:20 < Kamion> because I had to poke about in netcfg's internal debconf state at one point
19:21 < Kamion> I can't find it right now but I'll dig it out
19:21 < bubulle> People, we are a bit late in the schedule, so I hereby propose closing the official meeting
19:21 < fjp> bubulle: Missing is package selection and maybe apt-setup.
19:22 < bubulle> fjp: yes...but the system is still usable..:-)...anyway...
19:22 < bubulle> Thanks you to all people who attended. This was a very interesting meeting, though a bit long