Log from the Debian Installer team mini-meeting of March 5th 2006, 21:00UTC --------------------------------------------------------------------------- People who speak below: fjp : Frans Pop eddyp : Eddy Petrisor zinosat : Davide Viti aurel32 : Aurélin jarno Indeed, the meeting was announced but Christian Perrier forgot to post reminders in the mailing list and even forgot to attend it. As a consequence, very few people attended the meeting which was turnet into a mini meeting of the few people involved in the Graphical Installer. Hours are European Time (UTC +0200): [23:07:40] fjp has changed the topic on channel #debian-boot to "d-i meeting - probably a short one" [23:07:41] Attillio is not here :( [23:07:42] o/ [23:08:17] eddyp fixed problems at home, so starting with this weekend will really start to work on the fonts [23:08:30] OK. Given the audience, let's quickly discuss g-i and call it a day. [23:09:11] We are very close with the udeb dependency migration. [23:09:46] no, I don't have his skills and knowledge [23:10:11] All regular libs used by d-i are now done, except devmapper and parted. [23:10:33] For g-i we are only missing directfb, which is fixed in experimental. [23:10:35] not too close on this, but what is the impact of the recent directfb related chages? [23:10:58] eddyp tries to get back in contact with g-i issues [23:11:32] It makes the current gtk+2.0-directfb segfault... [23:11:59] the only fix being the transition to 2.8.10? [23:12:02] fjp, unfortunately I will not be able to test anything until next week [23:13:07] I don't know about the fix. [23:13:43] according to the upstream plans DFB 0.9.25 should be out next week, gtk+2.10 sometimes in May [23:13:52] I hope that some kind of temporary solution can be found. [23:14:11] Yeah, but 2.10 release != 2.10 available in unstable. [23:14:23] what about a cvs udeb package? [23:14:33] in experimental, maybe? [23:14:38] And the release could slip [23:14:43] What do you mean? [23:15:12] make a DFB udeb with a CVS snaphot [23:15:28] s/snaphot/snapshot/ [23:15:30] DFB is not the problem. [23:15:36] gtk is. [23:16:00] err, that too (sorry for being uninformed) [23:16:13] that might be a slution. joshtriplett asked me once if he could help with an udeb in case we needed... [23:17:16] fjp: what do you think about the cvs udeb idea? [23:17:27] eddyp: well I don't know. The machine is not at home, but at work, so I could only try tomorrow [23:17:28] zinosat: a package for what exactly? [23:18:12] he offered his (generic) help packaging an udeb [23:18:13] gdk? [23:18:35] and we could ask to package a snapshot of gtk+ [23:18:39] if that is the problem [23:19:09] obviously we cannot give for granted he will.I need to ping him [23:19:23] probably will enter under a different name in the archive [23:19:28] The problem is that it could conflict with the official packages. [23:19:47] not if it has an another name [23:19:50] eddyp: It will still produce the same libraries in the same places by default. [23:20:08] Conflicts? [23:20:20] that's why is there [23:20:22] perhaps I'm missing something, but the udeb would replace the current 2.0.9 [23:20:40] and only a udeb should be made [23:20:58] zinosat: No, we cannot put a replacement 2.09 in the archive. Only the gnome team can do that. [23:21:07] I see [23:21:19] And for licence reasons you can not put only an udeb in the archive. [23:21:38] so, let's see what Attilio has to say about this (he has analyzed the pb) [23:21:51] not sure there's a workaround though [23:22:06] fjp: hmm, but what if is not a replacement 2.09? is a different package conflicting with the base one and has "-CVS" in its name [23:22:22] fjp: I was suggesting not to create a deb, but only a udeb [23:22:50] eddyp: You'd still have to convince the FTP masters that it is a good idea... [23:22:55] and place the source for that -cvs udeb in the archive [23:23:00] to be honest I'm not too surprised such a huge change of libs will cause a period of breakage [23:23:03] it will be removed later [23:23:16] Well, you need the deb to be able to build libs and packages that depend on it... [23:23:20] so it's only temporary [23:23:23] exactly [23:24:09] if we will be using -cvs suffix or smth, still it could be done, with the ftpmasters objection in mind [23:24:31] Yeah, but 1-3 months breakage just when we've got dependencies sorted out is not something I look forward too. [23:25:14] fjp: I don't follow you [23:25:44] Another option is to try to keep the current directfb package alive for a while. And keep using that. [23:26:04] let's evaluate that option [23:26:33] in any case we should start poking the right ppl to start the process of packaging something new [23:27:14] I'm afraid the gnome team will move at its own speed and will not really be influenced by d-i. [23:27:19] we will need to modify cdebconf-gtk to support the new dfb at some point, so those missing APIs will still be needed in [23:28:01] Also, there is a very nice packaging challenge there anyway: we want the new gtk build only against directfb; they want it built against X... [23:28:04] fjp, i see your point now [23:28:22] Same goes for cairo. [23:28:27] fjp: that was already done [23:28:30] once [23:28:46] we have the udeb with dfb support [23:28:47] For cairo we have solved it temporarily by creating a separate package. [23:29:05] I think it shall remain the same in the future [23:29:22] and that is a good thing, imho [23:29:26] eddyp: Only by creating a full shadow package: gtk+2.0-directfb. Not by integrating it in the main packages. [23:29:58] I'd prefer to see it integrated into the main packages now that the patches have been integrated. [23:30:04] well, if it's such a big elephant we will be tied very closely to gtk+ release schedules [23:30:06] Idon't see the reason why it should not be integrated [23:30:50] zinosat: not until the first release; after that we can just backport what is needed [23:31:51] the only good thing about all this is that the directfb backand lives in its own subdir and is almost 100% indipendent/modular [23:32:19] Well, I don't have all the answers now. I do know that someone will have to work fairly closely with gtk and cairo packagers to create exactly what we want and have the certainty that the build environment stays sane. [23:33:13] zinosat: maybe alistair can help us? [23:33:17] if gtk+ (not directfb specific parts) evolve, it's very likely the directfb will just work [23:33:25] Yes. [23:33:48] obviously during the all release cycle for 2.x.y [23:34:09] with x fixed [23:34:25] AFAICT this resumes to: [23:35:04] - having an official package (with DFB backend) that can live in the archive with the X backend [23:35:42] - packaging is done as we need it and is not broken from a DFB POV [23:35:48] right? [23:36:39] Roughly, yes. [23:37:06] let's see if we can live with what we have first [23:37:27] and in the meanwhile start thinking about a brand new package [23:38:00] zinosat: any idea about how we can live with what we have? [23:38:05] from Attilio's message on d-boot, he should have already an answer for my first question [23:38:08] the "as we need it" is mostly a clean, minimal udeb and -dev packages that have the DFB backend and allow us to build other udebs against [23:38:25] fjp: right [23:39:04] anyway, having sources in main cvs helps alot, really [23:39:42] "live with what we have" means trying to get a temporary package with the current directfb accepted. I think we can do that by conflicting with the new package. [23:40:11] yes [23:40:12] zinosat: AFAICT, the problem now is that cdebconf-gtk relies on removed APIs in the new DFB variants [23:40:50] so cdebconf-gtk willl have to be changed, but probably Attilio has done that [23:40:56] or was that in GTK? [23:41:07] We can do that primarily because directfb only needs to be installed at build time and the buildds can deal with that. [23:41:09] don't know [23:42:02] eddyp: Hmm. The plan is to try to keep the current (old) directfb for a while... [23:42:05] eddyp looks on list archives [23:42:28] So we don't have to change either gtk+2.0-directfb or cdebconf-gtk [23:42:35] fjp, yes. [23:43:05] That would buy us the time to wait for the new upstream releases to arrive. [23:43:06] again, Attilio has the answer, so we need to see the report he said he would post [23:43:34] OK. Let's wait for that, but keep this in mind. [23:44:03] Would it help to have gtk 2.10 CVS udebs? [23:44:08] If attilio knows a solution wher we can upgrade the current gtk+2.0-directfb somehow, that would be even better. [23:44:19] Not only udebs, no. [23:44:39] We need the full development stuff to be able to build depending packages. [23:44:47] zinosat: Frans has explained we need the debs, too [23:45:08] right [23:45:19] scratch that:) [23:45:20] but having CVS debs and udebs would fix the issue [23:45:45] well "fix" the issue :o) [23:45:47] but we don't want to take over that beast [23:46:24] No, we have to be careful about being in the way of the offical packagers. [23:46:34] yes, agree [23:47:00] that could be done by using different package names and Conflicts fields [23:47:19] besides the political issues [23:47:20] But if Josh thinks he can do that within a reasonable timeframe, then I'm all for it. [23:47:45] fjp, do you know him? [23:48:05] eddyp: It would mean that you can only install them in a clean chroot or something. On a "normal" system it will conflict with gnome, gimp and whatever... [23:48:18] zinosat: Only by name. Never worked with him. [23:48:53] we have a fairly automated build process for libs with dfb so making the -dfb-cvs packages should not be that hard [23:49:03] fjp: we don't care :-D [23:49:22] he's been extremely helpful with freefont and he offered his help without me having to ask [23:49:25] a big fat warning in the description could help [23:50:09] He's not a DD though, right? [23:50:40] does it matter? you are, 'though, so you can upload, right ? ;-) [23:50:43] don't know. I spoke with him on d-d [23:51:14] eddyp: It does very much if you want to get complex NEW packages accepted into the archive [23:51:44] oh, right these will be NEW... damn [23:52:01] we have to see if he still has the time / want to do that. can't speak for him [23:52:20] I'll ping him as soon as I see he's on d-d [23:52:25] right, as a backup, can we ask Alistair? [23:52:48] is he still willing to help g-i? [23:53:15] perhaps that is the fist ppl we should ask to [23:54:05] Alistair is a DD and has GTK packages, right? So this would be a plus... [23:54:26] I doubt alastair will want to package a new upstream, but we could ask. [23:55:04] ok, I'm not sure there's much left to say about this [23:55:13] Still, I do see a lot of hurdles on that path and my estimate is that keeping the current directfb is more feasible [23:55:31] me too [23:55:31] fjp agrees [23:55:46] Let's wait for what Attilio has to say. [23:55:52] yep [23:55:58] I'll mail him this discussion. [23:56:06] ok [23:56:15] Goodnight all. [23:56:19] night [23:56:27] fjp has changed the topic on channel #debian-boot to "Debian installer development channel - 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"