[users] Request and a bug: gksu

[Todd And Margo Chester]

Hi Daag,

Request: would you consider upgrading your el5 RPMs of
gksu and libgksu for SL6?


Okay now a bug to report: Since you did not have SL6
RPMs for gksu, I installed your el5 versions on my
new SL6 x64 bit server:

gksu-2.0.0-1.el5.rf.x86_64.rpm
libgksu-2.0.5-1.el5.rf.x86_64.rpm

Problem: I got a crash saying gksu could not find
"gksu-run-helper".

Work around:
mkdir /usr/lib/libgksu
ln -s /usr/lib64/libgksu/gksu-run-helper
/usr/lib/libgksu/gksu-run-helper

So the 64 bit version is still looking in the 32 bit location
for gksu-run-helper

-T

[Yury V. Zaytsev]

FYI: https://github.com/repoforge/rpms/issues/12

Since you did not have SL6 RPMs for gksu, I installed your el5

Baaaad idea.

[Todd And Margo Chester]

Post by Yury V. Zaytsev
FYI: https://github.com/repoforge/rpms/issues/12

Thank you. I will track it.

Post by Yury V. Zaytsev

Since you did not have SL6 RPMs for gksu, I installed your el5

Baaaad idea.

Why? What am I missing? Older code is harmful, why? SL6
is all out-of-date anyway. What harm does one more out-of-date
app cause amongst the thousands of other out-of-date apps?
No dependencies were added. I do not get it. Please educate me.

Many thanks,
-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester
Why? What am I missing? Older code is harmful, why? SL6
is all out-of-date anyway. What harm does one more out-of-date
app cause amongst the thousands of other out-of-date apps?
No dependencies were added. I do not get it. Please educate me.

I consider this too basic Linux knowledge, to be elaborated on this
list. The keywords are "linking", "ABI / API compatibility", "rpm
versions" etc. Otherwise see Jim's comprehensive reply.

You *might* get away with mixing packages *sometimes*, but at other
times, it can cause anything in between software malfunctioning and
catastrophic data loss. And very certainly, it is a bad idea for
anything security related, such as gksu.

[Todd And Margo Chester]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
Why? What am I missing? Older code is harmful, why? SL6
is all out-of-date anyway. What harm does one more out-of-date
app cause amongst the thousands of other out-of-date apps?
No dependencies were added. I do not get it. Please educate me.

I consider this too basic Linux knowledge, to be elaborated on this
list. The keywords are "linking", "ABI / API compatibility", "rpm
versions" etc. Otherwise see Jim's comprehensive reply.
You *might* get away with mixing packages *sometimes*, but at other
times, it can cause anything in between software malfunctioning and
catastrophic data loss. And very certainly, it is a bad idea for
anything security related, such as gksu.

Hi Yury,

Thank you for your patience with me over my misunderstanding.
I am still stuck on if it is a security hazard in el6, why is it not also a
security hazard in el5? I presume that the dependencies in the RPM
would take care of anything that is different. The code itself is
still the code itself -- the code has not changed. If it is safe in one,
it should be safe in the other. I am clearly not getting your point.

-T

[Yury V. Zaytsev]

Hi!

Post by Todd And Margo Chester
I am still stuck on if it is a security hazard in el6, why is it not also a
security hazard in el5? I presume that the dependencies in the RPM
would take care of anything that is different.

This is, in fact, a very wrong assumption. RPM will not take care of it.

RPM always assumes that the packages are coming from an appropriate
channel and only tries to detect situations when there is a danger of
inducing direct damage to the RPM database (unsatisfiable dependencies,
wrong checksum / file corrupted, wrong signature etc.)

If you keep mixing things, you are totally on your own. In the very best
case it will detect some obvious linking problems, but not more than
that. Possible pitfalls:

1) Library SONAME didn't change (i.e. functions get added), and the
program uses new ABI, you install the RPM on the old system

