ISHIKAWA Mutsumi wrote: > > Hi, all. > > I've tried to build new xterm.deb package from Thomas' tree last > weekend. I think it is 1st step for pruning xterm from xorg-x11 orig > tarball (it is listed in TODO list of xorg-x11) > > Sources and binary (for i386) are available bellow: > > http://people.debian.org/~ishikawa/xterm/ > > * based on xorg-x11 6.8.2.dfsg.1-0pre1v1 > * TODO: > - {pre,post}{rm,insta} scripts cleanup > - patch audit (patches are roughly merged from xorg-x11)
I just did most of that for you. Additional patches from the xfree86 packaging which impact xterm are: 803_gnu_xterm_openpty.diff -- needed for Hurd 059_external_XrenderXftXcursor_programs.diff -- needed for external Render In xorg-x11 tree: 058_support_external_Xcursor_Xft_Xrender_libs.diff -- New version of 059. 803_gnu_xterm_openpty.diff -- Same as old 803. That's it; none of the other patches patch anything *in* xterm. Xterm also appears to be xdm's "failsafe" client, so it might be wise for xdm to "Recommend" xterm; I don't know. You'll want (obviously) to check that the same files get installed as in the build from the main package; Imake is a tricky beast and it wouldn't do to lose something due to a bad Imake interaction. And if you're switching from the Imake build to the configure/Make build, it's even more dicey. I don't think that a debdiff is a good enough method of avoiding regressions here. You might consider -- and I know this is a bit odd -- doing a build of the new packaging with the exact version used in the monolithic package, and doing a full diff between that build and the build from the monolithic package. That seems like the best way to avoid configuration regressions. -- This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
