Re: My Plan For Uploading Modular To Unstable
>
> 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/developer.php?login=debian-x@lists.debian.org).
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
Reply to: