[users] update latest dante 1.3.0-1 package failed

[Armin Tueting]

Hello,

updateing to the latest dante package fails with error message:-
Processing Dependency: ld-linux.so.2(GLIBC_PRIVATE) for package: dante

[Yury V. Zaytsev]

Post by Armin Tueting
Hello,
updateing to the latest dante package fails with error message:-
Processing Dependency: ld-linux.so.2(GLIBC_PRIVATE) for package: dante

I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

[Armin Tüting]

Post by Yury V. Zaytsev
I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

CentOS 5.6 x86_64

Regards,
Armin

[Armin Tüting]

Post by Yury V. Zaytsev
I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

CentOS 5.6 x86_64

Regards,
Armin

[Armin Tüting]

Post by Armin Tüting

Post by Yury V. Zaytsev
I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

CentOS 5.6 x86_64

Sorry, the issue exists with CentOS 5.6 i386 - I'll have two servers running.

[Yury V. Zaytsev]

Post by Armin Tüting

Post by Armin Tüting

Post by Yury V. Zaytsev
I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

CentOS 5.6 x86_64

Sorry, the issue exists with CentOS 5.6 i386 - I'll have two servers running.

Hi!

Do these test packages work for you?

http://rpm.zaytsev.net/test/

If yes, then I will commit the SPEC to the repository.

[Armin Tüting]

Post by Yury V. Zaytsev
Do these test packages work for you?
http://rpm.zaytsev.net/test/

rpm -Uvh http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
Retrieving http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
error: Failed dependencies:
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386
libminiupnpc.so.5 is needed by dante-1.3.1-1.el5.zyv.i386
dante = 1.2.3-1.el5.rf is needed by (installed) dante-server-1.2.3-1.el5.rf.i386

Post by Yury V. Zaytsev
If yes, then I will commit the SPEC to the repository.

Nop

[Dag Wieers]

Post by Yury V. Zaytsev
If yes, then I will commit the SPEC to the repository.

Nop

It's a problem I noticed myself, but haven't had the time to fix,
unfortunately. The solution is merging the patch that was used before.
Somehow I think the configure options fooled me once before, indicating
that this was already fixed. I guess not :-/

As soon as I find the time to look into I'll fix it.

[Yury V. Zaytsev]

Hi Dag,

Post by Dag Wieers
It's a problem I noticed myself, but haven't had the time to fix,
unfortunately. The solution is merging the patch that was used before.
Somehow I think the configure options fooled me once before, indicating
that this was already fixed. I guess not :-/

As it turns out, they are now checking whether the private symbols can
be exported and if yes, they use them. Otherwise, they use a manual
check which makes the second part of your patch redundant.

Post by Dag Wieers
As soon as I find the time to look into I'll fix it.

I have created a new patch and will commit it, if Armin reports back
that it works for him, but I believe that it should work. You can just
rebuild the package when I commit my changes and that's it.

[Yury V. Zaytsev]

Post by Yury V. Zaytsev

Post by Dag Wieers
As soon as I find the time to look into I'll fix it.

I have created a new patch and will commit it, if Armin reports back
that it works for him, but I believe that it should work. You can just
rebuild the package when I commit my changes and that's it.