2) Interpreter version is not recorded in RPM, software incompatible
with newer/older Python

3) Few hundred others...

Post by Todd And Margo Chester
The code itself is still the code itself -- the code has not changed.
If it is safe in one, it should be safe in the other. I am clearly
not getting your point.

You know, you should really get some basics right first. Sorry for that.

[Todd And Margo Chester]

Post by Yury V. Zaytsev
Hi!

Post by Todd And Margo Chester
I am still stuck on if it is a security hazard in el6, why is it not also a
security hazard in el5? I presume that the dependencies in the RPM
would take care of anything that is different.

This is, in fact, a very wrong assumption. RPM will not take care of it.
RPM always assumes that the packages are coming from an appropriate
channel and only tries to detect situations when there is a danger of
inducing direct damage to the RPM database (unsatisfiable dependencies,
wrong checksum / file corrupted, wrong signature etc.)
If you keep mixing things, you are totally on your own. In the very best
case it will detect some obvious linking problems, but not more than
1) Library SONAME didn't change (i.e. functions get added), and the
program uses new ABI, you install the RPM on the old system
2) Interpreter version is not recorded in RPM, software incompatible
with newer/older Python
3) Few hundred others...

Post by Todd And Margo Chester
The code itself is still the code itself -- the code has not changed.
If it is safe in one, it should be safe in the other. I am clearly
not getting your point.

You know, you should really get some basics right first. Sorry for that.

Hi Yury,

Thank you for the education.

Follow up question: if I were to skip the RPM process and just compile
the app from the/a tar ball, would that remove your security concerns?

Many thanks,
-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester
Follow up question: if I were to skip the RPM process and just compile
the app from the/a tar ball, would that remove your security concerns?

If you manage to do it properly, then mostly yes. Indeed, bigger part of
the issues are caused by running binaries on a system that they were not
compiled for (be it older or newer).

You can still screw up on many occasions, i.e. install the application
that was compiled from source into the directory tree that is controlled
by the package manager.

This actually sometimes happens even when you did everything correctly,
for instance when there is a bug / hardcoded path somewhere in the build
system that causes make install to ignore the prefix for some files,
which is why software is never to be compiled or installed as root.

...

[Todd And Margo Chester]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
Follow up question: if I were to skip the RPM process and just compile
the app from the/a tar ball, would that remove your security concerns?

If you manage to do it properly, then mostly yes. Indeed, bigger part of
the issues are caused by running binaries on a system that they were not
compiled for (be it older or newer).
You can still screw up on many occasions, i.e. install the application
that was compiled from source into the directory tree that is controlled
by the package manager.
This actually sometimes happens even when you did everything correctly,
for instance when there is a bug / hardcoded path somewhere in the build
system that causes make install to ignore the prefix for some files,
which is why software is never to be compiled or installed as root.

Thank you.
-T

[Todd And Margo Chester]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
Follow up question: if I were to skip the RPM process and just compile
the app from the/a tar ball, would that remove your security concerns?

If you manage to do it properly, then mostly yes. Indeed, bigger part of
the issues are caused by running binaries on a system that they were not
compiled for (be it older or newer).
You can still screw up on many occasions, i.e. install the application
that was compiled from source into the directory tree that is controlled
by the package manager.
This actually sometimes happens even when you did everything correctly,
for instance when there is a bug / hardcoded path somewhere in the build
system that causes make install to ignore the prefix for some files,
which is why software is never to be compiled or installed as root.

Thank you.
-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester
Follow up question: if I were to skip the RPM process and just compile
the app from the/a tar ball, would that remove your security concerns?

If you manage to do it properly, then mostly yes. Indeed, bigger part of
the issues are caused by running binaries on a system that they were not
compiled for (be it older or newer).

You can still screw up on many occasions, i.e. install the application
that was compiled from source into the directory tree that is controlled
by the package manager.

