> > Actually, I was wondering what the status of modularized > xprint packages was? I can't build libxaw8 currently without them, and I'd > like to not leave people depending on it out in the cold right away if I > don't have to... >
That's why I asked, in fact. Xprint does not build at all in xorg 7.0. We got the build fixed in CVS, but there remain problems in FreeType support, and there's no point having it until Xprint works with FreeType. Unfortunately I got the Free Software Treatment (i.e. "scratch your own itch", i.e. no response from them) so far from the X.org developers about it, see http://lists.x.org/archives/xorg-modular/2006-January/000889.html , and I can't keeping pinging them every week to force them to make discussion. I prompted one of them again privately today so I'll hope for a direct reply then. Are you sure libxaw8 strictly depends on a modularised Xprint server? It's just a library, I would have thought it doesn't really care at all about the server. And any server should do, "Xprint 6.8" should be as good as "Xprint 7.0", is it not so? I don't have anything to do directly with libxaw, 8 or otherwise, so maybe there's some detail I missed. I thought it just added widget printing support, which means it must need libXp, the Xprint library, not Xprt the server. I presume modular xorg 7.0 is still providing libXp (that would be module lib/Xp)? I wasn't planning to take over libxp. In regards to the Xprint utilities (xprehashprinterlist, xplsprinters, etc), my xprint currently provides them. Modularly they come from the app modules which you already have, and you're currently commenting them out of the build. When it's time for me to upload modular xprint, I think it makes since to have them built in their natural environment with the other app modules. That is, they'll no longer be provided by the xprint package, and you'll uncomment them from the app packages. Unless you're splitting the app module source tree and aren't currently holding the xprehashprinterlist (&c.) source anyway. What I mean is, we should arrange the source package to build and provide the binary packages for the apps that it contains. That is, we don't want two copies of the xprehashprinterlist (&.c) source lying in the Debian repository. Following that last comment, we *will* however have two copies of the Xprt server source code, one from your xorg-server package and one from my xprint. Once I've aligned my xprint package to match your xorg-server then we can discuss merging the xprint binary packaging over into the xorg-server source package, for the purposes of not duplicating source packages. The modularisation effort does not go so far as to modularly separate the various Xservers (e.g. Xorg, Xprt, Xnest, Xdmx), although I understand Xgl will be separate. Let me know if there is anything we need to clear up. Looking at http://necrotic.deadbeast.net/svn/xorg-x11/branches/modular/lib/, I perceive the absence of libXp... It's not clear to me if you already have its source (I can't even see where libXpm (power management not printing), for instance, belongs at http://qa.debian.org/[EMAIL PROTECTED]). In summary, 1) I'll take care of Xprt, no worries (I can hack in FreeType support if I have to) 2) I'm suggesting to shift the Xprint support apps over to your apps modules 3) I've been assuming you will continue to provide libxp For Point 1, there will be a small lag between xorg7 libraries hitting unstable and modular Xprint being ready, unless someone can convince me I really must start using the packages in experimental Right Now. (I've already built and tested modular Xprt, so I don't expect any such lag to be very long). Point 2 assumes you already have the app module source all together in the one tarball. Looking at your source package separation of xdm vs xbase-clients, maybe this is wrong? What are you doing with app/xplsprinters source at the moment? Things will get ugly if my assumption in Point 3 is wrong. I wasn't presuming to take over any libraries. I might screw up the sonames. > > I have a question about general xorg7 version policy. Will you > > generally be supplying the last "stable" release (7.0 at the moment, right?) > > to Debian unstable, or do you plan to upload xorg cvs? > > I haven't fully decided. Currently in experimental there's 7.0+, which is > all of 7.0 plus the individual components that upstream has currently > decided to release since (i810, libxkbfile, etc). OK, the flexibility is good. Speaking of i810, the latest development version (http://www.fairlite.demon.co.uk/intel.html) is at least 1.6.11 and provides some important bug fixes wrt lockup, though I guess Debian can't supply it until Alan puts it into X.org cvs. I'm just pointing out that i810 1.5.1 is not the "best" version. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