Actually, I am ridiculously inattentive today :-(

You are right, there is a configure option now that allows one to turn
off the usage of the private symbols even if they are detected, so the
first part of the patch is now also unnecessary.

Anyway, this makes fixing the issue even more straightforward. Let me
just wait for the feedback from Armin and I'll commit the fix.

[Yury V. Zaytsev]

Post by Yury V. Zaytsev

Post by Dag Wieers
As soon as I find the time to look into I'll fix it.

I have created a new patch and will commit it, if Armin reports back
that it works for him, but I believe that it should work. You can just
rebuild the package when I commit my changes and that's it.

Actually, I am ridiculously inattentive today :-(

You are right, there is a configure option now that allows one to turn
off the usage of the private symbols even if they are detected, so the
first part of the patch is now also unnecessary.

Anyway, this makes fixing the issue even more straightforward. Let me
just wait for the feedback from Armin and I'll commit the fix.

[Yury V. Zaytsev]

Hi Dag,

Post by Dag Wieers
It's a problem I noticed myself, but haven't had the time to fix,
unfortunately. The solution is merging the patch that was used before.
Somehow I think the configure options fooled me once before, indicating
that this was already fixed. I guess not :-/

As it turns out, they are now checking whether the private symbols can
be exported and if yes, they use them. Otherwise, they use a manual
check which makes the second part of your patch redundant.

Post by Dag Wieers
As soon as I find the time to look into I'll fix it.

I have created a new patch and will commit it, if Armin reports back
that it works for him, but I believe that it should work. You can just
rebuild the package when I commit my changes and that's it.

[Yury V. Zaytsev]

Post by Armin Tüting

Post by Yury V. Zaytsev
Do these test packages work for you?
http://rpm.zaytsev.net/test/

rpm -Uvh http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
Retrieving http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386

Ok, sorry, this is my fault. I didn't investigate the issue thoroughly
enough. It turned out that this problem has already come up before, and
the issue is that dante tries to use GLIBC private symbols, which is
disallowed by policy on RHEL / Fedora.

A patch was created to address the issue, but at some point it got lost
and the problem thus surfaced again. I have now updated the packages,
could you please try another time?

Post by Armin Tüting
libminiupnpc.so.5 is needed by dante-1.3.1-1.el5.zyv.i386
dante = 1.2.3-1.el5.rf is needed by (installed) dante-server-1.2.3-1.el5.rf.i386

You should rather use yum localinstall, because otherwise the dependency
on miniupnpc will not be automatically resolved.

Also, the server needs a particular version of dante so you should be
upgrading both at the same time.

[Armin Tüting]

Post by Yury V. Zaytsev
A patch was created to address the issue, but at some point it got lost
and the problem thus surfaced again. I have now updated the packages,
could you please try another time?

yum localinstall --nogpgcheck dante-1.3.1-1.el5.zyv.i386.rpm dante-server-1.3.1-1.el5.zyv.i386.rpm
...
Examining dante-1.3.1-1.el5.zyv.i386.rpm: dante-1.3.1-1.el5.zyv.i386
Marking dante-1.3.1-1.el5.zyv.i386.rpm as an update to dante-1.2.3-1.el5.rf.i386
...
Examining dante-server-1.3.1-1.el5.zyv.i386.rpm: dante-server-1.3.1-1.el5.zyv.i386
Marking dante-server-1.3.1-1.el5.zyv.i386.rpm as an update to dante-server-1.2.3-1.el5.rf.i386
...
Complete!

The package update fails when the option "--nogpgcheck" isn't used - Package dante-server-1.3.1-1.el5.zyv.i386.rpm is not signed.

[Yury V. Zaytsev]

Hi!

Post by Armin Tüting
Complete!

Thanks for checking out!

So, I presume it works for you? I have committed the changes and the
packages should become available in the repository soon.

Post by Armin Tüting
The package update fails when the option "--nogpgcheck" isn't used -
Package dante-server-1.3.1-1.el5.zyv.i386.rpm is not signed.

Right, I don't sign test packages that won't go into the repository.

[Jeff Johnson]

Post by Yury V. Zaytsev
Hi!

Post by Armin Tüting
Complete!

Thanks for checking out!
So, I presume it works for you? I have committed the changes and the
packages should become available in the repository soon.

Post by Armin Tüting
The package update fails when the option "--nogpgcheck" isn't used -
Package dante-server-1.3.1-1.el5.zyv.i386.rpm is not signed.

Right, I don't sign test packages that won't go into the repository.

There's a deep and fundamental flaw here that someone (not me) needs to
pay attention to.

This is the 2nd report of interactions between signature
checking and dependencies I'm aware of.

The previous issue fixed a signature failure by removing a Provides: dependency.

This issue is fixing a dependency issue by not checking signatures.

There should be _NO_ interaction between dependencies and signature/digest
verification.

The fact that there is (now multiple reports) an interaction
hints at a deeper (and probably fairly serious) flaw.

hth

73 de Jeff

[Yury V. Zaytsev]

Post by Jeff Johnson
There's a deep and fundamental flaw here that someone (not me) needs to
pay attention to.

Should be me then or yet someone else ...?

Post by Jeff Johnson
This is the 2nd report of interactions between signature
checking and dependencies I'm aware of.

[...]

I am unable to understand what you are talking about. I see no
interaction between Provides: and signature checking. Could you please
rephrase?

I didn't sign the test packages so of course Armin was unable to install
them via yum localinstall unless he would disable the signature check.

[Jeff Johnson]

Post by Yury V. Zaytsev

Post by Jeff Johnson
There's a deep and fundamental flaw here that someone (not me) needs to
pay attention to.

Should be me then or yet someone else ...?

All I know is "not me" (because not my code and not my packaging
and I don't have the time nor energy to explain why an integrity
check on all package metadata cannot be fixed by adding or deleting
information in the metadata.)

Either the metadata passes an integrity check or it doesn't.
There are no other solutions.

Post by Yury V. Zaytsev

Post by Jeff Johnson
This is the 2nd report of interactions between signature
checking and dependencies I'm aware of.

[...]
I am unable to understand what you are talking about. I see no
interaction between Provides: and signature checking. Could you please
rephrase?

Perhaps I'm confused ? there appear to be 2 problems in this thread.

The original report claimed
error: Failed dependencies:
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386

A later report claimed that adding --nogpgcheck "fixed".

That was the basis of my comment:
Adding --nogpgcheck cannot solve a missing dependency.

If in the interim you have rebuilt dante and forgotten to sign and
so the package doesn't install, well, that is exactly what is supposed
to happen.

Apologies for my confusion. The first problem is/was a serious flaw
in need of a proper fix, which is why I monitor.

I've missed the fact that you've already fixed dante and so
the root cause changed.

73 de Jeff

[Yury V. Zaytsev]

Post by Jeff Johnson
All I know is "not me" (because not my code and not my packaging
and I don't have the time nor energy to explain why an integrity
check on all package metadata cannot be fixed by adding or deleting
information in the metadata.)

Ok, I see.

Post by Jeff Johnson
Perhaps I'm confused ? there appear to be 2 problems in this thread.

I think this is indeed the case.

Post by Jeff Johnson
The original report claimed
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386

Yes, the problem was that the software was indeed using private glibc
symbols, which is disallowed as per Fedora / RHEL policy.

I didn't realize that I included the wrong patch to fix it, so my first
stab at it was ineffective. Later on, Dag hinted me of another way to
correct it and get rid of this dependency altogether, which I
implemented and rebuilt the packages.

Post by Jeff Johnson
A later report claimed that adding --nogpgcheck "fixed".

Yes, this problem surfaced, because I intentionally do not sign test
packages, and while Armin was initially using rpm -Uvh (which didn't
enforce a signature check) I asked him to do yum localinstall instead
(to pull in *other* dependencies, most notably libminiupnpc).

In this case, of course, he also had to use --nogpgcheck explicitly to
get the packages installed, because they were not signed.

Post by Jeff Johnson
Adding --nogpgcheck cannot solve a missing dependency.

True, but it was me who solved the missing dependency in the mean time,
which is, I guess, the basis for confusion.

Thanks for the clarification!

[Yury V. Zaytsev]

Post by Jeff Johnson
All I know is "not me" (because not my code and not my packaging
and I don't have the time nor energy to explain why an integrity
check on all package metadata cannot be fixed by adding or deleting
information in the metadata.)

Ok, I see.

Post by Jeff Johnson
Perhaps I'm confused ? there appear to be 2 problems in this thread.

I think this is indeed the case.

Post by Jeff Johnson
The original report claimed
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386

Yes, the problem was that the software was indeed using private glibc
symbols, which is disallowed as per Fedora / RHEL policy.

I didn't realize that I included the wrong patch to fix it, so my first
stab at it was ineffective. Later on, Dag hinted me of another way to
correct it and get rid of this dependency altogether, which I
implemented and rebuilt the packages.

Post by Jeff Johnson
A later report claimed that adding --nogpgcheck "fixed".

Yes, this problem surfaced, because I intentionally do not sign test
packages, and while Armin was initially using rpm -Uvh (which didn't
enforce a signature check) I asked him to do yum localinstall instead
(to pull in *other* dependencies, most notably libminiupnpc).

In this case, of course, he also had to use --nogpgcheck explicitly to
get the packages installed, because they were not signed.

Post by Jeff Johnson
Adding --nogpgcheck cannot solve a missing dependency.

True, but it was me who solved the missing dependency in the mean time,
which is, I guess, the basis for confusion.

Thanks for the clarification!

[Jeff Johnson]

Post by Yury V. Zaytsev

Post by Jeff Johnson
There's a deep and fundamental flaw here that someone (not me) needs to
pay attention to.

Should be me then or yet someone else ...?

All I know is "not me" (because not my code and not my packaging
and I don't have the time nor energy to explain why an integrity
check on all package metadata cannot be fixed by adding or deleting
information in the metadata.)

Either the metadata passes an integrity check or it doesn't.
There are no other solutions.

Post by Yury V. Zaytsev

Post by Jeff Johnson
This is the 2nd report of interactions between signature
checking and dependencies I'm aware of.

[...]
I am unable to understand what you are talking about. I see no
interaction between Provides: and signature checking. Could you please
rephrase?

Perhaps I'm confused ? there appear to be 2 problems in this thread.

The original report claimed
error: Failed dependencies:
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386

A later report claimed that adding --nogpgcheck "fixed".

That was the basis of my comment:
Adding --nogpgcheck cannot solve a missing dependency.

If in the interim you have rebuilt dante and forgotten to sign and
so the package doesn't install, well, that is exactly what is supposed
to happen.

Apologies for my confusion. The first problem is/was a serious flaw
in need of a proper fix, which is why I monitor.

I've missed the fact that you've already fixed dante and so
the root cause changed.

73 de Jeff

[Yury V. Zaytsev]

Post by Jeff Johnson
There's a deep and fundamental flaw here that someone (not me) needs to
pay attention to.

Should be me then or yet someone else ...?

Post by Jeff Johnson
This is the 2nd report of interactions between signature
checking and dependencies I'm aware of.

[...]

I am unable to understand what you are talking about. I see no
interaction between Provides: and signature checking. Could you please
rephrase?

I didn't sign the test packages so of course Armin was unable to install
them via yum localinstall unless he would disable the signature check.

[Jeff Johnson]

Post by Yury V. Zaytsev
Hi!

Post by Armin Tüting
Complete!

Thanks for checking out!
So, I presume it works for you? I have committed the changes and the
packages should become available in the repository soon.

Post by Armin Tüting
The package update fails when the option "--nogpgcheck" isn't used -
Package dante-server-1.3.1-1.el5.zyv.i386.rpm is not signed.

Right, I don't sign test packages that won't go into the repository.

There's a deep and fundamental flaw here that someone (not me) needs to
pay attention to.

This is the 2nd report of interactions between signature
checking and dependencies I'm aware of.

The previous issue fixed a signature failure by removing a Provides: dependency.

This issue is fixing a dependency issue by not checking signatures.

There should be _NO_ interaction between dependencies and signature/digest
verification.

The fact that there is (now multiple reports) an interaction
hints at a deeper (and probably fairly serious) flaw.

hth

73 de Jeff

[Yury V. Zaytsev]

Hi!

Post by Armin Tüting
Complete!

Thanks for checking out!

So, I presume it works for you? I have committed the changes and the
packages should become available in the repository soon.

Post by Armin Tüting
The package update fails when the option "--nogpgcheck" isn't used -
Package dante-server-1.3.1-1.el5.zyv.i386.rpm is not signed.

Right, I don't sign test packages that won't go into the repository.

[Armin Tüting]

Post by Yury V. Zaytsev
A patch was created to address the issue, but at some point it got lost
and the problem thus surfaced again. I have now updated the packages,
could you please try another time?

yum localinstall --nogpgcheck dante-1.3.1-1.el5.zyv.i386.rpm dante-server-1.3.1-1.el5.zyv.i386.rpm
...
Examining dante-1.3.1-1.el5.zyv.i386.rpm: dante-1.3.1-1.el5.zyv.i386
Marking dante-1.3.1-1.el5.zyv.i386.rpm as an update to dante-1.2.3-1.el5.rf.i386
...
Examining dante-server-1.3.1-1.el5.zyv.i386.rpm: dante-server-1.3.1-1.el5.zyv.i386
Marking dante-server-1.3.1-1.el5.zyv.i386.rpm as an update to dante-server-1.2.3-1.el5.rf.i386
...
Complete!

The package update fails when the option "--nogpgcheck" isn't used - Package dante-server-1.3.1-1.el5.zyv.i386.rpm is not signed.

[Dag Wieers]

Post by Yury V. Zaytsev
If yes, then I will commit the SPEC to the repository.

Nop

It's a problem I noticed myself, but haven't had the time to fix,
unfortunately. The solution is merging the patch that was used before.
Somehow I think the configure options fooled me once before, indicating
that this was already fixed. I guess not :-/

As soon as I find the time to look into I'll fix it.

[Yury V. Zaytsev]

Post by Armin Tüting

Post by Yury V. Zaytsev
Do these test packages work for you?
http://rpm.zaytsev.net/test/

rpm -Uvh http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
Retrieving http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386

Ok, sorry, this is my fault. I didn't investigate the issue thoroughly
enough. It turned out that this problem has already come up before, and
the issue is that dante tries to use GLIBC private symbols, which is
disallowed by policy on RHEL / Fedora.

A patch was created to address the issue, but at some point it got lost
and the problem thus surfaced again. I have now updated the packages,
could you please try another time?

Post by Armin Tüting
libminiupnpc.so.5 is needed by dante-1.3.1-1.el5.zyv.i386
dante = 1.2.3-1.el5.rf is needed by (installed) dante-server-1.2.3-1.el5.rf.i386

You should rather use yum localinstall, because otherwise the dependency
on miniupnpc will not be automatically resolved.

Also, the server needs a particular version of dante so you should be
upgrading both at the same time.

[Armin Tüting]

Post by Yury V. Zaytsev
Do these test packages work for you?
http://rpm.zaytsev.net/test/

rpm -Uvh http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
Retrieving http://rpm.zaytsev.net/test/dante-1.3.1-1.el5.zyv.i386.rpm
error: Failed dependencies:
ld-linux.so.2(GLIBC_PRIVATE) is needed by dante-1.3.1-1.el5.zyv.i386
libminiupnpc.so.5 is needed by dante-1.3.1-1.el5.zyv.i386
dante = 1.2.3-1.el5.rf is needed by (installed) dante-server-1.2.3-1.el5.rf.i386

Post by Yury V. Zaytsev
If yes, then I will commit the SPEC to the repository.

Nop

[Yury V. Zaytsev]

Post by Armin Tüting

Post by Armin Tüting

Post by Yury V. Zaytsev
I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

CentOS 5.6 x86_64

Sorry, the issue exists with CentOS 5.6 i386 - I'll have two servers running.

Hi!

Do these test packages work for you?

http://rpm.zaytsev.net/test/

If yes, then I will commit the SPEC to the repository.

[Armin Tueting]

Hello,

updateing to the latest dante package fails with error message:-
Processing Dependency: ld-linux.so.2(GLIBC_PRIVATE) for package: dante

[Yury V. Zaytsev]

Post by Armin Tueting
Hello,
updateing to the latest dante package fails with error message:-
Processing Dependency: ld-linux.so.2(GLIBC_PRIVATE) for package: dante

I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

[Armin Tüting]

Post by Armin Tüting

Post by Yury V. Zaytsev
I guess this could be a matter of a re-build that is needed, which
OS/ARCH is that?

CentOS 5.6 x86_64

Sorry, the issue exists with CentOS 5.6 i386 - I'll have two servers running.