This actually sometimes happens even when you did everything correctly,
for instance when there is a bug / hardcoded path somewhere in the build
system that causes make install to ignore the prefix for some files,
which is why software is never to be compiled or installed as root.

...

[Todd And Margo Chester]

Post by Yury V. Zaytsev
Hi!

Post by Todd And Margo Chester
I am still stuck on if it is a security hazard in el6, why is it not also a
security hazard in el5? I presume that the dependencies in the RPM
would take care of anything that is different.

This is, in fact, a very wrong assumption. RPM will not take care of it.
RPM always assumes that the packages are coming from an appropriate
channel and only tries to detect situations when there is a danger of
inducing direct damage to the RPM database (unsatisfiable dependencies,
wrong checksum / file corrupted, wrong signature etc.)
If you keep mixing things, you are totally on your own. In the very best
case it will detect some obvious linking problems, but not more than
1) Library SONAME didn't change (i.e. functions get added), and the
program uses new ABI, you install the RPM on the old system
2) Interpreter version is not recorded in RPM, software incompatible
with newer/older Python
3) Few hundred others...

Post by Todd And Margo Chester
The code itself is still the code itself -- the code has not changed.
If it is safe in one, it should be safe in the other. I am clearly
not getting your point.

You know, you should really get some basics right first. Sorry for that.

Hi Yury,

Thank you for the education.

Follow up question: if I were to skip the RPM process and just compile
the app from the/a tar ball, would that remove your security concerns?

Many thanks,
-T

[Yury V. Zaytsev]

Hi!

Post by Todd And Margo Chester
I am still stuck on if it is a security hazard in el6, why is it not also a
security hazard in el5? I presume that the dependencies in the RPM
would take care of anything that is different.

This is, in fact, a very wrong assumption. RPM will not take care of it.

RPM always assumes that the packages are coming from an appropriate
channel and only tries to detect situations when there is a danger of
inducing direct damage to the RPM database (unsatisfiable dependencies,
wrong checksum / file corrupted, wrong signature etc.)

If you keep mixing things, you are totally on your own. In the very best
case it will detect some obvious linking problems, but not more than
that. Possible pitfalls:

1) Library SONAME didn't change (i.e. functions get added), and the
program uses new ABI, you install the RPM on the old system

2) Interpreter version is not recorded in RPM, software incompatible
with newer/older Python

3) Few hundred others...

Post by Todd And Margo Chester
The code itself is still the code itself -- the code has not changed.
If it is safe in one, it should be safe in the other. I am clearly
not getting your point.

You know, you should really get some basics right first. Sorry for that.

[Todd And Margo Chester]

Post by Yury V. Zaytsev

Post by Todd And Margo Chester
Why? What am I missing? Older code is harmful, why? SL6
is all out-of-date anyway. What harm does one more out-of-date
app cause amongst the thousands of other out-of-date apps?
No dependencies were added. I do not get it. Please educate me.

I consider this too basic Linux knowledge, to be elaborated on this
list. The keywords are "linking", "ABI / API compatibility", "rpm
versions" etc. Otherwise see Jim's comprehensive reply.
You *might* get away with mixing packages *sometimes*, but at other
times, it can cause anything in between software malfunctioning and
catastrophic data loss. And very certainly, it is a bad idea for
anything security related, such as gksu.

Hi Yury,

Thank you for your patience with me over my misunderstanding.
I am still stuck on if it is a security hazard in el6, why is it not also a
security hazard in el5? I presume that the dependencies in the RPM
would take care of anything that is different. The code itself is
still the code itself -- the code has not changed. If it is safe in one,
it should be safe in the other. I am clearly not getting your point.

-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester
Why? What am I missing? Older code is harmful, why? SL6
is all out-of-date anyway. What harm does one more out-of-date
app cause amongst the thousands of other out-of-date apps?
No dependencies were added. I do not get it. Please educate me.

