11:28 p.m.
Has anyone else seen a problem with nemiver i386 package not being available?
There is an update in x86_64, and the matching version is actually present on
the mirror for i386, but its not being shown as available through yum. This was
causing updates to fail even with skip-broken, so I had to --exclude it.
Both packages are there:
http://limestone.uoregon.edu/ftp/fedora/development/x86_64/os/Packages/ne...
http://limestone.uoregon.edu/ftp/fedora/development/i386/os/Packages/nemi...
But only x86_64 tries to update.
10:05:03 |lordmorgul.durthangnix:0| |17 files:11M@~| |0 jobs|
- yum list nemiver.x86_64 nemiver.i386
Loaded plugins: basearchonly, fastestmirror, fedorakmod, priorities, security,
: versionlock
Loading mirror speeds from cached hostfile
* livna-development: mirrors.tummy.com
* livna-development-debuginfo: mirrors.tummy.com
* rawhide: limestone.uoregon.edu
* upstart-debuginfo: notting.fedorapeople.org
* upstart: notting.fedorapeople.org
Reading version lock configuration
Installed Packages
nemiver.x86_64 0.4.0-3.fc9 installed
nemiver.i386 0.4.0-3.fc9 installed
Available Packages
nemiver.x86_64 0.5.1-1.fc9 rawhide
10:05:22 |lordmorgul.durthangnix:0| |17 files:11M@~| |0 jobs|
- yum list updates
Loaded plugins: basearchonly, fastestmirror, fedorakmod, priorities, security,
: versionlock
Loading mirror speeds from cached hostfile
* livna-development: mirrors.tummy.com
* livna-development-debuginfo: mirrors.tummy.com
* rawhide: limestone.uoregon.edu
* upstart-debuginfo: notting.fedorapeople.org
* upstart: notting.fedorapeople.org
Skipping security plugin, no data
Reading version lock configuration
Updated Packages
evince.x86_64 2.22.0-3.fc9 rawhide
inkscape.x86_64 0.46-0.3.pre3.fc9 rawhide
kpathsea.x86_64 2007-28.fc9 rawhide
nemiver.x86_64 0.5.1-1.fc9 rawhide
poppler.x86_64 0.7.3-1.fc9 rawhide
poppler-glib.x86_64 0.7.3-1.fc9 rawhide
poppler-qt.x86_64 0.7.3-1.fc9 rawhide
poppler-qt4.x86_64 0.7.3-1.fc9 rawhide
texlive.x86_64 2007-28.fc9 rawhide
texlive-dvips.x86_64 2007-28.fc9 rawhide
texlive-latex.x86_64 2007-28.fc9 rawhide
texlive-utils.x86_64 2007-28.fc9 rawhide
10:07:39 |lordmorgul.durthangnix:0| |17 files:11M@~| |0 jobs|
- rpm -q nemiver.x86_64 nemiver.i386
nemiver-0.4.0-3.fc9.x86_64
nemiver-0.4.0-3.fc9.i386
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
12:37 a.m.
On Mon, 2008-03-24 at 21:28 -0700, Andrew Farris wrote:
Both packages are there:
http://limestone.uoregon.edu/ftp/fedora/development/x86_64/os/Packages/ne...
http://limestone.uoregon.edu/ftp/fedora/development/i386/os/Packages/nemi...
Actually, the package _isn't_ there. They should both be in the x86_64
tree (the i386 package simply duplicated into it). However, only the
nemiver-devel.i386 is present, the base nemiver.i386 package is not
there.
I can confirm that this also seems to happen with the
download.fedora.redhat.com (the mirrors' master, IIRC)
This seems at first glance to me like a bug in whatever created the
repo, since the devel subpackage contains an explicit dependency on the
main package of the same NVR. Hmm. :|
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
1:17 a.m.
Peter Gordon wrote:
Actually, the package _isn't_ there. They should both be in the
x86_64
tree (the i386 package simply duplicated into it). However, only the
nemiver-devel.i386 is present, the base nemiver.i386 package is not
there.
Oh yes, good point.
I can confirm that this also seems to happen with the
download.fedora.redhat.com (the mirrors' master, IIRC)
This seems at first glance to me like a bug in whatever created the
repo, since the devel subpackage contains an explicit dependency on the
main package of the same NVR. Hmm. :|
Well hopefully the repo compose does not do this again. I'll probably file a
bug if it isn't fixed tomorrow morning.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
6:40 a.m.
On Mon, 2008-03-24 at 22:37 -0700, Peter Gordon wrote:
Actually, the package _isn't_ there. They should both be in the
x86_64
tree (the i386 package simply duplicated into it). However, only the
nemiver-devel.i386 is present, the base nemiver.i386 package is not
there.
I can confirm that this also seems to happen with the
download.fedora.redhat.com (the mirrors' master, IIRC)
This seems at first glance to me like a bug in whatever created the
repo, since the devel subpackage contains an explicit dependency on the
main package of the same NVR. Hmm. :|
Actually it looks like a packaging bug. nemiver-devel-0.5.1-1.fc9.i386
has a require of nemiver-0.5.1-1.fc9, which nemiver-0.5.1-1.fc9.x86_64
satisfies. Usually a -devel package will have a .so symlink to an
actual library file that is in an arch specific package, which is how
the arch specific multilib package gets pulled into the repo.
What is it about the nemiver-devel.i386 that absolutely requires
nemiver.i386 instead of nemiver.x86_64?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:08 a.m.
On Tue, 25 Mar 2008 07:40:35 -0400, Jesse Keating wrote:
On Mon, 2008-03-24 at 22:37 -0700, Peter Gordon wrote:
> Actually, the package _isn't_ there. They should both be in the x86_64
> tree (the i386 package simply duplicated into it). However, only the
> nemiver-devel.i386 is present, the base nemiver.i386 package is not
> there.
>
> I can confirm that this also seems to happen with the
> download.fedora.redhat.com (the mirrors' master, IIRC)
>
> This seems at first glance to me like a bug in whatever created the
> repo, since the devel subpackage contains an explicit dependency on the
> main package of the same NVR. Hmm. :|
Actually it looks like a packaging bug. nemiver-devel-0.5.1-1.fc9.i386
has a require of nemiver-0.5.1-1.fc9, which nemiver-0.5.1-1.fc9.x86_64
satisfies. Usually a -devel package will have a .so symlink to an
actual library file that is in an arch specific package, which is how
the arch specific multilib package gets pulled into the repo.
The packaging suffers also from another bug.
libnemicommon.pc refers to libnemicommon.so in default search
path, but in the main package the library is in /usr/lib/nemiver/
Even if the search path were adjusted, linking to it with -lnemicommon
would fail later at run-time (and indeed, the nemiver executable sets:
0x0000000f (RPATH) Library rpath: [/usr/lib/nemiver]
What is it about the nemiver-devel.i386 that absolutely requires
nemiver.i386 instead of nemiver.x86_64?
The ability to link against 32-bit libs.
8:32 a.m.
On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
> What is it about the nemiver-devel.i386 that absolutely
requires
> nemiver.i386 instead of nemiver.x86_64?
The ability to link against 32-bit libs.
That means it should require those 32-bit libs. Ideally this requires
would happen automatically, through the use of a .so symlink to a
versioned arch specific shared object. However I gather that this isn't
necessarily C so there is no symlink. I hate that we would have to add
yet another file requires here.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
11:21 a.m.
On Tue, 25 Mar 2008 09:32:27 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
> > What is it about the nemiver-devel.i386 that absolutely requires
> > nemiver.i386 instead of nemiver.x86_64?
>
> The ability to link against 32-bit libs.
That means it should require those 32-bit libs. Ideally this requires
would happen automatically, through the use of a .so symlink to a
versioned arch specific shared object. However I gather that this isn't
necessarily C so there is no symlink. I hate that we would have to add
yet another file requires here.
It is C/C++, and there is no .so symlink because the library uses
a version-less SONAME and therefore uses a .so file name already.
12:05 p.m.
On Tue, 2008-03-25 at 17:21 +0100, Michael Schwendt wrote:
On Tue, 25 Mar 2008 09:32:27 -0400, Jesse Keating wrote:
> On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
> > > What is it about the nemiver-devel.i386 that absolutely requires
> > > nemiver.i386 instead of nemiver.x86_64?
> >
> > The ability to link against 32-bit libs.
>
> That means it should require those 32-bit libs. Ideally this requires
> would happen automatically, through the use of a .so symlink to a
> versioned arch specific shared object. However I gather that this isn't
> necessarily C so there is no symlink. I hate that we would have to add
> yet another file requires here.
It is C/C++, and there is no .so symlink because the library uses
a version-less SONAME and therefore uses a .so file name already.
Got any clever thoughts on how to resolve this, without adding manual
file deps?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
2:30 p.m.
On Tue, 25 Mar 2008 13:05:13 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 17:21 +0100, Michael Schwendt wrote:
> On Tue, 25 Mar 2008 09:32:27 -0400, Jesse Keating wrote:
>
> > On Tue, 2008-03-25 at 13:08 +0100, Michael Schwendt wrote:
> > > > What is it about the nemiver-devel.i386 that absolutely requires
> > > > nemiver.i386 instead of nemiver.x86_64?
> > >
> > > The ability to link against 32-bit libs.
> >
> > That means it should require those 32-bit libs. Ideally this requires
> > would happen automatically, through the use of a .so symlink to a
> > versioned arch specific shared object. However I gather that this isn't
> > necessarily C so there is no symlink. I hate that we would have to add
> > yet another file requires here.
>
> It is C/C++, and there is no .so symlink because the library uses
> a version-less SONAME and therefore uses a .so file name already.
Got any clever thoughts on how to resolve this, without adding manual
file deps?
Clever? Add a version to the soname after talking to upstream about it.
If they think the library interface is not stable enough, they can still
use .so.0 instead of just .so
Alternatively, ship a dummy executable in the -devel package, which causes
rpmbuild to create an automatic soname dep. ;)
2:41 p.m.
On Tue, 2008-03-25 at 20:30 +0100, Michael Schwendt wrote:
Clever? Add a version to the soname after talking to upstream about
it.
If they think the library interface is not stable enough, they can still
use .so.0 instead of just .so
Alternatively, ship a dummy executable in the -devel package, which causes
rpmbuild to create an automatic soname dep. ;)
Heh, ok, both of those went through my mind too, glad we're on the same
page.
Peter Gordon, can you take this issue to upstream? We really would
rather not see unversioned shared objects.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:06 p.m.
On Tue, 2008-03-25 at 07:40 -0400, Jesse Keating wrote:
Actually it looks like a packaging bug.
nemiver-devel-0.5.1-1.fc9.i386
has a require of nemiver-0.5.1-1.fc9, which nemiver-0.5.1-1.fc9.x86_64
satisfies. Usually a -devel package will have a .so symlink to an
actual library file that is in an arch specific package, which is how
the arch specific multilib package gets pulled into the repo.
Thanks, Jesse & Michael.
I looked into it a bit further and this does indeed seem to be a bug on
the package itself. In 0.4.0, the -devel properly held a symlink to the
original library, but because that was moved in the 0.5.x builds, that
symlink was also removed (and thus the -devel package contains only data
files: incude headers and the pkgconfig-foo).
What would be the best solution to resolve this? Should I add a symlink
in the -devel subpackage manually? (This would resolve to within the %
libdir/nemiver directory, too, which I think was one other bug that
needed a squashing.)
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
7:08 p.m.
On Tue, 2008-03-25 at 17:06 -0700, Peter Gordon wrote:
[...] data
files: incude headers and the pkgconfig-foo).
Should read: "include headers ..."
Sorry for the typo!
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
3:11 a.m.
On Tue, 25 Mar 2008 17:06:25 -0700, Peter Gordon wrote:
I looked into it a bit further and this does indeed seem to be a bug
on
the package itself. In 0.4.0, the -devel properly held a symlink to the
original library, but because that was moved in the 0.5.x builds, that
symlink was also removed (and thus the -devel package contains only data
files: incude headers and the pkgconfig-foo).
What would be the best solution to resolve this? Should I add a symlink
in the -devel subpackage manually? (This would resolve to within the %
libdir/nemiver directory, too, which I think was one other bug that
needed a squashing.)
Well, it would still require an rpath before linked programs would run
(and rpaths are fragile, because the library may move to a different
location). Because with a link like
%_libdir/libnemivercommon.so -> %_libdir/nemiver/libnemivercommon.so
you can -lnemivercommon at build-time, but at run-time the library is not
found as it is located outside default search path. Strictly speaking, the
package should not "Provides: libnemivercommon.so" either as long as the
lib is provided in a private path (but rpmbuild doesn't know that, and
hence you end up with automatic soname dependencies here, too).
4:55 a.m.
I think I finally figured this out.
I was able to patch the build scripts a bit to build the nemivercommon
shared library as a versioned DSO, and tweaked those same scripts to
install to $LIBDIR instead of $LIBDIR/nemiver, so now we have in the
main package:
/usr/lib64/libnemivercommon.so.0 -> libnemivercommon.so.0.0.0
/usr/lib64/libnemivercommon.so.0.0.0
And in the devel subpackage, the arch-specific, unversioned symlink is
properly created:
/usr/lib64/libnemivercommon.so -> libnemivercommon.so.0.0.0
The nemiver binary properly is linked to the versioned DSO
(libnemivercommon.so.0) so that works well, also.
I've just committed the update to CVS, and will let Koji churn through
the builds while I get some much-needed sleep. =)
Assuming no problems, I'll sync the version update to F-8 and F-7 soon,
too.
Thanks.
--
Peter Gordon (codergeek42)
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
5851
days inactive
5869
days old
13 comments
4 participants
participants (4)
-
Andrew Farris -
Jesse Keating -
Michael Schwendt -
Peter Gordon