4:18 a.m.
Hello, All!
Subj, until i symlinked /usr to usr/X11R6
Looks like someone hardcoded xauth to
/usr/X11R6/bin/xauth
Frankly speaking I think that's a good idea to make this symlink, until
all issues, concerned with modular Xorg, will be resolved.
--
With best regards, Peter Lemenkov.
5:15 a.m.
On Fri, Nov 18, 2005 at 01:18:51PM +0300, Peter Lemenkov wrote:
Looks like someone hardcoded xauth to
/usr/X11R6/bin/xauth
Frankly speaking I think that's a good idea to make this symlink, until
all issues, concerned with modular Xorg, will be resolved.
Bug in openssh. Want to file a bug?
6:43 a.m.
Ralf Ertzinger wrote:
On Fri, Nov 18, 2005 at 01:18:51PM +0300, Peter Lemenkov wrote:
> Looks like someone hardcoded xauth to
>
> /usr/X11R6/bin/xauth
>
> Frankly speaking I think that's a good idea to make this symlink, until
> all issues, concerned with modular Xorg, will be resolved.
>
Bug in openssh. Want to file a bug?
Already reported. Bug # 173414
5:20 a.m.
On Fri, 2005-11-18 at 13:18 +0300, Peter Lemenkov wrote:
Hello, All!
Subj, until i symlinked /usr to usr/X11R6
Looks like someone hardcoded xauth to
/usr/X11R6/bin/xauth
Frankly speaking I think that's a good idea to make this symlink, until
all issues, concerned with modular Xorg, will be resolved.
problem is.. if compat symlinks are made.. the issues will never get
reported and thus not resolved....
6:48 a.m.
On Fri, 18 Nov 2005, Arjan van de Ven wrote:
> Frankly speaking I think that's a good idea to make this
symlink, until
> all issues, concerned with modular Xorg, will be resolved.
problem is.. if compat symlinks are made.. the issues will never get
reported and thus not resolved....
Understand your concerns, but still think that this symlink is necesary.
Please note, that *all* openssh-clients at the whole Planet use hardcoded
path to xauth, and only Fedora Core switches to the modular X. Can we
enforce all of 'em to use new, patched ssh-client? Even theoretically?
And one more: of course end-users never found this bug (and some others,
no doubts), if we allow such workaround, so what? That's a good news for
average Joe, that he will never discovers such issue using its good old
software.
--
With best regards, Peter Lemenkov.
7:14 a.m.
On Fri, Nov 18, 2005 at 03:48:20PM +0300, Peter Lemenkov wrote:
Please note, that *all* openssh-clients at the whole Planet use
hardcoded
path to xauth, and only Fedora Core switches to the modular X. Can we
enforce all of 'em to use new, patched ssh-client? Even theoretically?
I *think* (not having looked at the code) that xauth is being called by
the ssh daemon.
8:15 a.m.
On Fri, 18 Nov 2005, Ralf Ertzinger wrote:
> Please note, that *all* openssh-clients at the whole Planet use
hardcoded
> path to xauth, and only Fedora Core switches to the modular X. Can we
> enforce all of 'em to use new, patched ssh-client? Even theoretically?
I *think* (not having looked at the code) that xauth is being called
by
the ssh daemon.
"Mea culpa!"
Sure, it's called by the sshd.
[petro@Petro ~]$ strings /usr/sbin/sshd | grep X11R6
/usr/X11R6/bin/xauth
[petro@Petro ~]$
--
With best regards, Peter Lemenkov.
10:21 a.m.
Peter Lemenkov wrote:
On Fri, 18 Nov 2005, Ralf Ertzinger wrote:
>> Please note, that *all* openssh-clients at the whole Planet use
>> hardcoded
>> path to xauth, and only Fedora Core switches to the modular X. Can we
>> enforce all of 'em to use new, patched ssh-client? Even theoretically?
> I *think* (not having looked at the code) that xauth is being called by
> the ssh daemon.
"Mea culpa!"
Sure, it's called by the sshd.
[petro@Petro ~]$ strings /usr/sbin/sshd | grep X11R6
/usr/X11R6/bin/xauth
[petro@Petro ~]$
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173568
I tried to fix openssh last night, but it fails to build because modular
X seems to be missing gccmakedep that previously was in xorg-x11-devel.
I am attempting to get gccmakedep back, but we may have run out of time.
Warren Togami
wtogami(a)redhat.com
8:41 a.m.
Once upon a time, Peter Lemenkov <petro(a)mail.ru> said:
Looks like someone hardcoded xauth to
/usr/X11R6/bin/xauth
It isn't "hardcoded" exactly; it is found there by configure and the
path compiled in.
A rebuild of OpenSSH should fix this.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:49 a.m.
On Friday 18 November 2005 03:18am, Peter Lemenkov wrote:
Hello, All!
[snip]
Frankly speaking I think that's a good idea to make this symlink,
until
all issues, concerned with modular Xorg, will be resolved.
I would be concerned about opening that floodgate. If we do, then there is no
reason for people to care to fix their code.
--
Lamont R. Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
6:32 a.m.
Lamont R. Peterson wrote:
On Friday 18 November 2005 03:18am, Peter Lemenkov wrote:
>Hello, All!
[snip]
>Frankly speaking I think that's a good idea to make this symlink, until
>all issues, concerned with modular Xorg, will be resolved.
I would be concerned about opening that floodgate. If we do, then there is no
reason for people to care to fix their code.
Correct. Just prior to the release of Fedora Core 5, I plan on doing
a sweep through bugzilla looking for various compatibility issues with
respect to hard coded paths to things. There are likely to be some
areas where we do need to provide optional backward compatibility, and
at that time, I will likely be creating some compatibility mechanisms,
however the details of exactly what, and how it will work, will be
determined late in the Fedora development cycle.
Right now, the focus is on getting modular X cleaned up and stabilized,
and on getting as much of the rest of the OS as possible, as well as
Fedora Extras, and other 3rd party software out there - all fixed up
to work with modular X too. There are a number of things out there
right now that may very well be broken by modular X, due to paths
moving. That is good. I want to see those applications fixed by
people, and fixed sooner rather than later.
If people know of software that is broken by having hard coded paths
to X binaries, config files, libraries, or X data files, please report
bugs to the upstream developers of those packages, and to the
package maintainers who own the packages. Where possible, please
submit patches to help fix the software to work with modular X.
If you're unsure about how best to fix something in particular, please
ask directly on this mailing list and/or on the main xorg list
upstream. If I see your question and have time to offer an answer,
I will gladly try to help.
Having said that, I want to emphasize that I am not in a rush to
provide backward compatibility symbolic links for anything at this
early point in the Fedora development cycle, as that just allows
broken applications to stay broken indefinitely, or until we
remove the symlink in an OS release or 2 or 3.
Also, when we do decide late in the development cycle what compat
links we should provide for the final OS release, I plan on disabling
them again in rawhide as soon as FC6 development starts up, to
further "encourage" people to fix broken applications that are
still out there.
By contributing to reporting bugs, and/or fixing the broken
applications, people will help to get rid of such compatibility
problems much sooner, and the whole community will benefit from
it.
1:14 p.m.
By contributing to reporting bugs, and/or fixing the broken
applications, people will help to get rid of such compatibility
problems much sooner, and the whole community will benefit from
it.
On the other side keeping things compatibel should be a goal
for all necessary changes we do.
regards,
Florian La Roche
9:23 a.m.
On Fri, 2005-11-18 at 10:49 -0700, Lamont R. Peterson wrote:
> Frankly speaking I think that's a good idea to make this
symlink, until
> all issues, concerned with modular Xorg, will be resolved.
I would be concerned about opening that floodgate. If we do, then there is no
reason for people to care to fix their code.
Perhaps we could make the symlink, but configure the selinux policy to
bitch if it's ever actually used?
--
dwmw2
6:19 a.m.
Peter Lemenkov wrote:
Hello, All!
Subj, until i symlinked /usr to usr/X11R6
Looks like someone hardcoded xauth to
/usr/X11R6/bin/xauth
Frankly speaking I think that's a good idea to make this symlink, until
all issues, concerned with modular Xorg, will be resolved.
Symlinks to directories can cause a lot of problems when future packages
reverse directions. I am currently facing a big dir/symlink problem in
the modular X packages which is going to be difficult to resolve.
Rawhide may have changed its name to "Fedora Developement", but it is
still very much "raw" hide. Expect that some things will break from
time to time, and that some things will stay broken until they are
fixed.
Feel free to hack around problems on your own system if you desire,
until a problem is fixed properly, but you will not see this type
of hack come from my X packages. There are a lot of software out
there that put their files into /usr/X11R6 that are not a part
of X, and while we've fixed most of the ones that come with the OS,
we have no control over the various 3rd party packages out there
that violate the directory structure.
Consider the fact that various packages on people's systems do have
files installed by rpm in /usr/X11R6. Ignoring the fact that rpm
will not allow you to replace a directory (/usr/X11R6) with a
symbolic link for the minute - what would happen to all of the
applications that were installed via rpm, which have files in
/usr/X11R6, if all of a sudden, /usr/X11R6 became a symlink that
pointed to /usr?
How would you implement this?
rm -rf /usr/X11R6 ; ln -s /usr /usr/X11R6
Like that? That would make a lot of happy users I'm sure. ;o)
If you require a stable OS, use Fedora Core 4 please, and wait until
rawhide has had some of the "raw" shaken out of it. That is generally
around test3 or so. Alternatively, wait until Fedora Core 5 final
is released.
6772
days inactive
6773
days old
13 comments
10 participants
participants (10)
-
Arjan van de Ven -
Chris Adams -
David Woodhouse -
Florian La Roche -
John Ellson -
Lamont R. Peterson -
Mike A. Harris -
Peter Lemenkov -
Ralf Ertzinger -
Warren Togami