I consider this too basic Linux knowledge, to be elaborated on this
list. The keywords are "linking", "ABI / API compatibility", "rpm
versions" etc. Otherwise see Jim's comprehensive reply.

You *might* get away with mixing packages *sometimes*, but at other
times, it can cause anything in between software malfunctioning and
catastrophic data loss. And very certainly, it is a bad idea for
anything security related, such as gksu.

[Todd And Margo Chester]

Post by Yury V. Zaytsev
FYI: https://github.com/repoforge/rpms/issues/12

Thank you. I will track it.

Post by Yury V. Zaytsev

Since you did not have SL6 RPMs for gksu, I installed your el5

Baaaad idea.

Why? What am I missing? Older code is harmful, why? SL6
is all out-of-date anyway. What harm does one more out-of-date
app cause amongst the thousands of other out-of-date apps?
No dependencies were added. I do not get it. Please educate me.

Many thanks,
-T

[Jim Perrin]

On Mon, Jun 6, 2011 at 12:32 AM, Todd And Margo Chester

Post by Todd And Margo Chester
Hi Daag,

Really? If you're going to ask people to do stuff, please at least
spell their name correctly. It's literally the least you could do.

Post by Todd And Margo Chester
Okay now a bug to report: ?Since you did not have SL6
RPMs for gksu, I installed your el5 versions on my

As has been stated, this is a bad route to go down for several reasons.

Post by Todd And Margo Chester
? ? ?gksu-2.0.0-1.el5.rf.x86_64.rpm
? ? ?libgksu-2.0.5-1.el5.rf.x86_64.rpm
Problem: I got a crash saying gksu could not find
"gksu-run-helper".
? ? ? mkdir /usr/lib/libgksu
? ? ? ln -s /usr/lib64/libgksu/gksu-run-helper
/usr/lib/libgksu/gksu-run-helper
So the 64 bit version is still looking in the 32 bit location
for gksu-run-helper

Does it do this on the el5 version? because that's just about the only
way this could be considered a bug. Something behaving incorrectly on
el6 when it's built for el5 isn't exactly shocking.

[Todd And Margo Chester]

Post by Jim Perrin

Post by Todd And Margo Chester
Hi Daag,

Really? If you're going to ask people to do stuff, please at least
spell their name correctly. It's literally the least you could do.

Oh crap. Sorry Dag. No offense intended.

-T

[Todd And Margo Chester]

Post by Jim Perrin
On Mon, Jun 6, 2011 at 12:32 AM, Todd And Margo Chester
Okay now a bug to report: Since you did not have SL6

Post by Todd And Margo Chester
RPMs for gksu, I installed your el5 versions on my

As has been stated, this is a bad route to go down for several reasons.

No one actually stated the reasons.

Using older piece of code is a problem, why? Everything in Enterprise
Linux is old. That is the idea. Why would this particular piece of
older code
be an issue and the thousands of other pieces of older code in EL
not be a problem? I do not understand. (Out-of-date Firefox drives me
nuts.)

Post by Jim Perrin

Post by Todd And Margo Chester
gksu-2.0.0-1.el5.rf.x86_64.rpm
libgksu-2.0.5-1.el5.rf.x86_64.rpm
Problem: I got a crash saying gksu could not find
"gksu-run-helper".
mkdir /usr/lib/libgksu
ln -s /usr/lib64/libgksu/gksu-run-helper
/usr/lib/libgksu/gksu-run-helper
So the 64 bit version is still looking in the 32 bit location
for gksu-run-helper

Does it do this on the el5 version? because that's just about the only
way this could be considered a bug. Something behaving incorrectly on
el6 when it's built for el5 isn't exactly shocking.

I would think that the paths are hard coded in the package. So, I would
also think they would behave exactly the same in el5 as el6. Not "shocking"
at all. Do the paths somehow float around depending on the revision of
the kernel? Am I mistaken? Is there some dependancy statement:

