Log from the Debian Installer team meeting of July 25th 2007, 19:00UTC ---------------------------------------------------------------------- People who speak below: anibal : Aníbal Monsalve Salazar aurel32 : Aurélien Jarno bubulle : Christian Perrier elmig : Miguel Figueiredo faw : Felipe Augusto van de Wiel fjp : Frans Pop joeyh : Joey Hess Lunar^ : Jérémy Bobbio nyu : Robert Millan otavio : Otavio Salvador p2-mate : Peter De Schrijver waldi : Bastian Blank zinoviev : Anton Zinoviev Nicknames mentioned during the meeting though these people were not attending: cjwatson : Colin Watson 19:01 * Lunar^ has changed the topic to: D-I meeting 19:01 Usual meetings advices apply: please try to focus on what's going on 19:02 open another text editor to prepare your statements and copy/paste when it's the appropriate time 19:02 The agenda is pretty dense 19:02 So I'd like to know how long people can stay, first 19:02 (I have no deadline myself) 19:02 2 hours 19:02 2 hours 19:02 * joeyh has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination 19:02 same 19:02 ok 19:03 Hope people ordered the agenda correctly 19:03 Let's take items in the order, and we'll see how far we'll go :) 19:03 goo 19:03 good 19:04 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Adding udebs to the archive: what do we want to allow? (fjp) 19:04 fjp: I'll let you introduce that 19:04 One item is listed double: rdate is same as NTP and clock stuff 19:04 right 19:04 People seem to underestimate the impact that adding udebs without any kind of coordination has. 19:05 For a D-I RM it really is an awful lot of work if you suddenly see udebs appear. 19:05 hasn't this been sorted out now? 19:05 I've tried to explain some of that in the recent mails. 19:06 Well, there is now an agreement with FTP-masters that no new udebs will be accepted without checking with d-boot first. 19:06 seems to have worked pretty well in the case of rdate 19:06 Yes, agreed. 19:06 i hope it will work in future 19:06 fjp: that's good and I suggest that we put something on developpers-reference doc too 19:06 it would be nice if the udeb were downloadable at that point too, the ftpmaster summary is not enough really 19:07 Maybe at some point in the future this can be relaxed a bit. 19:07 maybe need to have an "official" statement of who is qualified to say "yes|no"? 19:07 joeyh: If we have doubts we can always contact the maintainer for uploaded version. 19:07 consensus of the team seems good enough to me, RM override 19:07 bubulle: Yes, I think we need to put this on a wiki. 19:07 bubulle: until we have a RM it's a bit difficult to define 19:07 joeyh: agree 19:08 joeyh: define "team". :-) 19:08 Currently, there is only one section for udebs, which is debian-installer. In the long term, we could imagine an official "d-i-contrib" (or whatever) section in the archive could be helpful to people that want to enable new stuff to create the udeb they want (and that the d-i team itself doesn't have to worry about), or is that a bad i 19:08 Sure, but there needs to be a consensus _before_ a random member of the team replies to ftp masters 19:08 dea? 19:08 or other d-i sections for derivstives 19:08 Lunar^: You'd need a pretty strong use-case for FTP masters to want to add and support that. 19:08 cant we use the priority of the packages instead of a new section? Say d-i ignores extra priority. 19:08 Lunar^: it's a good idea, but needs libd-i mods to be really useful 19:09 fjp: gnu-fdisk-udeb would have fitted there IMHO 19:09 the archive side of that is a subcase of having separate sections in the archive for general staging areas, transitions, etc, an idea that has been discussed before 19:10 oh, and udebs to experimental are fine, no need for d-i review there 19:10 zinoviev: We use extra ourselves too and there is even a rough plan to make use of distinction between optional and extra in anna. 19:10 joeyh: I disagree 19:10 joeyh: Except that those could migrate to unstable without further check... 19:11 good point 19:11 joeyh: if the udeb is approved to experimental, it will be accepted by dak on next upload on sid 19:11 ok, it is a workaround, you're right 19:11 Anyway, let's not discuss solutions too much now. happy to see there is support for the FTP master agreement. 19:12 Next question is: do we want to allow gnu-fdisk udeb. 19:12 ? 19:12 fjp: I personally like to have it available 19:12 what does it provide? 19:12 If you've seen the discussion, I'm against as the use-case is already covered by parted-udeb 19:12 waldi: a replacement to fdisk using libparted 19:12 superior to the old fdisk? 19:12 GPT support 19:13 well, why do we need both fdisk-udeb and gnu-fdisk-udeb? 19:13 what does fdisk-udeb provide that the other lacks? 19:13 gnu-fdisk is really, really new. Not even in stable. 19:13 joeyh: stability 19:13 we can just reeeeeeeeeemove fdisk-udeb 19:13 joeyh: well, fdisk is more widly used by now and then I won't like to have it as a full replacement now 19:13 And depends on libparted, so much heavier for early inclusion. 19:14 so far fdisk-udeb is only used manually, so I don't see stability being a big deal. 19:14 Size is an issue. 19:14 why is a fdisk command present in first place? 19:14 But if gnu-fdisk-udeb isn't available anywhere, will gnu-fdisk gets more tests in the future? 19:14 joeyh: I'm aware of some cases where libparted has problems where fdisk doesn't has 19:15 Note that we _do_ use cfdisk in scripts. 19:15 your reasoning (there's already parted) seems to exclude that 19:15 joeyh: the XP partition overlap is one example 19:15 ah 19:15 fjp: where? 19:15 lilo-installer to set boot flag 19:15 ugh 19:15 But it's run in /target, right? 19:15 Nope 19:15 fjp: it could be done using a simple code for libparted, no? 19:16 oh, blah 19:16 does it need to do that? partman already sets it 19:16 otavio: Since when is anything involving libparted simple? ;-) 19:16 isn't a middle ground possible? i.e. providing gnu-fdisk-udeb but not replacing anything 19:16 fjp: hehe 19:16 * otavio hide 19:17 Anyway, I've still not seen any convincing arguments why we do need gnu-fdisk. 19:18 fjp: I'd like to keep it to later, in future, be able to remove fdisk 19:18 otavio: Sure, but let's add it later then too. As (former) RM we really don't need the overhead. 19:18 fjp: would be good to have a light tool that could be used to provide debugging information in future (not parted_server and neither parted-udeb) 19:18 Especially not for something that is relatively experimental. 19:19 fjp: since it's not being used, it won't hurt too much to leave it there 19:19 It takes space on CDs and costs effort from RM. 19:19 fjp: it's not experimental. It just isn't proved to be too stable yet 19:19 I'm concerned about GPT use case rather than just debugging/etc 19:19 I suggest we move to the next point, there seems to be not much oppositions to fjp's arguments 19:19 fjp: from CD, we can blacklist it 19:19 That's hurting enough for me. 19:20 note that stability is not as much of an issue as if it were doing the low-level stuff on its own. remember it relies on libparted 19:20 otavio: If you're going to agree to blacklist it, you don't need it in the first place. 19:20 Lunar^: yep, move 19:20 Summary: 19:20 nyu: gpt could be covered by parted-udeb in this case. 19:20 * Agreement with ftpmasters than no udeb will enter without prior auth is settled. -> Good 19:20 * It would be good to have ways to support udebs not endorsed by the d-i team. gnu-fdisk-udeb would fit there. 19:20 * gnu-fdisk is too young to be considered as a replacement for d-i right now. 19:20 * lilo-installer should not need to set partitions active, investigate 19:21 If we move on, I'm going to ask the udeb is dropped. 19:21 noted 19:21 Lunar^: I thought we were discussing wether it can stay in the archive, not wether it can replace fdisk :-) 19:21 Next point is: Status for a [WWW] Lenny beta1 release and release management (fjp) 19:21 fjp: but it's available on netboot and easy to get in if need. 19:21 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny beta1 release and release management (fjp) 19:21 fjp: Please :) 19:22 otavio: First convince people of the added value. *I* have not seen any convincing arguments. 19:22 OK. 19:22 fjp: well, looks like just you complain about it 19:22 otavio: move on :) 19:22 I've sent a few updates about status. Last one about an hour ago. 19:22 These really are going to be my last efforts 19:22 fjp: gpt.. 19:23 nyu: wrong point 19:23 So far I've basically just continued, but I'm now ready to have my DD account removed. 19:23 So, we need a new RM... 19:23 * joeyh drops a pin 19:23 Last thing I plan to do is send a "bits from D-I team" tomorrow or so. 19:24 D-I is (again) in reasonably good shape now. But there are still a few issues that need to be taken care of before a release is possible. 19:24 I wonder if any of the several people I hope are thinking "do I really want to do this..?" would be more inclined to do it if there were a small team 19:25 as with the debian RMs 19:25 this was more or less what I was thinking 19:25 And we probably need to separate all the tasks fjp fullfiled from what RM really is about 19:25 i can help as usual but -kernel is enough to do 19:26 IIRC, before fjp took over, joeyh did all the previous d-i releases, right? 19:26 um, mithandir may have done a beta release or 2, I forget 19:27 And pere? 19:27 even if not the best, the small team thing seems to be the only solution left anyway 19:27 pere also 19:27 bubulle: We need people knowing how to do it in this small team, though :) 19:27 Lunar^: yep, that means joeyh..:-) 19:27 The only problem I see with that idea is that you _really_ need to keep a good overview of what's happening. And that will always take time. 19:28 yeah 19:28 even though cjwatson hasn't done it (in Debian), he knows pretty much everything 19:28 fjp: yep 19:28 joeyh: is that still (remembering from debconf) okay with you? 19:28 Lunar^: you mean being in such a team? 19:28 joeyh: yep 19:28 I have limited time, I am not sure 19:28 probably like most other people 19:28 cjwatson is pretty busy as well, as far as I have seen 19:29 and he's not here right now... 19:29 if I were in it it would probably be in a more advisory/teaching position 19:29 Forget Colin for RM... 19:30 so, joeyh could train someone? 19:30 I see something like a Lunar^|joeyh lead tandem with some of us as strong backups to help in the areas we have knowledge of (that could include fjp) 19:30 sure, I've done it before.. 19:30 I think 3 people would be much better than 2 19:30 ok, how about joeyh trains Lunar^ ? 19:30 especially since as I've said, my role would be limited at best 19:31 bubulle: I don't know if I can spend enough time ; and I will be offline for weeks during next year 19:31 but I'm willing to learn, for sure 19:32 frankly, I really do not see any other solution 19:32 I'd really like to find someone else... 19:33 all this anyway enforces the feeling that we really need to avoid disruptive changes unless we want to be the ones delaying lenny 19:33 usualy the kernel is the problem 19:34 I offer help on it too 19:34 otavio: I'd be delighted to work with you as well :) 19:34 Lunar^: :-) 19:34 otavio: "on it" being kernel or core D-I RM team? 19:35 bubulle: can be both. I usually follow the two team closely. I'm more involved on d-i, right now. 19:35 In any case, I'd like to get a better view of what the job is about first... In a month or two I will probably be able to say if it fits my life or if it would be better for the project to find someone else 19:36 hmm, Lunar+otavio, trained and backed up by joeyh, then? 19:36 (a month or two working with joeyh and fjp to gather the knowledge) 19:36 can we go on? 19:36 I'll help too of course, in the background. 19:36 fjp: that would be great 19:37 fjp: imho, having you as the one saying "*this* is likely to be disruptive" when proposals are made would be good 19:37 bubulle: indeed 19:37 fjp: you're very good to find gabs on proposals and like and it does help a lot :-) 19:37 I suggest we move on staying on that, and have regular point during next meetings about how it goes 19:37 Well, a large part of what I've been doing is quality checking and _loads_ of testing an tracing of issues. 19:38 * sepski (~sep@217.17.211.51) has joined #debian-boot 19:38 that's not specifically an RM job ;- 19:38 ) 19:38 before we move on, I of course confirm that I'll keep my i18n hat in the D-I team 19:38 bubulle: :-D 19:38 Summary: 19:39 No, but it does give you a good feel if you're ready for a release and it also helps improve the quality of a release when you do one. 19:39 * otavio and Lunar works with joeyh to acquire the needed knowledge about d-i RM 19:39 Lunar^: and fjp 19:39 * fjp will still be there to give advices 19:39 it's more a matter of someone having to do it, so if it's not done, the RM is stuck with it 19:39 s/joeyh/fjp and joeyh/ in that order 19:39 ok 19:40 * bubulle keeps going with i18n stuff :) 19:40 next point is closely related: Installation report processing and answering mails to d-boot in general (fjp) 19:40 joeyh: Right. And that in practice goes with _a lot_ of things. I've been happy to do it, which maybe does not help. 19:40 maybe mention in the report who keeps maintaining the install manual? 19:40 bubulle: good point 19:41 Rm for the manual is being transferred to faw. 19:41 * faw is now taking care of d-i manual 19:41 faw: wave please :P 19:41 I also plan to keep working on it though. 19:41 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Installation report processing and answering mails to d-boot in general (fjp) 19:42 I sometimes try to not answer reports for a bit to see if anyone else will, but I'm mostly disappointed... 19:42 t 19:42 * bubulle often sorry to be less and less able to answer install reports 19:42 (sorry, that was a typo) 19:43 stapper does some, but IMO his "help" is more noise than real help. 19:43 IMO dealing with issues is part of being on the team... 19:43 I've been wondering for a while if installation reports are a bit of a relic. Targeted bug reports are much better, and there's typically only one bug per person now anyway 19:43 compared with the old installation reports where you reported on which 10% was _working_ 19:44 Yes, we seem to be getting less anyway. 19:44 and mor einstall report that are related to anything but d-i, especially when we're close to releases 19:44 most of the failures I have seen where related to unsupported hardware, also 19:44 yeah, we got something under 10 for the etch release, AFIACR 19:45 (by the kernel, which is not something we can really do about it) 19:45 that's one in .. two thousand? 19:45 joeyh: couldn't we make a kind of wizzard to report this? If the user choose the place where he has problems we can do very good guesses about where the problem is really happening 19:45 We still need a general pseudo package though as we can't expect users to identify components. 19:45 (to 20 thousand, depending on your opinon of how many use popcon) 19:45 So, we need a much more general template? 19:45 otavio: so like have main-menu detect when a step fails and file a bug? 19:45 fjp: or maybe a small application? 19:46 joeyh: maybe 19:46 we could already stop encouraging to report successful install, maybe? 19:46 uh... I don't wan't to get an installation-report for every network failure :) 19:46 joeyh: or offer a step to report a bug and asking what was the last step. 19:46 the very few successful ones are still somewhat useful, just to remind you that people do succeed.. they're also often very easy to skim and close 19:46 joeyh: if he has not problems on boot, ... but had on boot-loader, then it's a grub-installer or lilo-installer problem, most of time 19:47 joeyh: as an example 19:47 * fjp agrees with Lunar^: automated reporting may lead to flooding... 19:47 Well, I personally need to stop telling myself that somebody else is going to do it :) 19:47 well, you can usertag it up and stuff, and of course, if netcfg or anna *dies* due to a network problem, that is a bug.. 19:48 Answering reports and tracing issues really gets you a good feel for D-I as a whole. 19:48 Another option about this issue will be scheduled time to work on reports, coordinated on IRC 19:48 Lunar^: Installation Repports Squashing Party? :P 19:49 * fjp doubts he'd want to commit to that 19:49 * joeyh neither 19:49 can only handle them in small batches 19:49 it could be scheduled when we've just lost track for too many of them 19:49 we've been thousands behind for years.. 19:49 ok 19:49 while I don't think people without knownledge on d-i can help too much we could do it online and coordinate it online too. 19:49 Lunar^: Like the current 2000 :-) 19:50 didn't we plan to close all install reports from versions before etch? 19:50 of the etch RCs 19:50 so d-i team people could try to work on them together at some time 19:50 s/of/or 19:50 It would already help a lot if people just started on reports and asked for help on issues on IRC. 19:50 yes 19:51 I'd have no problem with helping identify issues, as long as the other D-I person would take responsibility for following up. 19:51 Currently I just often find that I have way too many running conversations and lots of issues get dropped half way through because of that. 19:51 Which really sucks. 19:52 that brings a kind of topic of (re)identifying whoc currently thinks (s)he's still active in d-i right now 19:52 I suggest we all try to make an effort to answer more installation reports and move to the next point (and see if we did commit to that during the next meeting) 19:52 going back to otavio's idea, I wonder if a non-bug based data gatherer wouod be more useful. If anytime d-i failed it dumped data to a server somewhere, and you could see that base-installer is failing for 25% of people today, that would be quite nice 19:52 what about closing old reports? 19:52 Lunar^: ack 19:52 bubulle: I'll do that. 19:52 all before the RCs? 19:52 (though I'v ebeen promising for over a year or so...) 19:53 reports from sarge and etch betas are almost useless now (or too much work to get something useful from them) 19:53 fjp: need help on that? 19:54 so close all install reports sent before Nov 1st 2006, then 19:54 joeyh: Sensitive subject... Gathering random data from random people in a central place. 19:54 otavio: I'll keep you in mind/ 19:54 We have 1:05 minutes left 19:54 of course you ask first, but most people will say yes 19:54 I will need help once I start closing and people reply! 19:54 true 19:54 Let's move on' 19:55 Summary: * Let's make a collective effort to answer more installation reports. * fjp closes reports sent before Etch release candidates. There will be the need for help with replies. * Let's also think about alternative to installation reports. 19:55 fjp: ppl don't reply when you close old bugs (personal experience) 19:55 bubulle: If you close 100, 5-10 will 19:55 Next point is: Lenny development -> dhcp-client replacement (fjp) 19:55 Short. 19:56 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny development -> dhcp-client replacement (fjp) 19:56 We've switched to dhcp3 now, but would really like something smaller. 19:56 Anybody wants to work on that is _very_ welcome. 19:56 busybox udhcp 19:56 I'd be willing to help people test something else, but don't plan to drive it on my own 19:56 but we killed it some time ago 19:56 Lenny goals page lists alternatives. 19:56 There's alternatives listed on the wiki, we need someone to commit to test the different possibilities 19:56 I think I know the use cases pretty well, though 19:56 waldi: does it miss too much features? 19:57 waldi: killed from package or upstream side? 19:57 waldi: Are you willing to check if busybox dhcp suits d-i needs? 19:57 We really need someone to concentrate on that, and maybe give netcfg some love too. 19:57 yes 19:57 joeyh: could you make write a wiki page with the use cases for we use as guidance? 19:57 waldi: maks said klibc has something too. 19:58 fjp: do we have klibc per default? 19:58 we have busybox 19:58 waldi: we don't bug maks said it does work with libc 19:58 No, but he said it could be compiled against libc too. 19:58 s/bug/but 19:58 i need to cleanup busybox anyway and will take a look into it 19:59 Let's move on and talks about it once waldi will have checked out busybox dhcp 19:59 waldi: busybox alternative is active from upstream side? (the udhcp)? 19:59 yes 19:59 Summary: 19:59 * switch to dhcp3 done, but too big 19:59 waldi: nice 20:00 * alternatives on the wiki 20:00 * joeyh is willing to help people test something 20:00 * waldi checks busybox dhcp and we'll see the results 20:00 Next point is connected to our first point :) Lenny devel: multiple udeb sources (fjp) 20:00 not much to say, i'm working on libd-i support 20:01 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny development -> multiple udeb sources (fjp) 20:01 Yes, that was after I added it to the agenda :-) 20:01 (and really want c++, without stl, for that ...) 20:01 which udebs have multiple sources? 20:01 main, non-free 20:01 s-p-o 20:01 What more is needed after libc is fixed? 20:01 libc? 20:02 anibal: It's not about that. It's about _using_ udebs from multiple sources. 20:02 Will there be anymore change to make once libd-i will support it? 20:02 ok 20:02 yes, anna, manin-menu 20:02 s/libc/libdi/ 20:02 (maybe finaly udpkg ...) 20:02 waldi: it's going to be API and ABI incompatible, right? 20:02 yes 20:03 Let's move on 20:03 Summary: 20:03 And we need some support to select or at least preseed multiple sources. 20:03 * waldi is working on supporting it in libd-i 20:03 fjp: it looks to be more a anna issue 20:03 fjp: no? 20:03 anna and main-menu and probably udpkg will need to be changed once libd-i will be ok 20:04 (missing a star) 20:04 Next point: devfs removal; cleaning up code or not? (fjp) 20:04 otavio: You don't specify which sources you want to use in anna... 20:04 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny development -> devfs removal; cleaning up code or not? (fjp) 20:04 Is there any reason to keep support for devfs style device names? 20:05 code cleanup ... 20:05 no 20:05 it will not come back 20:05 cleanup! 20:05 :-) 20:05 I vaguely remember Colin saying that some other kernels may use it? 20:05 I agree for Linux... 20:05 I made a list of files to clean on the wiki during DebConf 20:05 bsd don't do that, aurel32 can you confirm it? 20:05 I might have overlooked some of them, but it still is a good start if anyone wants to clean that up 20:06 * fjp will do some of the cleaning 20:06 freebsd has a devfs, but I dont know what paths it uses 20:06 different 20:06 * bubulle rang aurel32 also on -fr, just in case..:) 20:06 Support for kFreeBSD is a different issue IMHO 20:07 Lunar^: yes 20:07 Do we want to consider that ATM, or just clean and have those ports be responsible for adding back what's needed? 20:07 clean 20:07 Lunar^: and I also think it's not be considered right now for d-i global decisions 20:07 fjp: clean 20:07 * dennis has quit (Ping timeout: 480 seconds) 20:07 let's clean :) 20:07 fjp: if need, we can change it later 20:07 joeyh: ? 20:07 having a list of places you need to modify is useful at least 20:08 make a list during cleaning :) 20:08 Let's move on 20:08 Summary: 20:09 * Let's clean up! 20:09 Let's at least agree to mark such cleaning clearly in commit messages! 20:09 * There is a preliminary list of files to clean on the wiki. 20:09 fjp: Please make a proposal :) 20:09 fjp: like: [devfs removal] description? 20:09 Note that we should still wait for new udev before starting. Upload expected real soon. 20:10 fjp: there's any radical change on it? 20:10 otavio: Yes, for example. And no mixing with other changes. 20:10 Disabling devfs compat rules :-) 20:10 fjp: ah, on udeb part 20:10 fjp: got it 20:11 ok 20:11 * We need to wait for the new udev before starting. Upload expected real soon. 20:11 * Let's mark commit messages cleary with "[devfs removal]" and no mix with other changes. 20:11 * fjp will be doing some of the work. 20:11 * Supporting kFreeBSD is a different issue and will add back what it needs later. 20:11 Next point: Lenny development -> NTP and clock stuff (joeyh) 20:12 You skip one 20:12 persistent device naming? 20:12 uhhh... sorry 20:12 Next point: Lenny development -> persistent device naming (fjp) 20:12 Another subject where we really need someone to take the lead... 20:12 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny development -> persistent device naming (fjp) 20:12 waldi: What are kernel-team plans for IDE-PATA switch? 20:12 the kernel will rewrite fstab with some of the next releases 20:13 hopefully .23 20:13 wow 20:13 including the pata switch 20:13 Can we also use that in D-I to get UUID in fstab? 20:13 not uuid 20:13 (or whatever) 20:13 What then? 20:14 not yet decided. s390 will use disk/by-path 20:15 I've not seen any discussion on this. Did I miss something? 20:15 by-id looks okay for normal use 20:15 there was some on d-b 20:15 with vorlon 20:15 Do we need to wait on kernel support to progress on that issue? 20:16 no 20:16 but d-i and the kernel should use the same schema 20:16 It would be good to use the same approach though. 20:16 indeed 20:16 * waldi .o0( /dev/disk/by-path/ip-192.168.9.13:3260-iscsi-iqn.2007-07.org.zseries.debian00:storage.org.zseries.debian04v1-lun-1 ... ) 20:17 wow! 20:17 gosh! 20:17 One thing is that someone needs to work out what to do with removable devices and such and implications for replacing hardware and such. 20:18 * fjp still hates the idea of having way to long strings like that in his /etc/fstab... 20:18 s/to/too/ 20:18 fjp: agreed 20:18 I'd be happy to have a pointer about all this to put on the report 20:18 * sepski has quit (Remote host closed the connection) 20:18 I still wonder if upstream kernel cannot come up with something better. 20:18 this is udev 20:18 and what other distros are doing? 20:19 ubuntu uses uuid 20:19 ubuntu is using by-uuid AFAIK 20:19 no UUID= 20:19 right but others? 20:19 there's no other distro handling this issue? 20:19 no idea 20:19 We need someone to dig that out 20:20 imho, this should be the first step 20:20 do other distros support USB installers at all? 20:20 Another subject where we really need someone to take the lead... 20:20 :-) 20:20 so we know what others are doing 20:20 Let's move on. 20:20 No one stepping up 20:20 fjp: yes 20:20 Summary: 20:20 * We need someone to take the lead on that issue. 20:20 * How other distros are doing it? Let's start by finding that out. 20:20 * Kernel .23 will include the IDE-PATA switch and will rewrite fstab. We don't need to wait on kernel to make progress but we should use the same approach. 20:21 wait 20:21 sorry, boss was calling. Yes, I'm taking care of d-i manual ;) 20:21 * faw waves 20:21 this doesn't concern other distros if they don't provide USB installers 20:21 afaict 20:21 nyu: no, the problem is not usb specific 20:21 or at least, not as much as us 20:22 [OT] faw: a new build would be good; should be almost all languages :-) 20:22 Next point is: Lenny development -> NTP and clock stuff (joeyh) 20:22 with usb, it kills the install (usb becomes /dev/sda, then goes away) 20:22 fjp, will start another one later tonight 20:22 D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny development -> NTP and clock stuff (joeyh) 20:22 Little to say here, I implemented the basics of using rdate for ntp in d-i, and it seems to work. 20:22 Needs testing, especially real-world testing, non-i386 (alpha?), and nslu2 testing. 20:22 There are some fancy extra things that could be done that I didn't implement, like guessing timezones. 20:22 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny development -> NTP and clock stuff (joeyh) 20:23 Thanks to anibal for quick response on reported issues. 20:23 yes 20:23 * aurel32 reads the backlog 20:23 Though I guess the paches made it easy :-) 20:23 anibal: Anything to add? 20:23 aurel32: bsd devfs format, basically 20:23 Did someone pinged tbm about nslu2? 20:24 otavio: that's very simple 20:24 maybe the udp support need to be extended as well to ntp 20:24 just do a mount devfs /dev -t devfs 20:24 and that's all 20:24 Lunar^: not yet, he's away from his 20:24 I guess the main thing is for everybody to stay alert for issues re clock setting so we can get the code mature. 20:24 aurel32: good 20:25 it also needs testing on a factory-fresh one 20:25 you can even mount it multiple time 20:25 like in a chroot for example 20:25 aurel32: Please read backlog for context. It's not so simple :-) 20:25 Let's stay with current topic. 20:25 we probably can move on even 20:25 aurel32: Maybe we should discuss it later with otavio :) 20:25 aurel32: we revisit it after meeting 20:25 bubulle: I agree 20:25 Summary: 20:25 * joeyh did the work. 20:25 * Need more testing on non-i386 and nslu2. Let's stay alert on such issues to get the code moture. 20:26 Next point is: Dropping support for sparc32; cleaning up code or not? (fjp) 20:26 clean 20:26 Are there some remote chances this cone will be useful in future? 20:26 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Lenny development -> Dropping support for sparc32; cleaning up code or not? (fjp) 20:26 s/cone/code 20:26 ok 20:26 for sparc32, libc6 does not support sparc32 anymore 20:26 Yes, libc is already getting changed to optimize for sparc64, so I think there's really no way back. 20:27 I vote for cleaning too. 20:27 Do we need to define a clean tag like we did for devfs? 20:27 no 20:27 No, it's much less pervasive. 20:27 I'll take care of this one. 20:27 great 20:27 Let's move on 20:28 Summary: 20:28 * kernel dropped sparc32, glibc as well so no turning back. 20:28 * fjp will do the cleaning. 20:28 It's good to do it before a Beta1 as that makes coordinating D-I and debian-cd changes easier. 20:28 Next point: Future of g-i (lunar) 20:28 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Future of g-i (lunar) 20:29 So, I submited a huge bunch of code at once :) 20:29 Attilio said that he will continue his background maintainance on g-i if we switch to the new code 20:30 Lunar^: that's great. 20:30 as he have less time now to take care of it, and he doesn't feel like learning all the new codebase to continue the maintainance 20:30 shouldn't we switch to g-i as default as soon as possible? 20:30 bubulle: I'll come to that later 20:31 But he's willing to continue to share his current knowledge, work on part of it and scratch the remaining itches in g-i deps 20:31 * fjp would like to see new code cleaned for functional equivalence with current g-i and then merged ASAP, including plug-in support 20:31 Lunar^: looks like you've fixed all regressions that were pointed out, right? 20:31 otavio: I did, fjp confirmed they were 20:32 Lunar^: what's missing? 20:32 bubulle: You are for "Yes/No" buttons, if I remember well 20:32 I've not done a 100% test yet though. 20:32 more than radio buttons, yes 20:32 otavio: A clear consensus on which experiments should become mainstream 20:32 Lunar^: I like the Yes/No buttons if they go nearer of the question 20:32 Lunar^: not as it's in the last screenshot I saw 20:32 * fjp and attilio are against 20:32 * fjp acks otavio 20:33 radio buttons do not go very well with the interrogative form of boolean templates short descriptions 20:33 Lunar^: Let's keep functional changes separate from codebase change. 20:33 fjp: ac 20:33 fjp: I agree 20:34 Lunar^: so would be great if you could revert to radio buttons and make it virtually igual of current code to allow us to merge it asap 20:34 Lunar^: can you do that? 20:34 If that was not clear enough, I will take care of maintaining the new codebase, at the very least until its stable and tested 20:34 And screenshot button. 20:34 fjp: right 20:34 * otavio hates the screenshot button 20:34 * fjp does not :-) 20:34 I will try to get a side-by-side functionally equivalent code 20:34 Great. 20:34 * otavio would like to have a debconf preseeding to hide them 20:35 and then we'll discuss other stuff later 20:35 Lunar^: then, after the merging we can go and improve it 20:35 There's an issue left about the fe_gtk namespace, though :D 20:35 Lunar^: what's the problem? 20:35 I will send more emails with specific questions along the way 20:36 there's one or two minor things like this, but we should probably move on 20:36 Lunar^: so it'll be dealt on the ml 20:36 ? 20:36 yes 20:36 My personal goal would be to make g-i the default on i386, powerpc and amd64 20:36 ugh 20:37 But not before a real graphical partitioner 20:37 or support for some kind of columns 20:37 * fjp is not against but sees plenty of issues that need to be addressed before he'd consider it ready for that 20:38 Let's discuss that when more people will feel it "ready" :) 20:38 Lunar^: I think it's too early to decide it. I'd rather wait until beta1 to see how it goes 20:38 gtk changed a bit 20:38 Let's move on/ 20:38 we also should try to get dfb updated asap 20:39 so we can detect regressions asap too 20:39 20 minutes left 20:39 right 20:40 I will make the summary later :) 20:40 Next point: Status of lowmem and recent cdebconf improvements (lunar) 20:40 * fjp moves to skip this for next meeting 20:40 yep 20:40 Well, actually I'd like to do this point before the end: 20:40 Finding new contributors (lunar) 20:41 If that's ok with everyone 20:41 ok with me 20:41 So what's next new point? 20:41 * Lunar^ has changed the topic to: D-I meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination | Finding new contributors (lunar) 20:41 zinoviev: are you here? I'd like to hear your bit even if it goes over.. 20:42 We need documentation with specific instructions for new d-i developers. Since I've never tested partman in real environment I naver learned how to test partman. The last days it took me a whole week to firure this out. Imagine what it would take for a complete newcommer to firure out how to test the simplest udeb. 20:42 For example it needs to be documented that from all targets only the one making mini.iso is useful, also how to make a pkg-list where only udebs you need are installed, or how to update the version of udebs in the installer without restart of the emulator, how to use snapshots in qemu. 20:42 * bubulle brings again the "let's ping who currently considers self member of the d-i team" topic 20:42 zinoviev: http://d-i.alioth.debian.org/doc/talks/debconf6/paper/ 20:42 I read this... 20:43 Some of your points could be added there. 20:43 We need to make the start of the new developers easy. A simple howto with steps first do this, then this, and so on 20:43 Turning your paper into a maintained "d-i developers reference" would be great 20:44 Yes. That has been the plan all along. I never really found time myself to expand it though. 20:45 bubulle: this might be interesting to you: http://www.ohloh.net/projects/6853/analyses/latest/contributors?page=1 20:45 I think we are still not completely unsuccessful in attracting new people. 20:45 fjp: wouldn't it be easier if it has been move to devel/doc/? 20:45 During last DebConf, I was there for the debian-women meeting and attendees where trying to find new stuff for d-w. One of my proposal was to make an announce on the d-w list that d-i was seeking new contributors and that it could also goes with an online tutorial on how to hack d-i. 20:45 fjp: on svn of d-i, of course 20:46 * fjp thinks bubulle should be disqualified from that... 20:46 Lunar^: An offer from me to mentor for d-i work has been on d-w website for ages :-/ 20:47 I was encouraged to do so. If people agrees with such idea, I'd like some help to work on such announcement. :) 20:47 * dennis has quit (Ping timeout: 480 seconds) 20:47 Very large, active development team 20:47 Mature, well-established codebase 20:47 :-) 20:48 Lunar^: Let's include it in the bit's from d-i too. I'll let you see the draft. 20:48 Yes 20:48 Project Cost $4,216,564 20:48 Would anyone also like help to make an online tutorial? 20:48 heh :) 20:49 seems a bit cheap 20:49 fjp: slocount? 20:49 I think many people will help if it is in a wiki. (me too) 20:49 it must be in the billions range 20:49 zinoviev: talking about d-i-devref? 20:49 yes 20:50 it need not to be realesed formaly as the usual devref 20:51 Should we go on on that topic or is there anyone that would really like to talk about another point of the agenda during the last 10 minutes? 20:51 I wanted to hear zinoviev on partman 20:51 but could stay after 20:51 powerpc port should be discussed 20:51 * bubulle has to go 20:51 I can write an email after 10 minutes if you want to discuss other things. 20:51 * dennis (~dennis@200.32.236.20) has joined #debian-boot 20:51 And I'd like a poll on Rename "Serial ATA RAID" to "ATA RAID" 20:51 zinoviev: great 20:51 I got an efica board here and can help on some ppc work 20:51 fjp: do it on a user site? 20:52 otavio: you too? cool :-) 20:52 nyu: :-) 20:52 joeyh: I agree, would be better to get user feedback on that 20:52 [OT] otavio: you should really test my patch for grub-installer on powerpc then ;-) 20:52 nyu: sven has worked out to get one sent to me :-) 20:52 we should have some people doing ps3 stuff for powerpc porting. Its a great platform for it 20:52 otavio: Personally I'd much rather see some progress on all the libparted issues we have open :-) 20:52 joeyh: is that openfirmware? 20:52 I wonder if we could get debian to buy some ps3s for developers? :-) 20:53 nyu: it has its own bootloader, that is built-in, so you just make a CD< iirc 20:53 the port exists, but is not merged 20:53 joeyh: new toys for developers? 20:53 waldi: needs kernel support merged... ;-) 20:53 too expensive IMHO. besides, part of it goes to funding DRM infrastructure :-/ 20:53 hmm, there was something 20:54 fjp: yes. It's on the first item on the TODO list 20:54 fjp: I'll probably push it to experimental on the end of this week 20:54 perhaps we could convince Sony to donate some ;P 20:54 fjp: and then we should managed to get it tested again and see what need to be solved before pushing it to sid 20:55 nyu: indeed 20:55 nyu, or get discounted prices for developers 20:55 otavio: Not just s/390, but also the other BRs tagged d-i. Though s/390 and new version has prio obviously. 20:55 fjp: yes 20:56 otavio: Good. I'll test when available in experimental of course. Just announce on the list. 20:56 fjp: yes, thanks by your help :-) 20:56 can i make a comment? 20:56 elmig: please do 20:56 just a sugestion, i believe throwed to the air before. Release notes not like a manual but announcement of software inside the release: the news are, kernel a.b.c, Gnome X, KDE Y, OO.o n, ... you get the picture 20:56 elmig: No! 20:56 well, it's the last free for all 4 minutes 20:57 * fjp is joking of course. 20:57 hehe 20:57 elmig: So, what's the point? 20:57 RN seems like a 'bible' 20:57 any comments about grub-installer on powerpc ? 20:57 I will be making a summary - if someone could send me the full IRC log, that would be great 20:58 * fjp thinks that's up to new RMs... 20:58 nyu: I glanced over your patch, seemed pretty intrusive for an experimental feature 20:58 nyu: Could you make an .iso out of it and ask for more testing on debian-powerpc? 20:58 joeyh: can you be more specific? some parts (e.g. s/grub2/grub-foo/g) were necessary as cleanup (also for -efi and whatever) 20:58 Lunar^, I'm logging at work, I'll email you my log in about 3 to 4 hours :) 20:59 Lunar^: sure 20:59 anibal: thanks 20:59 I should read it again I guess, it just looked suprisingly large 21:00 fjp, imho some parts like upgrading kernels and so on belong in the manual. RNs should be to advertise whats new on the 'product' 21:00 actually, without considering grub-of, s/grub2/grub-pc/g would be needed. otherwise flip-flopping during the install won't work 21:00 (this happens since grub2 became a dummy package) 21:00 wrt win32-loader integration, I assume you want to wait untill it's in sid to discuss it? 21:01 nyu: probably better, yes :) 21:02 gotta run 21:02 joeyh: uhm looking at the patch again, I notice that this and some other things already make sense in the current code. perhaps I should split 21:02 yes, time's up 21:02 Thanks to everyone :) 21:02 * Lunar^ has changed the topic to: http://www.debian.org/devel/debian-installer | If nobody answers, try debian-boot@lists.debian.org | status of today's builds: http://wiki.debian.org/DebianInstaller/Today 21:02 Hope my facilitation was helpful :) 21:03 elmig: The Debian release notes don't really have anything to do with D-I. 21:03 Lunar^: thanks for the work. That d(i meeting was much easier for me..:-) 21:03 elmig: And also, it's not just a release announcement (that's the mail), but also upgrade instructions for 12 architectures. 21:03 bubulle: Are you willing to ping previous d-i contributors to see if they are still interested? 21:04 my point it's those upgrade instructions (imho) belong on the manual 21:05 elmig: IMO not. They are much too changable. 21:05 Lunar^: yes, but I'll be able to do it only after my holidays....or maybe on Friday which is the last free day I have 21:05 bubulle: I don't feel any hurry, but that would be helpful, for sure :) 21:05 Of the previous release notes I'd guess that >>60% was rewritten. 21:06 elmig: In my experience, most huge piece of software that I know do it the way Debian does 21:06 actually "members d-i" should give the correct list on alioth, then it's just a matter of automating a mail. Even me could do it, I think 21:06 Lunar^, thank you for organising and co-ordinating this meeting 21:06 bubulle: I was thinking on having a look at all debian/changelog