Log from the Debian Installer meeting of August 29th 2007, 20:00 UTC -------------------------------------------------------------------- People who speak below: bubulle : Christian Perrier dannf : Dann Frazier fjp : Frans Pop joeyh : Joey Hess Lunar^ : Jérémy Bobbio nyu : Robert Millan otavio : Otavio Salvador panthera : Daniel Baumann sc : Stefano Canepa waldi : Bastian Blank Yoe : Wouter Verhelst Nicknames mentioned during the meeting though these people were not attending: cjwatson : Colin Watson ths : Thierry Steve Hurst 20:00 * Lunar^ changed the topic to: Meeting in progress - http://wiki.debian.org/DebianInstaller/Meetings/Coordination 20:00 bubulle: be welcome 20:00 I have just one request for the meeting: could new RMs please act on http://lists.debian.org/debian-boot/2007/08/msg00218.html 20:01 fjp: That is partially covered already 20:01 fjp: we can see what's missing on it. 20:02 As no one else stepped up to facilitate the meeting 20:02 AFAICT nothing has been done after the stable update. At least the Etch D-I page has not been updated. 20:02 fjp: (covered by the agenda, I meant) 20:04 fjp: yes, stable and oldstable still need to be done 20:04 fjp: rest looks mostly OK 20:04 I am going to facilitate this one... I would much appreciate if others could do it as well 20:04 Let's start. 20:04 Usual online meeting recomendations: 20:04 * Turn off your email agents, instant messagers, or similar stuff. 20:04 * Focus what is said on the channel, try not to pay attention to what happens 20:04 in other window of your IRC client. 20:04 * "Listen" to what other have to "say". Keep in mind that we do not 20:04 necessarily all have a good network connection or a fast typing. Let's keep 20:04 the meeting moving and dynamic, but not messy. 20:05 First point is about d-i beta1 release 20:05 Well, for d-i beta1 we're more or less in good shape but we do have some serious blockers 20:06 What are those? 20:06 The most serious one, in my POV is the compilation problems due kernel compatibility types 20:06 usually, Frans was listing them on a wiki page. Could be done maybe? 20:07 bubulle: good. note taken :-) 20:07 what is that problem? 20:07 joeyh: kbd-chooser issue that has been workarounded 20:07 and we're not in sync with all arches due this 20:07 #434040 -> last action Fri, 03 Aug 2007 20:07 joeyh: <20070823200844.GB26641@wavehammer.waldi.eu.org> on -glibc 20:08 and -kernel 20:08 we cannot start moving some modules to testing due this 20:08 no, we're not in sync on all arches due to a broken sparc buildd that does not have base packages installed 20:08 sparc is a mess 20:08 joeyh: libdebian-installer had problems too 20:09 and an ampd64 buildd that seems absurdly slow 20:09 I can eventually use my own sparc to do binary uploads in arder to speed the process, if that's really needed 20:09 couldn't these be built and uploaded manually by someone? 20:09 Lunar^: it is not affected by the kernel problem? 20:09 waldi: It's using etch + pbuilder, atm 20:09 waldi: I worked around the kernel problem by explcitly including the header file 20:10 * dannf has a sparc i can use for manual builds as well - a pretty fast one 20:10 joeyh: yes. It's a workaround but it's ugly ... :( 20:10 shrug, it's one line of C 20:10 Lunar^: will not help 20:10 someone should mail the sparc buildd maintainer 20:10 waldi: do you have any hope when it'll get fixed? 20:10 Lunar^: the bug is in the kernel since at least .18 and is exposed by the sid glibc 20:11 otavio: the cause is still unknown and upstream did not help 20:11 waldi: :( 20:11 waldi: do you suggests we start to do workarounds for it? 20:11 we can't workaround it 20:11 um 20:12 waldi: #include ? 20:12 hello.. tap tap 20:12 otavio: other problem 20:12 There's two things being discussed here... libdebian-installer and sparc 20:12 Can we workaround the issue in libdebian-installer the same way joeyh did in kbd-setup? 20:12 help to fix the problem 20:13 Lunar^: shouldn't be a problem, I think 20:13 waldi: What do you mean? 20:13 mips and mipsel are also in bad state. I've talked with the maintainer of them and he's working on it 20:13 ahem, do we at least have a solution for kbd-chooser? The discussion slipped to libd-i a biit too early..:) 20:14 bubulle: yes. kbd-chooser has been workarounded at 1.37 IIRC 20:14 Lunar^: it is a usual problem that i try to discuss solutions with large impact but noone wants to answer 20:14 waldi: and what other distros has been doing about it? Have you checked it? 20:14 waldi: No one from kernel or glibc teams - or in d-i? 20:15 Lunar^: vorlon did 20:15 otavio: worked around but not built on sparc and amd64 if I read correctly 20:15 bubulle: yes 20:15 it wasn't on amd64 this afternoon 20:15 otavio: really problematic workarounds 20:16 waldi: yes 20:16 waldi: ack 20:16 waldi: I don't like it, too :( 20:16 every single d-i beta release has had problimatic workarounds for issues in unstable 20:16 that's why we've been able to have d-i beta releases 20:17 I agree. If there is no sign of progress on the issue in close sight, I suggest to just work around it so we can move d-i forward. 20:17 Well, I think that is better we start to workaround it where it's need 20:17 so.....who builds kbd-chooser on missing arches? :-) 20:17 But would be nice to tag them properly so we can remove the workarounds when the bug gets fixed 20:18 nyu: can you build it for amd64? 20:18 btw, current libd-i svn builds fine on amd64 here, so it doesn't seem to trigger the libc bug 20:18 joeyh: cool :-) 20:19 Well, m68k has a size issue on floppy 20:19 joeyh: amd64 is not affected by the bug 20:19 it was for kbd-chooser 20:19 (m68k floppy size issue) I don't know who is the best person to ask about it. 20:19 okay, not always. some lowlevel arch headers includes feature.h 20:20 md6k is not a release architecuture, is it? 20:20 waldi: Do you have any pointer that would sum up the situation about sparc, I'd like to have a clear picture of the situation 20:20 Still not AFAIK, I say that we can do the release with the issue 20:21 We can still email debian-m68k asking for help on the issue 20:21 Lunar^: yes, I think that if we start to work around them we can do 20:21 #433187 20:21 otavio: sure, which package, kbd-chooser? 20:21 As I said, mips and mipsel are being worked on by ths 20:21 waldi: thanks 20:21 nyu: yes. 20:22 Lunar^: i think about dropping sparc support from the kernel because it is unmaintained 20:22 otavio: he was on VAC IIRC, let's ping him in a week 20:22 Lunar^: I've done it. He said he's going to work at it next week 20:22 otavio: great 20:23 Well next thing about beta1 is kernel. 20:23 bubulle: do you see #425835 as a blocker for beta1? (CJK regressions in the newt frontend) 20:23 Does someone has any problem about moving to 2.6.22? 20:23 Lunar^: no 20:23 there is an abi bump pending 20:23 when will 2.6.22 reach testing? 20:23 waldi: when do you plan to upload it? 20:24 wow this is 5 days old. are amd64 buildds lagging behind? sounds strange 20:24 joeyh: We need to have the same kernel version in testing than the one we use for d-i, correct? 20:24 joeyh: after d-i updates its kernel packages 20:24 waldi: we also have some problems with linux-modules-2.6 and linux-modules-extra-2.6 that would be worked out to get it in shape, no? 20:25 otavio: yep 20:25 waldi: and are those issues solved already on svn? 20:25 dunno 20:25 waldi: and when do you plan to upload 2.6.22 for the abi bump? 20:27 Basically, I was going to suggest we wait kernel team to do the upload for the ABI bump and if there's not serious blocker we move to 2.6.22 asap. 20:27 Someone has any problem with this move? 20:28 Are you willing to coordinate this? 20:29 frankly, I'm not sure what to make of comments like: 20:29 joeyh: after d-i updates its kernel packages 20:29 how is d-i supposed to know that the kernel team has apparently been waiting for a month for us to update to the new packages? 20:29 I can do it. No problem. Just wants to know if there's any complain about it 20:30 joeyh: communication is a issue that need to be improved indeed. :( 20:30 I suggest that we spend max 10 more minutes on beta1 and then move to the next point. 20:30 joeyh: but there're other issues for kernel to move. l-m-*-2.6 are not in sync 20:31 .oO(l-m-e-2.6 waits for unionfs2 which i'm uploading tomorrow) 20:31 otavio: 3 people doing the work on the kernel is simply not enough 20:31 waldi: well, we can try to help but even for it we need to know what we need to work with 20:32 * Lunar^ still don't get it 20:32 Lunar^: what you've not get? 20:32 Is a new kernel upload required before we can upload d-i's kernel packages and release? 20:33 otavio: kbd-chooser_1.37_amd64.changes uploaded 20:33 Do we need to wait for 2.6.22 to migrate? 20:33 nyu: tnkx 20:33 Lunar^: no. the migration will happen with the d-i testing update 20:33 Lunar^: Well, not a requirement but .21 is a know to have some serious problems. 20:34 Lunar^: I wouldn't like to release with .21 20:34 Lunar^: people on -br-cdd has exposed a lot of boot problems with .21 that has been solved with .22 20:34 great 20:34 Lunar^: they use d-i there too 20:35 So: 1. kernel team uploads a new kernel - 2. massbuild and upload of d-i kernel udebs - 3. everything moves to testing at the same time 20:35 Is that right? 20:35 yes 20:35 Thanks :) 20:36 waldi: what's missing for kernel new upload? 20:36 waldi: that's critical to us 20:36 the linux/types.h patch 20:37 waldi: you've it ready, no? 20:37 not completely 20:37 waldi: ah 20:37 waldi: any expected timeline? 20:37 hopefully tomorrow 20:37 * otavio things beta1 is done 20:38 should i upload kbd-chooser_1.37_sparc? 20:38 dannf: please do! 20:38 waldi: good news 20:38 Ok, let's sum up 20:38 vorlon will hate me 20:38 Blockers: 20:38 * Issue with libdebian-installer (see #434040) 20:38 -> going to be worked around by explicitely including the header like 20:38 joeyh did for kbd-chooser 20:38 * sparc is broken - bug in kernel since .18 exposed by the libc in sid. 20:38 see #433187 20:38 -> someone needs to mail sparc buildd maintainers 20:38 Who steps up for that? 20:39 * #425835 is not a blocker for beta1. 20:39 * kernel issues 20:39 There is an abi bump pending. We wait kernel team to do the upload for the 20:39 ABI bump and if there's not serious blocker we move to 2.6.22 ASAP. 20:39 Otavio will be coordinating the move. 20:40 Any comments? 20:40 That's good for me :-) 20:40 no 20:41 next topic? 20:41 I suggest that we skip the next 3 points: Status of lowmem and recent cdebconf improvements, make d-i support nfsroot systems, need an option of memtest86+ on the install CD 20:41 as neither anibal nor colin are here 20:41 Lunar^: ack 20:42 Lunar^: postpone it for next meeting again 20:42 Ok, let's move on 20:42 Lunar^: if noone objects 20:42 Next point is: backporting fix for next Etch point release 20:42 There was quite a lot of useful fixes done on cdebconf during the past months. 20:42 Some of these fixes removed huge memory leaks, and should probably be 20:42 backported for the next Etch point release. It is due in 4-6 weeks, so this 20:42 sounds like a realistic timeframe. 20:43 hmmm, is that really acceptable? 20:43 Lunar^: are you willing to handle this? 20:43 bubulle: acceptable? 20:43 Note that the RC issue was fixed in _debconf_, not cdebconf. See my mail. 20:43 what do the SRM think about this? 20:44 fjp: damn... I completely overlooked that 20:44 Lunar^: "useful fixes"....I'm not sure this qualifies something for being included in a stable release update 20:45 otavio: smarenka is the m68k d-i guy 20:45 Yoe: ah, thanks! :-) 20:45 bubulle: well... d-i crashing because of lack of memory or deadlock sounds like "useful" 20:45 bubulle: there're two or three things that I think that fits on the RC rule 20:46 Lunar^: those things can be easily backported? 20:46 I am willing to coordinate this. I will make an inventory of the changes that could be backported and see with zobel what would be acceptable. 20:46 Lunar^: great. 20:46 otavio: In cdebconf, I believe so... AFAIK, there was no huge change in the core since etch. 20:46 but that would need to be ACKed by Colin 20:46 Lunar^: I'd suggest to *first* check with zobel if that would be acceptable..:) 20:47 Lunar^: I think it also the same for debconf 20:47 bubulle: it's difficult to discuss it without check how intrusive would be the changes 20:47 bubulle: I need to know what to ask first! :) 20:49 * bubulle is just playing the ultra-conservative role, don't worry....:) 20:49 Lunar^: do you want to comment something else on this specific topic? Looks like we need to check what would be candidate for backporting and ask SRM about them 20:49 yes 20:49 I'll work on it 20:49 Let's move on... 20:50 Summary: 20:51 * A deadlock issue was fixed in _debconf_ and needs to be backported. 20:51 See http://lists.debian.org/debian-boot/2007/08/msg00218.html for a summary 20:51 (and other things left to be done wrt. stable and oldstable releases) 20:51 * Memory issues in cdebconf as well. 20:51 * Lunar will be coordinating the effort: first step will be to make 20:51 an inventory of what could be backported, then see with zobel what is 20:51 acceptable. 20:51 Next point is: Integration of some work done by lunar during his VAC 20:52 "some work"? 20:52 well, I have subpoints :) 20:52 :-) 20:52 RTLD_GLOBAL and frontend plugins 20:52 Thanks to vorlon's help, I have been able to change the way frontend plugins 20:52 could use frontend functions to something that really feels a lot more 20:52 "natural" than using ackward dlsym() calls. I'd like to get some feedback 20:52 from Colin before integrating the changes, which has yet to arrived though. 20:53 And it can't be integrated before fixing the mklibs issue 20:53 do we have dependencies? this makes the behavior of a plugin subject of the loading order 20:53 waldi: What would do that? 20:54 waldi: frontend have a clear API in a clear namespace, plugins are written for a specific frontend and use this API 20:55 plugins themselves are not loaded with RTLD_GLOBAL 20:56 zzzzzz...:-) 20:56 About mklibs, I have sent a little description of what I have understood of the problem available here: http://lists.debian.org/debian-boot/2007/08/msg00557.html 20:56 The attached patch was just a workaround sent so others could test the other 20:56 patches I have sent along. A proper fix to mklibs or d-i build system would 20:56 need to be done, but I don't have any clue about where to start. 20:57 BTW, I find it quite rude to reply to messages with NACK. People are not TCP implementations. 20:58 Next stuff was about the tetris implementation 20:58 I got positive feedback already on this one, but no real answers to my 20:58 questions. What would be the best way to integrate such code to d-i? 20:58 ++++++ for the tetris implementation 20:59 leaving it to an option in the menu does not feel like the best way to integrate it to me, though 20:59 Lunar^: frankly, I personnally have no technical advice about these changes but if there's is a moment to do them, this is now 20:59 wonder if you could have a tetris tab an an installer tab? 21:00 joeyh: This is doable, but will have impact on memory 21:00 maybe only load the tetris code if the tab is opened? 21:00 Lunar^: we might use some boot param to enable it? 21:00 the code didn't look very big to me though.. 10k? 21:00 something like this, yes 21:01 Installed-Size: 64 21:01 for the cdebconf-gtk-tetris package 21:01 if any progress bar could show at the bottom of both tabs, that would be really nice 21:02 or something like that, I'm sure there are better UIs 21:02 I am probably going to do more research on what to do 21:02 I personally prefer we merge current work of cdebconf before start changing it again 21:02 should we try to ship the current udeb in beta1 (for the hype)? 21:02 yes 21:03 marketing, etc. 21:03 Lunar^: but beta1 would be good enough to have it as an item on menu. At least for now. 21:03 We have enough changes on cdebconf waiting for merging. Wouldn't be better to sync it before? 21:04 The patch series I have sent is what I feel ready for beta1 21:04 waldi: what's your idea about the mklibs issue spot by Lunar^ ? 21:05 otavio: feels like the issue reallly is in the build system after having another look 21:05 Lunar^: right. I think those are things we need to speed up to be able to get more testing on it 21:05 I will try to coordinate with Colin about the merge 21:05 * bubulle votes for Lunar^ changes to be included 21:06 I want him to have a last look before merging 21:06 I suggest we move on 21:06 (and thanks for your input) 21:06 * waldi provides bubulle the workaround-medal first class 21:07 Next point is: Current status of the switch to console-setup 21:07 Lunar^: but do you have any bet where at the building is the problem? 21:07 Lunar^: ah ok, we talk about it later 21:07 otavio: No, but I'll figure that out 21:07 bubulle: can you talk about c-s? 21:08 bubulle: Mind to give us a summary (your last mail which was like a roadmap was http://lists.debian.org/debian-boot/2007/08/msg00504.html) 21:08 ? 21:09 bubulle: could you get nekral (you named him your padawan) to work on it? 21:10 I had two other remarks on that topic, btw 21:11 Integrating Ubuntu's keyboard recognition plugin would be great. And we can also imagine cool plugins for the graphical installer where the actual 21:11 layout is shown on screen. Some code could probably be adapted from 21:11 gnome-keyboard-properties to do so. 21:12 ... 21:12 Lunar^: this will work only on g-i 21:13 sc: showing the layout? 21:13 Lunar^: adapting gnome-keyboard-properties 21:14 sc: yes, it would be only on g-i 21:14 sc: Yeah, sure. My idea was to do another plugin to enhance the graphical installer. 21:14 I don't feel that console-setup is going to be ready for beta1 21:14 Lunar^: ok 21:14 Lunar^: neither I 21:15 So I suggest we move on and see next month if there was any progresses 21:15 Lunar^: looks to have a lot of problems regarting to l10n 21:15 Next point is: have filesystems use the "relatime" option by default 21:16 fjp suggested that we integrate make relatime the default option for newly created partitions, see #426785. 21:16 My personal take on this issue: 21:16 As far as I have read in the LKML threads, it seems that kernel upstream will 21:16 probably add an option making relatime the default for all filesystems, so I 21:16 suggest we wait for that. 21:18 Any comments? Anyone wants to do anything about this? 21:19 sorry, folks, I've been distracted for some minutes 21:20 in short, yes, c-s is not ready for beta1 21:20 it works well, indeed, but is not i18n'ed at all which is, for me, a blocker 21:21 I've discussed it with Colin briefly and looks like the major blocker for it is to add at partman a proper way to set default options for each filysystem 21:21 So it's available as an option but not enabled by default. 21:21 Lunar^: how much does it costs for as to add relatime now and if it will be default in next kernel change again? 21:21 next? 21:21 it's too quiet 21:22 BSP? 21:22 Lunar^: otavio replied ;-) 21:22 ok :) 21:22 Next point: Bug Squashing Party? 21:22 I am organising a bug squashing party in Dijon during the last week-end of 21:22 september (29th-30th). If there is any interest, I would be happy to spend the 21:22 week-end fixing d-i bugs, coordinating on IRC. 21:23 Anyone interested in doing such thing? 21:23 I'm 21:23 Well, september 29th-30th is bad to me :( 21:24 I was mostly announcing that... we'll see who's going to be availably by then 21:24 Let's move on 21:24 Next point is: win32-loader integration 21:24 nyu: your turn :) 21:24 well, win32-loader is in the archive now (entered yesterday) 21:24 my current proposed patch (http://lists.debian.org/debian-boot/2007/08/msg00574.html) installs win32-loader support in cdrom and hd-media (and netboot mini.iso), without enabling it in autorun.inf or referencing it in any way. 21:25 nyu: congrats for making that happen 21:25 thanks :-) 21:25 the idea is that only users who know about it can use it for now 21:25 specialy since fjp expressed concerns about that 21:25 * otavio personally thinks it's OK for merging 21:25 me too 21:25 ok. any objection to the patch itself? 21:25 So you have another .exe on the CD which you can use to start the installer without messing with the BIOS, right? 21:26 nyu: not for me part 21:26 yep 21:26 I personnally disagreed with fjp's concerns about an autorun.inf but, well..... 21:26 as for enabling it in autorun.inf, chain-loading it from README.html or the like, do you want to discuss that now or better leave that for later? 21:26 would be good if fjp was present ;-) 21:26 bubulle: me too. But let's talk about it later after it's merged 21:26 I'll be happy to discuss it now, as we have some time left 21:26 fjp: ping 21:27 my primary concern is that it is available so that people can test it, etc 21:27 I'm not going to get involved in this. 21:27 nyu: I think that autorun might open a nice webpage and it be linked from it 21:27 the network version from http://goodbye-microsoft.com/ has been tested a lot, but not so for the CD one 21:27 otavio: that's a bit complicated (permission issue) 21:27 anyway, integrating first without the autorun.inf is good 21:27 HTML is sandboxed 21:28 I have encountered quite a few users that got a Debian installation CD and wondered: "Ok, what should I do next?" ; so I really feel that it would help to have an autorun personally. It could opening the documentatin and we could probably have a link starting win32-loader from there 21:28 but maybe we could write a win32 menu to select the HTML or the installer 21:28 nyu: that would be a nice improvement 21:28 another option that'd be simpler is adding a menu in win32-loader itself 21:28 that shellexecute()s the html 21:29 (equivalent to xdg-open) 21:29 and an extra warning, maybe 21:29 nyu: both are OK from my side 21:29 but that feels like a good solution 21:29 ok, so we leave it unreferenced for now and add the autorun.inf bits when it's capable of opening the HTML by itself? 21:29 nyu: shellexecute is not so bad solution 21:29 nyu: I'm ok with it 21:29 joeyh: ? 21:29 okie 21:30 nyu: ACK 21:30 btw, why not name the executable "setup.exe"? 21:30 bubulle: it's setup.exe once it's copied 21:30 ah, good.../me proves his ignorance about win32-loader...:) 21:30 maybe we could change the icon to a classical PC image. but I don't know any free ones 21:30 plus, the current swirl one is very pretty 21:31 * Lunar^ likes swirls 21:31 keep the swirl 21:31 and making it look nice on vista without causing regressions is quite a challenge 21:31 (any skilled gimpers around?) 21:32 nyu: You should probably ask debian-art 21:32 nyu: let's commit it then ... so it's going to show up at daily builds asap :-) 21:32 ok 21:32 Summary: 21:32 * ACK for the proposed patch: 21:32 http://lists.debian.org/debian-boot/2007/08/msg00574.html 21:32 * Once win32-loader will be able to open the documentation, we can add 21:32 an "autorun.inf" which will start it when the CD is inserted. 21:33 That was the last point on the agenda. 21:33 I think the meeting is over 21:33 I'll send a mail to debian-boot asking for suggestions regarding UI for the documentation opener 21:33 Before going free for all 21:33 Would Wednesday, Sep, 26th be a good day for the next meeting? 21:34 Lunar^: about the c-s topic, here is what I propose: 21:34 It's good to me, no problem 21:35 Lunar^: ok 21:35 bubulle: go ahead 21:35 debian-installer: rmh * r49074 installer/ (build/config/x86.cfg debian/changelog debian/control): * Integrate win32-loader utility. (Closes: #412922) 21:35 * console-setup technically ready to be included 21:35 21:35 * debconf questions about model/layout/variant not 21:35 i18n'ed at all --> blocker for D-I 21:36 do daily builds use svn head? 21:36 or the package 21:36 svn 21:36 uh? 21:36 bubulle: for win32-loader 21:36 ah 21:37 * bubulle still dreams of D-I builds that would rebuild all packages from SVN and build a cutting edge image 21:37 nyu: for d-i installer part only. module are taken from sid 21:38 otavio: ok 21:38 bubulle: I am thinking about it as well... I'd like to be able to use pbuilder for everything as well. But there's stuff that seems more important to me to do first 21:38