if el5
then helper=/usr/lib64/libgksu/gksu-run-helper
elif el6
then helper=/usr/lib/libgksu/gksu-run-helper
endif

I would presume the path to gksu-run-helper was simply
hard coded. What am I missing?

This is from a 64 bit CentOS 5.6 server I also administer. I had to place
the same link to compensate for the 32 bit path in a 64 bit package.

# uname -a
Linux server.xxx.local 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:13 EDT
2011 x86_64 x86_64 x86_64 GNU/Linux

# rpm -qa *\gksu\*
libgksu-2.0.11-1.el5.rf
gksu-2.0.0-1.el5.rf

# ls -al /usr/lib/libgksu
total 44
drwxr-xr-x 2 root root 4096 Dec 5 2009 .
drwxr-xr-x 78 root root 36864 May 10 15:13 ..
lrwxrwxrwx 1 root root 34 Dec 5 2009 gksu-run-helper ->
/usr/lib64/libgksu/gksu-run-helper


So, yes, it reproduces on el5. Now that is "shocking". Not really. :-)

-T

[Jim Perrin]

On Mon, Jun 6, 2011 at 3:06 PM, Todd And Margo Chester

Post by Todd And Margo Chester
No one actually stated the reasons.

Nor did I say they did. I said it was already stated to be bad, and
it's bad for several reasons.

Post by Todd And Margo Chester
Using older piece of code is a problem, why? ?Everything in Enterprise
Linux is old. ?That is the idea. ?Why would this particular piece of
older code
be an issue and the thousands of other pieces of older code in EL
not be a problem? ?I do not understand. ?(Out-of-date Firefox drives me
nuts.)

Not all enterprise linux is equal. Just because el5 and el6 are both
'enterprise' doesn't mean that you can go mixing packages
interchangeably. While you may think el6 is already out of date, it's
3-4 years newer than el5 software. The kernel (and kernel ABI) have
changed, as have python versions, glibc (the core library which is
depended on by nearly everything), the compression used for rpm, yum,
and on and on and on.

It's all newer, it's not all 100% backwards compatible. Installing el5
packages on el6 installs and expecting it to 'just work' shows a
fundamental failure of understanding for how linux in general
operates.

Post by Todd And Margo Chester
I would think that the paths are hard coded in the package. ?So, I would
also think they would behave exactly the same in el5 as el6. ?Not "shocking"
at all. ?Do the paths somehow float around depending on the revision of

How you think it should operate and how it may actually operate aren't
always the same thing. This is why I asked the question. Testing is
important. Yes, paths may change based on what version of something is
in use. There are a number of applications like this as well as many
spec files within the rpmforge arsenal that have conditional builds
and path modifiers based on the el version they're targeting.

Post by Todd And Margo Chester
? ? if el5
? ? ? ?then helper=/usr/lib64/libgksu/gksu-run-helper
? ? elif el6
? ? ? ? then helper=/usr/lib/libgksu/gksu-run-helper
? ? endif

While not true for this particular package, this is indeed the case
for many packages. Hell, even the rpmforge-release package has this
exact sort of logic built into the spec file for compile-time
operations, and there's essentially no source code to build. To see an
example of this have a look at ->
http://dries.ulyssis.org/rpm/packages/rpmforge-release/rpmforge-release-spec.html

What you're describing is far from an unusual case.

Post by Todd And Margo Chester
I would presume the path to gksu-run-helper was simply
hard coded. ?What am I missing?

Experience.

Post by Todd And Margo Chester
So, yes, it reproduces on el5.

So file the bug against el5. Don't bitch that something doesn't work
on a system it wasn't built for. Bitch that it doesn't work on the
system it WAS built for.

Post by Todd And Margo Chester
?Now that is "shocking". ?Not really. ?:-)

Your snark would have more weight if you made the effort to learn a
bit more about the software you use and the path it takes from source
to packaged install.

[Todd And Margo Chester]

Post by Jim Perrin
So file the bug against el5.

