On Mon, Jan 23, 2006 at 07:32:33AM +0100, Mike Hommey wrote:
> On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow <[EMAIL PROTECTED]>
> wrote:
> > Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> > will install there, at least as far as Xorg goes. An example of that
On Mon, Jan 23, 2006 at 02:56:09PM -0800, Russ Allbery wrote:
> I've done that sort of X configuration hacking to make imake install
> things in appropriate locations and use the right compilers in the past.
> It's not fun work; it's painful, tedious, and exceedingly boring, and I
> wouldn't recomm
On Mon, Jan 23, 2006 at 02:48:33AM -0500, Joey Hess wrote:
> David Nusinow wrote:
> > Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> > will install there, at least as far as Xorg goes. An example of that is
> > that the new xterm package installs to /usr/bin rather than
On Mon, Jan 23, 2006 at 07:32:33AM +0100, Mike Hommey wrote:
> On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow <[EMAIL PROTECTED]>
> wrote:
> > Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> > will install there, at least as far as Xorg goes. An example of that
On Sun, Jan 22, 2006 at 09:54:54PM -0800, Russ Allbery wrote:
> David Nusinow <[EMAIL PROTECTED]> writes:
> > Right. The everything that you'd expect to go in to /usr/bin and
> > /usr/lib will install there, at least as far as Xorg goes. An example of
> > that is that the new xterm package installs
On Mon, Jan 23, 2006 at 08:55:00AM +, Colin Watson wrote:
> There is some software that contains hardcoded paths to executables in
> /usr/bin/X11; for example, sshd hardcodes the path to
> /usr/bin/X11/xauth. sshd stats whatever it thinks is the location of
> xauth to find out whether it can do
On Sun, Jan 22, 2006 at 09:22:24PM -0500, David Nusinow wrote:
>Because the remainder of the Xorg 7.0 packages will require this change
> to have taken place, they will have to pre-depend upon an appropriate
> version of x11-common. As such, I'm writing to the list in accordance with
> policy.
Nathanael Nerode <[EMAIL PROTECTED]> writes:
> Imake is considered dead-except-for-routine-maintenance upstream as far
> as I can tell, so best practice would be to migrate away from it.
> Unless someone plans to adopt it.
imake the program, and xmkmf, are *probably* not that horribly difficult
t
Russ Allbery wrote:
> Here's a list of packages that install binaries into /usr/X11R6/bin and
> don't have lintian overrides for it. In spot checks, about a quarter of
> these packages use imake. And that's just the packages with binaries;
> there are a number of other packages that don't install
Joey Hess writes:
> Debian GCC Maintainers
>gcc-snapshot
no. must be a false positive.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Matthias Klose wrote:
> Joey Hess writes:
> > Debian GCC Maintainers
> >gcc-snapshot
>
> no. must be a false positive.
Yes, didn't anchor the pattern and it matched stuff in
/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/
--
see shy jo
signature.asc
Description: Digital signature
Nathanael Nerode <[EMAIL PROTECTED]> writes:
> Yep.
> Imake is still being shipped for the benefit of third-party packages,
> but it is not used by anything in Xorg 7.0 IIRC. Doing a quick check, I
> think very few if any other packages in Debian use imake.
I think you should perhaps check a li
Russ Allbery wrote:
> (Or is
> imake going away completely?)
Yep.
Imake is still being shipped for the benefit of third-party packages, but it
is not used by anything in Xorg 7.0 IIRC. Doing a quick check, I think very
few if any other packages in Debian use imake.
--
To UNSUBSCRIBE, email
On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote:
> David Nusinow wrote:
> > Currently, it fakes FHS compliancy by creating various
> > symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate
> > directories in /usr/X11R6. For 7.0, we need to make those symlinks become
>
David Nusinow wrote:
> As far as I understand it, this is simply grandfathered in. I'm not that up
> on the FHS details though, so I may be wrong. Remember also that this isn't
> X11R6 any more, but X11R7.
Ok, /usr/X11R7 would probably violate either the spirit or the letter of the
FHS (probably n
On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow <[EMAIL PROTECTED]>
wrote:
> Right. The everything that you'd expect to go in to /usr/bin and /usr/lib
> will install there, at least as far as Xorg goes. An example of that is
> that the new xterm package installs to /usr/bin rather than /us
[David Nusinow]
> As far as I understand it, this is simply grandfathered in. I'm not
> that up on the FHS details though, so I may be wrong. Remember also
> that this isn't X11R6 any more, but X11R7.
Branden toyed with the idea of setting ProjectRoot to /usr when
packaging XFree86 4.0. I was so
David Nusinow <[EMAIL PROTECTED]> writes:
> On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote:
>> David Nusinow wrote:
>>> Currently, it fakes FHS compliancy by creating various symlinks
>>> (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate
>>> directories in /usr/X11R6. Fo
On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote:
> David Nusinow wrote:
> >One of the changes happening for Xorg 7.0 is that it will finally become
> > FHS compliant.
>
> FWIW, the FHS 2.1 specifies /usr/X11R6 in section 4.1. I can't see
> anything FHS-incompliant about the current s
David Nusinow wrote:
>One of the changes happening for Xorg 7.0 is that it will finally become
> FHS compliant.
FWIW, the FHS 2.1 specifies /usr/X11R6 in section 4.1. I can't see
anything FHS-incompliant about the current setup.
> Currently, it fakes FHS compliancy by creating various
> symli
Hi all,
One of the changes happening for Xorg 7.0 is that it will finally become
FHS compliant. Currently, it fakes FHS compliancy by creating various
symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate
directories in /usr/X11R6. For 7.0, we need to make those symlinks bec
21 matches
Mail list logo
