Log from the Debian Installer meeting of September 26th 2007, 20:00 UTC ----------------------------------------------------------------------- People who speak below: Alphix : David Härdeman eddyp : Eddy Petrișor fabbione : Fabio M. Di Nitto fjp : Frans pop h01ger : Holger Levsen Lunar^ : Jérémy Bobbio maks : Maximilian Attems nyu : Robert Millan otavio : Otavio Salvador pere : Petter Reinholdtsen waldi : Bastian Blank Nicknames mentioned during the meeting though these people were not attending: anibal : Anibal Monsalve Salazar cjwatson : Colin Watson dannf : Dann Frazier joeyh : Joey Hess nekral : Nicolas François Sledge : Steve McIntyre 19:59 -- 19:59 Usual IRC meeting recommandations: 19:59 * Please focus on the #debian-boot IRC channel, leave other IRC channels and a 19:59 queries for later. 19:59 * Shutdown your email client or turn off its automatic checking abilities. 19:59 * Keep a text editor handy to prepare your statements. 19:59 * The meeting needs to be dynamic and fluid, but not too fast: we do not all 19:59 have the same typing abilities and everyone should be able to participate. 19:59 -- 20:00 bubulle_, pere, otavio ? 20:00 * pere = Petter Reinholdtsen 20:00 i'm here 20:00 pere: :-) 20:01 ping 20:01 hey 20:01 As long as no one oppose on that, the meeting will stop at 22:00 UTC (or 20:01 before if we run out of things to discuss). 20:02 joeyh is probably somewhere else (idle for 1+ day)... Let's start 20:02 * waldi have two other points: busybox and mklibs update 20:02 Neither Colin nor Anibal are there, so let's skip the already postponed items 20:03 waldi: Let's start with that, then, as it's related to the future beta1 20:03 -!- Lunar^ changed the topic to: busybox and mklibs update 20:04 busybox is updated to 1.6. 1.7 is waiting. but now completely unchecked 20:04 i want to do the update after beta1 as it may break anything 20:05 Are you going to upload 1.6 or move directly to 1.7? 20:05 i want to do 1.7 directly 20:05 nice. I'd going to suggest it 20:05 it will drop ifconfig and include ping 20:05 I was going to.. sorry 20:06 Lunar^: have you got a reply from ppp-udeb change? 20:06 I still need to send a fixed image to EddyP 20:06 ah food 20:06 good 20:06 the image was broken, lacking pppoe-modules 20:06 but I am fairly sure about my patch, ip was already used, but inconsistently in the script 20:07 Is there other breakage to be expected? 20:07 no 20:07 Lunar^: would be nice if we might get this out for beta1 (the ifconfig removal) so it gets testing 20:07 Lunar^: of ppp-udeb, I meant 20:07 is there a patch? 20:08 Ok, I'll see what I with EddyP about it 20:08 yes, but untested 20:08 okay 20:08 I suggest we move on to mklibs 20:08 Lunar^: good :-) thanks 20:09 newt lacks a fix AFAIK 20:09 i try to get the lib-force-patch tested 20:09 joeyh did an NMU earlier this evening 20:09 ah, okay 20:10 See #443248 20:10 This last patch allows me to build my branch, I hope it does not break anything else, though 20:10 (the '-l') 20:10 yep 20:10 Lunar^: this is the last blocker for the cdebconf merging, right? 20:11 it is :) 20:11 I need to verify everything once more, they might be one issue left in the tab ordering of the graphical frontend 20:12 waldi: Any excepted date for an upload? 20:12 waldi: maybe an upload to experimental would make the testing easier? 20:12 "the cdebconf merging" refers to? 20:13 Alphix: Lunar^ changes to gtk frontend and plugins api 20:13 Lunar^: weekend? 20:13 Alphix: a quite invasive changes in the way cdebconf handles the frontend plugins and a rewrite of the GTK+ code 20:13 ok 20:13 Fine with me 20:13 Let's move on to beta1, as we already slightly started that topic 20:14 basically the next big step is to move to 2.6.22 kernel 20:14 -!- Lunar^ changed the topic to: d-i beta1 20:14 looks like we finally will get it in shape to be ready to go for testing and then we'll be able to update the installer for it 20:15 i plan to wait for l-m-e to be build on all arches and then do a massbuild for the kernel udebs and modules 20:15 i guess, begin of next week we ought to be done with it 20:16 mklibs being solved, last main blocker is cdebconf merging and test 20:16 and then we can start to draw a timeline for the beta1 release 20:16 This kernel fixes the issue on sparc? 20:17 not yet 20:17 waldi: right? 20:17 partman has important issues, mostly due to new diskclean code 20:17 fjp: That's #425829? 20:18 otavio: not yet 20:18 Lunar^: Yes. And I think I filed another one about the same time. 20:19 #425840 20:19 I will try to see what I can do about partman... I need to resign myself to understand that strange beast 20:19 Lunar^: hehe 20:20 do you need me for README.html? I have to go to sleep 20:20 You could also look at Alphix. He introduced the changes after all... :-) 20:20 Alphix: ^ 20:20 nyu: Nope, thanks :) 20:20 ok bye ;-) 20:20 Can we do the beta1 with a broken sparc kernel? 20:20 Which changes? 20:21 Lunar^: I think that we'll need to do that 20:21 Alphix: removing old crypto partitions 20:21 Lunar^: otherwise we'll delay it for a not yet know time 20:21 Lunar^: yes, there is no fix available 20:22 Let's hope the fix will arrive while I'll merge cdebconf... 20:22 oh that...perhaps the lowmem-load-on-demand checks should be added there as well 20:22 Lunar^: and sparc porters could be pushed to get it fixed that way 20:22 As far as I have read, it is still on fabionne's radar 20:22 Alphix: please, would be nice if you could take a look at partman issues 20:22 Lunar^: I have this impression too 20:23 fabbione: news about that? (sparc bug) 20:23 But #425829 doesn't mention deallocating crypto volumes 20:23 I will try to look at #410418 with Sledge if he has enough time 20:23 (netinst images being too big) 20:23 Lunar^: I can probably help on it too 20:24 Lunar^: we might try to get it sorted out together 20:24 Alphix: No, but it worked before your changes. 20:24 otavio: "partman issues"...as in bug reports for all partman packages? I only know partman-crypto (and some partman-lvm/auto) 20:24 otavio: Sounds like a good idea 20:24 Alphix: no, I meant those regressions. 20:24 Alphix: but if you can help with rest it would be awesome ;-) 20:25 Alphix: and it's never later to learn another thing ;-) 20:25 fjp: I see, I'll try to take a look at that bug report in more detail then (but I assume it's "only" the on-demand dmsetup loading that is necessary) 20:25 otavio: yes and no. david just come back this tuesday from vacation and he is catching up on his emails. That's all I know for now 20:26 Alphix: Yes, that is the most important issue. What must be considered is if we want to have partman auto depend on that or not. 20:26 fabbione: thanks :-) 20:26 otavio: no problem. 20:26 otavio: it's lack of time that's the problem, not lack of interesting ideas to implement/bugs to fix :) 20:27 Alphix: IMO not as not to burden lowmem, but it should be coded so that it still behaves sanely if dmsetup is not present. 20:27 fjp: what is the general feeling on the lowmem load-on-demand stuff...is it still necessary? Is it useful? Does it create more headaches than it solves? 20:27 Are anyone working on #440161 (problem with adaptec 2100). I believe it affects Debian Edu/Etch too. 20:27 IMO it's useful. 20:28 pere: That's probably not a D-I issue? 20:28 Alphix: I think we should keep avoid using memory as possible 20:28 pere: I lost track of it, if you can go on it would be great 20:28 fjp: I am not sure. I've been unable to understand the issue. 20:28 If there's no other blocker that should be handled, I suggest that we move on 20:28 fabbione: What was that partman BR you followed up on? 20:29 pere: We can discuss it a bit after the meeting if you want 20:29 Lunar^: I will not have time to look at it, but Werner said he might have time to look at the debian edu version of it. 20:29 pere: good 20:29 fabbione: The one that also affected ubuntu. 20:30 Ok, summary: 20:30 * otavio takes care of the transition to 2.6.22 20:30 * mklibs issue will be sorted this week-end 20:30 * Lunar starts merging his cdebconf branch right after that 20:30 * Alphix and eventually Lunar looks at the partman diskclean regression 20:30 * Lunar and otavio looks at the "netinst being too big issue" 20:31 just ... 20:31 I am missing something? 20:31 Lunar^: let's keep two or tree days before merging cdebconf after kernel changes 20:31 fjp: it was the one about removing LVM or raid meta data from disks IIRC 20:31 Lunar^: so we get the whole picture of it 20:31 fjp: i don't have the bug num handy 20:31 Lunar^: I mean the uploads. Not the svn merging 20:31 fabbione: Yep. 20:32 otavio: ok :) 20:32 fjp: yeah i wrote a test case for it 20:32 fjp: or better.. how to reproduce it 20:32 fjp: it just takes an awful amount of time.. 20:33 -!- Lunar^ changed the topic to: d-i etch r2 | 20:33 fjp: can you dig it up yourself or do you need help? I was kinda in the middle of watching a movie when the bells started ringing :) 20:34 fabbione: Give me the BR afterward, I'll add it to the minutes 20:34 fabbione: I can't find it either :-( 20:34 Lunar^: is the meeting over? 20:34 ok 20:34 eddyp: Nope 20:34 Ok, let's move on :) 20:34 Lunar^: your slot ;-) 20:34 I have been working on getting an updated installer for the next Etch point 20:34 release. What has currently been done: 20:34 * cdebconf/0.114etch1 has been uploaded and accepted - improving memory usage, 20:34 * grub-installer/1.22etch1 has been uploaded - fixing serial console issues, 20:34 * libdebian-installer/0.50etch1 has been uploaded - adding support SGI O2, 20:34 * partman-crypto/20etch1 has been uploaded - fixing loop-aes on hd-media, 20:34 * uswsusp/0.3~cvs20060928-7etch1 has been uploaded - fixing the misleading 20:34 warning about swap. 20:35 What is left to be done: 20:35 * debconf: cjwatson told me two weeks ago that he would do the update ; as I 20:35 did not have seen any signs from him in last days, I would like to do it, if 20:35 someone adds me to the alioth project. 20:35 * kernel: dannf is going to uploaded a -15 with the security fixes merged, 20:35 there will be no ABI update. Once I will got his green-light, I am willing 20:35 to take care of the massbuilds. 20:35 * choosemirror: will probably need to be updated 20:35 * debian-installer: fjp gave me the necessary instructions on how to make a 20:35 stable upload. It is necessary to coordinate with the SRM and ftpmasters 20:35 in order to make everything smooth. 20:35 Any advices, comments? 20:36 keep the good work :-) 20:36 (I have been quite happy to do that stuff, it really helped to understand a lot of small details. I have started to gather various informations in DebianInstaller/ReleaseProcess on the wiki.) 20:36 otavio: Is it Ok with you to add me to the debconf project so I can take care of the upload? 20:37 you and the rest of the team, probably 20:37 :) 20:37 fjp: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425829 <- this is realated. should help to find the other one 20:37 fabbione: Yep, that's mine :-) I was looking for that other one. 20:38 Lunar^: done. Setted you as admin 20:38 err... :) I was not asking that much... :) 20:38 Lunar^: I doubt anyone will have problems with it. 20:38 Ok, let's move on if there's nothing else to add 20:39 -!- Lunar^ changed the topic to: discover-pkginstall 20:39 pere: Your turn. :) (And thanks for being there!) 20:39 so, not sure where to start. 20:39 fjp: #396023 20:40 I've extended discover to support mapping hardware to debian packages, and added support for building out-of-three kernel modules from source when installed. 20:40 all that is needed is to run the discover-pkginstall script as root, and it will take care of the rest, listing the detected packages and allow the user to select/deselect before any installation is done. 20:41 fabbione: I will take a look at that bug at the same time as #425829 20:41 this can for example install 915resolution for cards that need it, raid controller tools for servers that need it, wireless drivers, usb camera drivers, etc. 20:41 pere: does it handle environment to choose the packages? for exemple, if user is using GNOME offer X otherwise Y? 20:41 fabbione: (and since I wrote the patch for that bug) 20:42 anything that can be detected by discover can be mapped to packages. 20:42 Alphix: cool thanks 20:42 otavio: no. 20:42 otavio: here is nothing fancy about it so far. it is a simple mapping from hw->package, with a special handling of packages with module-assitant support. 20:43 pere: good 20:43 I believe it is a good idea to call the script from the normal installer, for example in hw-detect, to install the useful hw-related packages. 20:43 fabbione: Thx! 20:43 no problem guys 20:43 * fabbione goes back to his movie 20:43 pere: wouldn't hw-detect be too earlie? 20:43 so I wanted to check what the rest of you thought about it. 20:44 Alphix: what you really really really want to avoid is to have to enable vgs/lvs to detect them. Use pvs/vgs/lvs. 20:44 otavio: yes. it would have to be a finish-install.d fragment or post-base-installer.d fragment. 20:44 Is the question necessary? My feeling is that it should probably be avoided when not in expert mode 20:44 Alphix: otherwise you will open an entire new box of cans of worms 20:44 fabbione: yes 20:45 Lunar^: nope, it is not required, and the default is to install the detected packages. I believe I made it medium priority. 20:45 Lunar^: ack on it 20:45 Is there packages that are less safe to be built than others? 20:45 s/built/installed/ 20:45 Lunar^: I have no idea. :) 20:45 pere: would be nice to have a preseeding that allow to disable the calling from d-i 20:45 * bubulle_ just back home. Sorry, ppl, unplanned events with my kids......and I can't stay...just wanted to apologize quickly 20:45 otavio: yeah. but that would be in the udev code. 20:46 bubulle_: we'll talk about localization-config another time, then 20:46 pere: no on d-i, right? 20:46 I would like as many as possible to test the script on your machine, and let the discover-data maintainers know if some pakcage should be installed for your hardware. 20:46 s/udev/udeb/ aka d-i, yes. 20:47 About the packages handled by module-assistant, I believe that they would be built only if the required pre-built packages can't be found in the archive, is that corect? 20:48 not at the moment, no. 20:48 for the few I have added to discover-data, the hw map to the source package, and every source package is build if installed. 20:49 pere: so it doesn't check of there's no binary version ready to install before build? 20:49 In stable releases, we normally have the right packages in the archive, so it sounds like quite an overhead to build them by hand 20:49 otavio: nope. it does not know what the name of that package would be. 20:50 I thought that module-assistant was consistent in the resulting package names 20:50 pere: well I personally think this would be bad. Most of desktop people wouldn't want to have compilers and like installed (and don't need them) 20:50 Lunar^: could be. I did not think about prebuild binary packages when I wrote the source building code. 20:50 pere: besides, it makes the binary modules available on archive useless 20:51 I agree that it would be useful to try to install the prebuilt binary package if it is present. 20:51 otavio: do you have time to implement something like that? 20:51 pere: imho, if we get it to use binary versions to be used (when available), I'd be ok for get it in 20:51 pere: not now :( 20:51 otavio: you need to make sure that all binaries are buildable. the binary packages already make sure that they areupdated at the same time 20:52 pere: I've been busy at work due tree projects here :( 20:52 waldi: right 20:52 otavio: know the feeling. :) 20:52 pere: hehe 20:52 otavio: and the current setup can't do that 20:52 (dkt may support it) 20:53 waldi: does it means that dkt would deprecate m-a? 20:53 My feelings: this would be a welcome addition to the installer. I wonder how it could be interact with tasksel so users of GNOME desktops for example gets the right GUI tools installed. Anyway, adding discover-pkginstall is post beta1 to me, so we can really start to work on that in a month or two. 20:54 otavio: it will deprecate kpkg for debian linux kernels, not more for now 20:54 Lunar^: I agree that it will not be ready for beta1. 20:54 pere: Can you try to get in touch with joeyh about tasksel interactions? 20:54 pere: personally I think that tasksel integration would be a requirement for d-i integration 20:55 Lunar^: I wonder about that too. for now I limit it to desktop agnostic packages like 915resolution and dpt-utils. :) 20:55 pere: would be very bad to get in kde application for something if the user choose gnome, for example :( 20:55 pere: 915resolution is now obsolete though ;) 20:55 it would be useful for out-of-tree wireless drivers, except that it will be too late for network installs. :) 20:55 pere: but think about synaptics configuration utilities 20:56 Lunar^: really? what replaces it? 20:56 pere: the new intel driver 20:56 Better drivers 20:57 yes disover is a band aid, pls kick it 20:57 pere: modsetting support from i810 driver 20:57 otavio: that is now called "intel" 20:57 maks: useful to other kernels, I think 20:57 Lunar^: ah nice. Missed this 20:57 Lunar^: I do not want perfect to be the enemy of good enough, and believe having raid control software etc installed automatically is enough to justify the discover-pkginstall script at the moment. It can be improved, sure, but that can be done later. 20:57 no need on the default otavio 20:58 but I got the input I need to know that I should go on with d-i integration. 20:58 maks: I don't think you and pere are talking about the same discover functionality 20:58 pere: true 20:59 Summary: 20:59 * call the script in hw-detect to install the useful hw-related packages and it would have to be a finish-install.d fragment or post-base-installer.d 20:59 * pere would like everyone to give discover-pkginstall on their machine a shot and see if anything is missing 20:59 * need to use binary module packages if possible 21:00 * probably needs integration with tasksel for GUI tools 21:00 * integration will be done post beta1 21:00 Did I miss anything? 21:00 looks ok to me 21:00 looks good to me too. 21:01 Let's skip the topic about localization-config as bubulle can't be here 21:01 -!- Lunar^ changed the topic to: README.html new look 21:02 As you have probably seen on the mailling-list today, the new look for 21:02 README.html that was proposed by Kalle Söderman (see 21:02 http://kjs.homeip.net/projects/debian/debinstall/README) has been integrated to 21:02 debian-cd by Sledge and myself. Kalle also made a new look for the 21:02 README.mirrors, but this looks like a lot more difficult to get in, currently. 21:02 Now that win32-loader asks for a language before displaying the README, it 21:02 probably makes more sense now to add it to the translators lists. nekral will 21:02 look on how po4a could be used to do it properly. 21:02 Any comments? 21:03 what the problems of .mirros? 21:03 mirrors? 21:03 (btw, the secret agenda is to push forward a new look for www.debian.org by this mean) 21:03 Lunar^: hehe :-) it would be _GREAT_ 21:03 As far as I have understood, it's taken directly from what's in webwml generates 21:04 So it's not really possible to change the README.mirrors without changing what is on the website 21:04 and well... I don't want to mess with debian-www right now 21:04 got it 21:05 There is still discussions ongoing the mailling-list abouth the content of the README, which is a good thing... The last update of the README was dated 2004 21:05 Ok, let's move on, that was mostly informative 21:06 Date was 2004, but there have been more recent changes... 21:06 true 21:06 We've done updates for both Sarge, Etch and post Etch. 21:07 We can try to get an automatic date update if we manage to get it btranslated 21:07 Or just drop the date. 21:07 indeed :) 21:07 -!- Lunar^ changed the topic to: partman-crypto 21:08 personally I think it could be droped 21:08 Mostly informative as well, I wanted to relay the same information I gave in the D-I members poll....that I'm still alive and trying to keep up-to-date with partman-crypto bugs etc, but I am quite swamped, I have an exam in October and then another one (a whopper) in March which will keep me more busy then I'd like until then. 21:08 is useless to know when it has been change 21:08 But interesting things I'd like to work on: 21:08 * multi-disk support (this will fix the RAID issue as well). Needs a gui for partman-lvm 21:09 (also needs changes to cryptsetup - this is the issue I get the most bugmail to my private email address about) 21:09 * waldi have to go 21:09 * USB-key to store crypto keys (I have this working on my laptop but it needs GUI hookup as well) 21:10 * And (added today by fjp more or less) deallocation of crypto partitions 21:10 For the multi-disk GUI I was thinking of something like presenting a multi-choice window if more than one disk is detected (in the partman-auto-lvm and partman-auto-crypto dialogues) 21:10 I'd like to say this once more: partman-crypto is a killer feature of d-i, and I really think we need to take good care of it as we are the only distribution (AFAIK) which supports that 21:11 Note that you cannot require a gui for basic functionality! 21:11 And then depending on the number of disks selected....the user will get RAID levels to choose from 21:11 fjp: GUI for setting it up during installation that is 21:11 fjp: I think GUI he means partman integration 21:11 Not GUI for actually using it 21:11 otavio: correct 21:11 fjp: not g-i usage only 21:11 Alphix: good 21:12 Alphix: OK. GUI = cdebconf-gtk, not the newt interface. 21:12 Alphix: one good news where I'll probably need your help: my cdebconf branch contains the necessary code for an entropy plugin for the graphical installer 21:12 I'm damaged by too much bash....anything beyond black-and-white text is GUI to me 21:12 heh :) 21:12 :-) 21:13 Alphix: ack with you about GUI concept. ncurses is gui too ;-) 21:13 Lunar^: I saw that...I also considered disabling it for the non loop-AES case since the keys are so much smaller for dm-crypt 21:13 I've never seen the entropy screen when not using loop-AES 21:14 Please be aware than Anton started to work on partman-lvm again 21:14 But I guess it could be important on entropy-lacking systems (such as diskless ones) 21:14 Good to know 21:14 I have seen it once in an emulator 21:14 It needs to go on automatically if it was already 100%, I filled a wishlist about it 21:15 I think a slightly different approach would be better....first read entropy, then if not enough, present entropy plugin 21:15 Haven't looked at it though...low prio 21:15 I can try to have a look at that 21:16 Part of the partman-multidisk for lvm/crypto is also to whack partman-md so it doesn't kill partman-crypto's settings for md devices 21:16 Would you have enough time to review some patches when to integrate cdebconf-gtk-entropy? 21:16 madduck said that he'll look at it... I probably need to bug him about that... 21:16 Lunar^: I could try, but I think my partner in crime for partman-crypto would be a better choice since he wrote the first entropy plugin 21:17 Ok, I'll see with Max then 21:17 When do you think you will have time to work on all that stuff again? 21:17 If he can't/won't, let me know and I'll have a look 21:18 About partman. Is anybody going to upload all the pending changes? 21:18 Wish I knew...extreme studies have prio right now :) I'll do my best to put in the spare hours I find 21:18 fjp: I was hoping for a last reply from joeyh 21:19 Joey has never done very much with partman. Mostly Colin and me (and of course Anton and Alphix). 21:19 fjp: I talked to colin and he said he was going to do that 21:19 fjp: but he didn't since then 21:19 Alphix: don't hesitate to send patches or get a separate branch if we are in the preparation of a beta (like now) 21:20 I will take care of the upload tomorrow then 21:20 fjp: and I'm not feel safe to do that since I do not know them very well 21:20 Lunar^: perhaps I've missed it, but is there a timeplan somewhere? 21:20 fjp: neither have the time to test all them for it 21:20 Those regressions really should be fixed before beta1. If not, revert should be considered. 21:20 Lunar^: :-D nice! 21:21 otavio: Then you should probably not touch it. 21:21 Alphix: not yet ; but expect one soon 21:21 fjp: that's what I did ;-) 21:21 fjp: which regressions are you referring to? 21:22 Those BRs we discussed earlier. 21:22 otavio: speaking of partman-crypto and GUI's....any news on usplash? 21:22 * Lunar^ is confused: mixing up choosemirror in partman 21:22 sorry 21:22 Alphix: in which aspect? 21:22 Alphix: but let's talk it in private, offtopic here 21:22 otavio: sure 21:23 Alphix: I have a friend which said that he would look into it - I'm still waiting for some news - but yeah, it's offtopic 21:23 Moving on? 21:23 I should get more friends to look into stuff for me :) 21:23 I have nothing to add 21:24 Alphix: thanks for coming :) 21:24 np, thanks for reminding me 21:24 bubulle is not here, so let's postpone the poll results 21:24 -!- Lunar^ changed the topic to: "align" and g-i 21:24 I have been trying to add support for "columns" or "aligned" select question 21:24 handlers for the graphical installer, following Anton's proposal (see 21:24 http://lists.debian.org/debian-boot/2007/07/msg00723.html). 21:25 You can see the current result here: http://people.debian.org/~lunar/cdebconf-align-localechooser.png 21:25 It is currently available as a plugin, using "$$" to separate columns. Using 21:25 this feature would then mean, it seems, quite a lot of changes throughout the 21:25 installer to use it. 21:25 Another possibility that I thought about tonight would be to merge the code 21:25 actually in the plugin (which sounds doable, I am only using tab stops, 21:25 not true GtkTreeView columns) in the core frontend, and parse a succession of 21:25 two spaces like a column separator. This parsing would be conditionally 21:25 enabled by a new capability. 21:25 What do you think? 21:26 What happens in newt frontend with that code? 21:26 If we have something like "s/ */\t/g", we can keep all the current code as it is 21:26 if we keep the plugin way, we need dedicated debconf templates as it is a different question type 21:27 I have sent a private mail to Anton asking for his ideas without an answer yet 21:27 Lunar^: do you think it's going to be ready for beta1? 21:27 Memory impact of extra templates needs to be considered, as they'll probably be included in udebs by default 21:27 -EPARSE the "s/ */\t/g" comment. 21:27 otavio: nope 21:28 Umm...."s/ */\t/g" sounds dangerous for newt...doesn't it risk hitting cases where a couple of spaces have been used just for formatting/lining up text? 21:28 Lunar^: I think that this should be discussed deeply when you get Anton reply 21:28 Alphix: Agree. 21:28 (I'm thinking of the main partitioning screen) 21:29 Lunar^: Alphix gave a good point about possible regressions if we change the spaces on current texts 21:29 fjp: sorry... Curent templates have "French - Français" ; so if when the "align" capability is enabled the frontend transforms that into "French\t-Français" it will align nicely in GTK+ (with other Pango tickling under the hood) 21:29 Lunar^: and personally I think that is good to keep things as plugins if it doesn't hurt too much 21:29 Sorry, I am totally unclear 21:29 The idea is actually to avoid changing any templates 21:30 example from partman-lvm: output=$(printf "%-30s (%sMB)" "$pv" "$SIZE") 21:30 -!- pere is now known as pere_Zzzz 21:31 It would just be adding "db_capb align" before the templates get called when alignment would be desirable 21:31 Lunar^: I doubt that will work. There will always be the risk of lines where you only have one space on the separation. 21:31 IMO you need to actually have a separator in the templates and also modify other frontends so they know how to handle it. 21:32 I think the "$$" trick (combined with "db_capb align") and gradual template change sounds better 21:32 But I've been proven wrong before. 21:32 I personally think we use something like latex does: && or like ($$ as cited could be used) and does change it 21:32 I've never been proven wrong before. :) 21:32 Bleh! 21:33 That means adding more templates and more code, then 21:33 (and figuring out where to put that in partman) 21:33 Adding templates? Don't you mean gradually changing templates? 21:34 And adding the align capability to every frontends? 21:34 Yes? 21:34 Template duplication should be the last resort... 21:34 true 21:34 But that is a hell lot of work 21:35 Lunar^: I personally think it's the way to go 21:35 Proper structural implementation of something like this is bound to be... 21:35 Lunar^: try to do that without changing previous templates is prone to fail 21:35 Oh I remember something else now 21:35 You basically need to extend the protocol. 21:36 The plugin way has the problem that you would need two separate plugins for both select and multiselect 21:36 How does the alignment work? How are two "ReallyReallyReallyReallyReallyLongString$$Value" and "ShortString$$Value" strings aligned? 21:37 with my current code, they are 21:37 Anton's original idea was to get resizable columns, but this can't be done together with text spaning on multiple column in GTK+ 21:37 at least not without a hell lot of new code 21:37 that I was not able to write this summer 21:38 anyway, this should be avoided for other frontends 21:38 What should be avoided? 21:39 Well, as I've said before, the screenshot looks really nice. It really would be great to have this supported. 21:39 "ReallyReallyReallyReallyReallyLongString" 21:39 yes....we need to keep an eye on that without the alignment anyway 21:39 I am commited to it ; I hope I'll have enough energy to work on all the needed changes though 21:39 thanks for your feedback, I need to resign myself :) 21:40 s/resign/reason/ 21:40 I think it would be great, it could potentially help alot with the partitioning screen as well 21:40 indeed 21:40 The agenda is over 21:41 Is there anything people would like to talk about? 21:41 Good :-) 21:41 * otavio need to go! 21:41 Request: could someone check apt-setup and upload? 21:41 fjp: Ok, I was tying something about it 21:41 fjp: this was my previous mix up, I was waiting for a last reply from joeyh about it 21:41 Ah, OK. 21:42 nyu, so setup.exe, win32-loader.ini and autorun.inf are created when you build the package? and then you copy them where? cd root directory? 21:42 but your changes looked ok to me (fun enough, I was trying to understand the issue the very same day with a private bugmail) 21:42 Yes, that's fine by me. But he really did get this issue wrong IMO. 21:43 fjp: I will upload the change tomorrow evening if there is no further input on that issue 21:43 Thx 21:43 fjp: btw, I have fixed the interaction between main-menu and cdebconf-priority yesterday 21:43 fjp: but the changes in main-menu 1.19 makes the "Download installer components" entry useless if it stays at high priority 21:44 Yes, I saw. Nice. Will test nect time I run an install. 21:44 Has been discussed with Colin before. 21:45 I have read the thread (before asking about sudo)... this change has been done quite lightly I'd say 21:45 Would it be against the rule to prompt for extra components at high priority if this step had been already run before? 21:46 h01ger: he went to bed earlier on 21:48 Lunar^, ah. thanks. 21:48 * h01ger files debian-edu bug to document his questions :) 21:48 (and nyus answers!) 21:48 Thanks for everyone for attending, I'll take care of the minutes 21:49 Lunar^: No, that could be a solution. Best use a touch file and not a debconf var to save that. 21:49 * h01ger apologies, i forget there was a meeting today. 21:49 (the debconf var in localechooser that does the same should probably be replaced by a file too) 21:49 fjp: Does not anna-install already have a mechanism about it? 21:50 Not that I know. 21:50 Ok, I'll see what I can do... thanks for the advice