Where is the proper place to file the bug? Does Dag
have a bugzilla?

-T

[Yury V. Zaytsev]

Post by Todd And Margo Chester

Post by Jim Perrin
So file the bug against el5.

Where is the proper place to file the bug? Does Dag
have a bugzilla?

Just add it to the report I created earlier today.

I checked it out and I see no reason why libgksu would actually ignore
explicit libdir that is correctly passed to it and break multilib
compatibility.

If this file is multiarch, then it should go into share and not lib. So
I guess it just a hardcoded path that the developers missed at some
point, which might have been fixed already in a newer software release.

[Steve Huff]

Post by Todd And Margo Chester
Where is the proper place to file the bug? Does Dag
have a bugzilla?

this list is a good place.

in addition, Yury has already created a bug for you on our GitHub issue tracker, here:

https://github.com/repoforge/rpms/issues/12

if you comment on that issue, you'll get notifications when it is updated in the future.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
Url : http://lists.repoforge.org/pipermail/users/attachments/20110606/43676e62/attachment-0001.bin

[Todd And Margo Chester]

Post by Steve Huff

Post by Todd And Margo Chester
Where is the proper place to file the bug? Does Dag
have a bugzilla?

this list is a good place.
https://github.com/repoforge/rpms/issues/12
if you comment on that issue, you'll get notifications when it is updated in the future.
-steve

Hi Steve,

Will report it on the github in a few days when I get some office time.

Was the report I made in this thread sufficient, of should I restate it
in a new thread?

Many thanks,
-T

[Todd And Margo Chester]

Post by Steve Huff

Post by Todd And Margo Chester
Where is the proper place to file the bug? Does Dag
have a bugzilla?

this list is a good place.
https://github.com/repoforge/rpms/issues/12
if you comment on that issue, you'll get notifications when it is updated in the future.

I just added this and the leafpad/gksu issues to the github post.

[Todd And Margo Chester]

Post by Steve Huff

Post by Todd And Margo Chester
Where is the proper place to file the bug? Does Dag
have a bugzilla?

this list is a good place.
https://github.com/repoforge/rpms/issues/12
if you comment on that issue, you'll get notifications when it is updated in the future.
-steve

Hi Steve,

Will report it on the github in a few days when I get some office time.

Was the report I made in this thread sufficient, of should I restate it
in a new thread?

Many thanks,
-T

[Todd And Margo Chester]

Post by Steve Huff

Post by Todd And Margo Chester
Where is the proper place to file the bug? Does Dag
have a bugzilla?

this list is a good place.
https://github.com/repoforge/rpms/issues/12
if you comment on that issue, you'll get notifications when it is updated in the future.

I just added this and the leafpad/gksu issues to the github post.

[Yury V. Zaytsev]

Post by Todd And Margo Chester

Post by Jim Perrin
So file the bug against el5.

Where is the proper place to file the bug? Does Dag
have a bugzilla?

Just add it to the report I created earlier today.

I checked it out and I see no reason why libgksu would actually ignore
explicit libdir that is correctly passed to it and break multilib
compatibility.

If this file is multiarch, then it should go into share and not lib. So
I guess it just a hardcoded path that the developers missed at some
point, which might have been fixed already in a newer software release.

[Steve Huff]

Post by Todd And Margo Chester
Where is the proper place to file the bug? Does Dag
have a bugzilla?

this list is a good place.

in addition, Yury has already created a bug for you on our GitHub issue tracker, here:

https://github.com/repoforge/rpms/issues/12

if you comment on that issue, you'll get notifications when it is updated in the future.

-steve

--
If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
PGP 8477B706 (A92A 1F7E 6D76 16A0 BFF9 E61D AD54 0251 8477 B706)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110606/43676e62/attachment.sig>

[Todd And Margo Chester]

Post by Jim Perrin
So file the bug against el5.

Where is the proper place to file the bug? Does Dag
have a bugzilla?

-T

[Jim Perrin]

On Mon, Jun 6, 2011 at 3:06 PM, Todd And Margo Chester

Post by Todd And Margo Chester
No one actually stated the reasons.

Nor did I say they did. I said it was already stated to be bad, and
it's bad for several reasons.

Post by Todd And Margo Chester
Using older piece of code is a problem, why? ?Everything in Enterprise
Linux is old. ?That is the idea. ?Why would this particular piece of
older code
be an issue and the thousands of other pieces of older code in EL
not be a problem? ?I do not understand. ?(Out-of-date Firefox drives me
nuts.)

Not all enterprise linux is equal. Just because el5 and el6 are both
'enterprise' doesn't mean that you can go mixing packages
interchangeably. While you may think el6 is already out of date, it's
3-4 years newer than el5 software. The kernel (and kernel ABI) have
changed, as have python versions, glibc (the core library which is
depended on by nearly everything), the compression used for rpm, yum,
and on and on and on.

It's all newer, it's not all 100% backwards compatible. Installing el5
packages on el6 installs and expecting it to 'just work' shows a
fundamental failure of understanding for how linux in general
operates.

Post by Todd And Margo Chester
I would think that the paths are hard coded in the package. ?So, I would
also think they would behave exactly the same in el5 as el6. ?Not "shocking"
at all. ?Do the paths somehow float around depending on the revision of

How you think it should operate and how it may actually operate aren't
always the same thing. This is why I asked the question. Testing is
important. Yes, paths may change based on what version of something is
in use. There are a number of applications like this as well as many
spec files within the rpmforge arsenal that have conditional builds
and path modifiers based on the el version they're targeting.

Post by Todd And Margo Chester
? ? if el5
? ? ? ?then helper=/usr/lib64/libgksu/gksu-run-helper
? ? elif el6
? ? ? ? then helper=/usr/lib/libgksu/gksu-run-helper
? ? endif

While not true for this particular package, this is indeed the case
for many packages. Hell, even the rpmforge-release package has this
exact sort of logic built into the spec file for compile-time
operations, and there's essentially no source code to build. To see an
example of this have a look at ->
http://dries.ulyssis.org/rpm/packages/rpmforge-release/rpmforge-release-spec.html

What you're describing is far from an unusual case.

Post by Todd And Margo Chester
I would presume the path to gksu-run-helper was simply
hard coded. ?What am I missing?

Experience.

Post by Todd And Margo Chester
So, yes, it reproduces on el5.

So file the bug against el5. Don't bitch that something doesn't work
on a system it wasn't built for. Bitch that it doesn't work on the
system it WAS built for.

Post by Todd And Margo Chester
?Now that is "shocking". ?Not really. ?:-)

Your snark would have more weight if you made the effort to learn a
bit more about the software you use and the path it takes from source
to packaged install.

[Todd And Margo Chester]

Post by Jim Perrin

Post by Todd And Margo Chester
Hi Daag,

Really? If you're going to ask people to do stuff, please at least
spell their name correctly. It's literally the least you could do.

Oh crap. Sorry Dag. No offense intended.

-T

[Todd And Margo Chester]

Post by Jim Perrin
On Mon, Jun 6, 2011 at 12:32 AM, Todd And Margo Chester
Okay now a bug to report: Since you did not have SL6

Post by Todd And Margo Chester
RPMs for gksu, I installed your el5 versions on my

As has been stated, this is a bad route to go down for several reasons.

No one actually stated the reasons.

Using older piece of code is a problem, why? Everything in Enterprise
Linux is old. That is the idea. Why would this particular piece of
older code
be an issue and the thousands of other pieces of older code in EL
not be a problem? I do not understand. (Out-of-date Firefox drives me
nuts.)

Post by Jim Perrin

Post by Todd And Margo Chester
gksu-2.0.0-1.el5.rf.x86_64.rpm
libgksu-2.0.5-1.el5.rf.x86_64.rpm
Problem: I got a crash saying gksu could not find
"gksu-run-helper".
mkdir /usr/lib/libgksu
ln -s /usr/lib64/libgksu/gksu-run-helper
/usr/lib/libgksu/gksu-run-helper
So the 64 bit version is still looking in the 32 bit location
for gksu-run-helper

Does it do this on the el5 version? because that's just about the only
way this could be considered a bug. Something behaving incorrectly on
el6 when it's built for el5 isn't exactly shocking.

I would think that the paths are hard coded in the package. So, I would
also think they would behave exactly the same in el5 as el6. Not "shocking"
at all. Do the paths somehow float around depending on the revision of
the kernel? Am I mistaken? Is there some dependancy statement:

if el5
then helper=/usr/lib64/libgksu/gksu-run-helper
elif el6
then helper=/usr/lib/libgksu/gksu-run-helper
endif

I would presume the path to gksu-run-helper was simply
hard coded. What am I missing?

This is from a 64 bit CentOS 5.6 server I also administer. I had to place
the same link to compensate for the 32 bit path in a 64 bit package.

# uname -a
Linux server.xxx.local 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:13 EDT
2011 x86_64 x86_64 x86_64 GNU/Linux

# rpm -qa *\gksu\*
libgksu-2.0.11-1.el5.rf
gksu-2.0.0-1.el5.rf

# ls -al /usr/lib/libgksu
total 44
drwxr-xr-x 2 root root 4096 Dec 5 2009 .
drwxr-xr-x 78 root root 36864 May 10 15:13 ..
lrwxrwxrwx 1 root root 34 Dec 5 2009 gksu-run-helper ->
/usr/lib64/libgksu/gksu-run-helper


So, yes, it reproduces on el5. Now that is "shocking". Not really. :-)

-T

[Todd And Margo Chester]

Hi Daag,

Request: would you consider upgrading your el5 RPMs of
gksu and libgksu for SL6?


Okay now a bug to report: Since you did not have SL6
RPMs for gksu, I installed your el5 versions on my
new SL6 x64 bit server:

gksu-2.0.0-1.el5.rf.x86_64.rpm
libgksu-2.0.5-1.el5.rf.x86_64.rpm

Problem: I got a crash saying gksu could not find
"gksu-run-helper".

Work around:
mkdir /usr/lib/libgksu
ln -s /usr/lib64/libgksu/gksu-run-helper
/usr/lib/libgksu/gksu-run-helper

So the 64 bit version is still looking in the 32 bit location
for gksu-run-helper

-T

[Yury V. Zaytsev]

FYI: https://github.com/repoforge/rpms/issues/12

Since you did not have SL6 RPMs for gksu, I installed your el5

Baaaad idea.

[Jim Perrin]

On Mon, Jun 6, 2011 at 12:32 AM, Todd And Margo Chester

Post by Todd And Margo Chester
Hi Daag,

Really? If you're going to ask people to do stuff, please at least
spell their name correctly. It's literally the least you could do.

Post by Todd And Margo Chester
Okay now a bug to report: ?Since you did not have SL6
RPMs for gksu, I installed your el5 versions on my

As has been stated, this is a bad route to go down for several reasons.

Post by Todd And Margo Chester
? ? ?gksu-2.0.0-1.el5.rf.x86_64.rpm
? ? ?libgksu-2.0.5-1.el5.rf.x86_64.rpm
Problem: I got a crash saying gksu could not find
"gksu-run-helper".
? ? ? mkdir /usr/lib/libgksu
? ? ? ln -s /usr/lib64/libgksu/gksu-run-helper
/usr/lib/libgksu/gksu-run-helper
So the 64 bit version is still looking in the 32 bit location
for gksu-run-helper

Does it do this on the el5 version? because that's just about the only
way this could be considered a bug. Something behaving incorrectly on
el6 when it's built for el5 isn't exactly shocking.