Re: php-pear package build problem

2011-09-04 Thread TASAKA Mamoru 
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/05/2011 03:59 AM +9:00:
> Hello.
>
> I have couple of bugs with FBFS similar to [1]. At first glance it is trivial 
> - php-config doesn't found [2].
>
> But what interesting, it still there as was in Fedora 15:
> [pasha@vbox temp]$ repoquery --whatprovides '*/php-config'
> php-devel-0:5.3.6-2.fc15.i686
> [pasha@vbox temp]$ repoquery --disablerepo='*' --enablerepo='rawhide' 
> --whatprovides '*/php-config'
> php-devel-0:5.3.8-1.fc17.i686
>
> And php-devel BR is explicitly mentioned in spec as:
> BuildRequires: php-devel >= 5.1.0
>
> But what very interesting according to root.log [3] it wasn't pulled, and 
> even no error produced?
>
> What happened??
>
> 1 - https://bugzilla.redhat.com/show_bug.cgi?id=715709
> 2 - http://koji.fedoraproject.org/koji/getfile?taskID=3323691&name=build.log
> 3 - http://koji.fedoraproject.org/koji/getfile?taskID=3323691&name=root.log

2. (build.log) says
error: /builddir/build/SPECS/php-pecl-runkit.spec:33: parseExpressionBoolean 
returns -1

This means that there is something wrong (syntax error or so) with your spec 
file.
To investigate further actually seeing the used spec file is needed.

Regards,
Mamoru



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaned: vpnc

2011-09-04 Thread Christian Krause 
Hi David,

On 08/31/2011 09:37 AM, Woodhouse, David wrote:
> On Wed, 2011-08-31 at 02:42 +0200, Christian Krause wrote:

>> I have looked at the list of open bugs for vpnc and it looks like that
>> there are a couple of packaging issues, some problems with the
>> vpnc-script and some other issues which may require some upstream
>> help. 
> 
> Are there any problems with vpnc-script that *aren't* fixed by simply
> updating to the one in
> http://git.infradead.org/users/dwmw2/vpnc-scripts.git ?

I have looked at the git repository and I'm unsure about one change:

The commit:
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/ea98b094e8f75fcd696db81bc6c5160dc67b4e4f


seems to fix https://bugzilla.redhat.com/show_bug.cgi?id=693235
(negative MTU) in case "ip route ... " does not report the mtu.

However, at least on my systems, "ip route ..." does never return the
mtu in its output and so the script will always use the hard-coded
fallback value 1412 as MTU.

The proposed patch attached to the bug report (
https://bugzilla.redhat.com/attachment.cgi?id=515615 ) uses a different
approach:
It extracts the actual interface via "ip route" and retrieves the MTU
via "ip link show $interface".

What do you think about this patch?


Best regards,
Christian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bundle question

2011-09-04 Thread Jon Ciesla 

> Hello.
>
> I'm review jreen library and there found [1] very interesting issue -
> psi and kdenetwork bundle iris, jdns [2] and simplesasl.
>
> For example:
> $ find kdenetwork-4.6.5 psi-0.14 -iname simplesasl\*
> kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.h
> kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.cpp
> psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.h
> psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.cpp
>
> Should I fill bugs about it against both?
>
> iris (simplesasl its part) is psi [3] library, and as I understand
> released in it. So I think it may contain it. But how deal with
> kdenetwork?

Patch jreen to use system versions.

See:

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

for guidance.

> 1 https://bugzilla.redhat.com/show_bug.cgi?id=731456#c8
> 2 http://delta.affinix.com/jdns/
> 3 http://psi-im.org/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

php-pear package build problem

2011-09-04 Thread Pavel Alexeev (aka Pahan-Hubbitus) 

Hello.

I have couple of bugs with FBFS similar to [1]. At first glance it is 
trivial - php-config doesn't found [2].


But what interesting, it still there as was in Fedora 15:
[pasha@vbox temp]$ repoquery --whatprovides '*/php-config'
php-devel-0:5.3.6-2.fc15.i686
[pasha@vbox temp]$ repoquery --disablerepo='*' --enablerepo='rawhide' 
--whatprovides '*/php-config'

php-devel-0:5.3.8-1.fc17.i686

And php-devel BR is explicitly mentioned in spec as:
BuildRequires: php-devel >= 5.1.0

But what very interesting according to root.log [3] it wasn't pulled, 
and even no error produced?


What happened??

1 - https://bugzilla.redhat.com/show_bug.cgi?id=715709
2 - 
http://koji.fedoraproject.org/koji/getfile?taskID=3323691&name=build.log 

3 - 
http://koji.fedoraproject.org/koji/getfile?taskID=3323691&name=root.log 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20110903 changes

2011-09-04 Thread Kevin Fenzi 
On Sun, 4 Sep 2011 10:31:21 +0200
Thomas Spura  wrote:

> Some i686 updates make it to the broken deps for x86_64, others
> don't...
> 
> Why that?

This is multilib. Basically packages that have a -devel subpackage have
that devel subpackage and it's requirements (if available) shipped in
the 64bit tree. The theory is that this allows people to develop and
run 32bit applications if they need on 64bit machines. The 32bit
packages in the 64bit repo that don't show up in the report, don't have
broken deps. ;) 

You can see the exact logic used in the 'mash' project: 

http://git.fedorahosted.org/git/?p=mash;a=blob;f=mash/multilib.py;h=9ae98f0adef296451e0ceffa7589b985d20725af;hb=980e4863b241bcb4bd18e1a82f6256aa1d28b65a

If you are wanting to fix issues as a maintainer,
http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
may provide some ideas. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Non responsive maintainer : gouldwp

2011-09-04 Thread Remi Collet 
Hi,

It seems gouldwp is non-responsive.
User: gouldwp,
Name: None,
email: w...@gouldfamily.org,
Creation: 2008-01-19,
Status: active
Approved Groups: cla_fpca cla_fedora fedorabugs cla_done packager


Bug (open 2011-08-06, ping 2011-08-25)
https://bugzilla.redhat.com/show_bug.cgi?id=728665

Direct request for co-maintainer via pkgdb without answer

Direct email without answer

Last build from gouldwp : 2009-11-09
http://koji.fedoraproject.org/koji/userinfo?userID=591

Without response, I like to take ownership on perl-Net-NBName
(required by another package I own)

Remi.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd

2011-09-04 Thread Reindl Harald 


Am 04.09.2011 02:20, schrieb Tom Lane:
> Kevin Kofler  writes:
>> Stephen John Smoogen wrote:
>>> On Sat, Sep 3, 2011 at 07:46, Reindl Harald 
>>> wrote:
 How many releases will this dirty mix of systemd/sysvinit(lsb in the
 distribution exist until the OS can be called as "clean" like before
 F15?
> 
>>> As many as it takes to get it done.
> 
>> We need to get a provenpackager to just poke through all the packages and 
>> fix them instead of waiting for the maintainers.
> 
> That doesn't seem to me to be a very good idea.  Having recently worked
> on the systemd migrations for mysql and postgresql, I know that there
> are frequently package-specific considerations that are not obvious to
> the casual onlooker.  Having somebody who thinks he knows what he's
> doing hack all the unfixed services is likely to make things worse not
> better.
> 
>> We should also remove this stupid "cannot migrate to a native systemd unit 
>> in an update" rule. If a native systemd unit file gets written, it should be 
>> pushed out to F16 and F15 immediately.
> 
> That policy annoyed me at first but I've seen the wisdom of it.  Doing
> something like that will very likely break users' customizations of
> their service setups, which is not something you want to have happen
> after a routine "yum update"

this wisdom is a little too late and should have been there before
forcing the switch - no as we have systemd if we want it or not
it must not take years to get all services converted

hopefully the next time a big change like i fear wayland will be
is introduced this wisdom comes BEFORE release

give out a notice or somewaht else if a package brings a new
systemd-service but stop tell us we have to wait until F17 or F18
to get the state which should have been for F15








signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-16 Branched report: 20110904 changes

2011-09-04 Thread Branched Report 
Compose started at Sun Sep  4 13:15:51 UTC 2011

Broken deps for x86_64
--
389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires 
libnetsnmpagent.so.25()(64bit)
389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires 
libnetsnmpmibs.so.25()(64bit)
389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit)
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
airrac-0.1.0-2.fc16.i686 requires libstdair.so.0.36
airrac-0.1.0-2.fc16.i686 requires libstdairuicl.so.0.36
airrac-0.1.0-2.fc16.x86_64 requires libstdairuicl.so.0.36()(64bit)
airrac-0.1.0-2.fc16.x86_64 requires libstdair.so.0.36()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libecal-1.2.so.9()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit)
almanah-0.7.3-12.fc16.x86_64 requires libebook-1.2.so.11()(64bit)
1:anerley-0.3.0-1.fc16.i686 requires libedataserver-1.2.so.14
1:anerley-0.3.0-1.fc16.i686 requires libebook-1.2.so.11
1:anerley-0.3.0-1.fc16.x86_64 requires libebook-1.2.so.11()(64bit)
1:anerley-0.3.0-1.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit)
assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit)
awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires 
libgnome-menu.so.2()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools
coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py
comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet
deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires 
libedataserver-1.2.so.14()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave
emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit)
emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit)
evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires 
libedataserver-1.2.so.14()(64bit)
evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires 
libebook-1.2.so.11()(64bit)
exaile-0.3.2.1-1.fc16.noarch requires hal
fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5
fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4
fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit)
fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libboost_signals-mt.so.1.46.1()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libboost_thread-mt.so.1.46.1()(64bit)
fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires 
libgeos-3.2.1.so()(64bit)
ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires 
libedataserver-1.2.so.14()(64bit)
ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires 
libebook-1.2.so.11()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit)
fldigi-3.21.7-1.fc16.x86_64 requires libfl

Re: Review swap request: moonscript, lua-alt-getopt, lua-inotify

2011-09-04 Thread Pavel Alexeev (aka Pahan-Hubbitus) 
I'm ready to swap on any from my packages awaiting review.
I going to reviewing now.

24.08.2011 00:58, Michel Alexandre Salim wrote:
> Dear contributors,
>
> Is anyone interested in some review swaps? These packages should be
> quite straightforward:
>
> moonscript -- moonscript is to Lua what coffeescript is to Javascript
> (improved syntax, lots of convenience features -- from
> for-comprehensions to OOP)
>
>You need to recompile lua-filesystem and lua-lpeg from Rawhide, but
> that should be straightforward. They'll be built for F-16 as well, but
> we're
>probably not going to build them for F-15 unless requested
>
>https://bugzilla.redhat.com/show_bug.cgi?id=731003
>
> lua-alt-getopt -- an alternative getopt module, modeled after BSD's
> getopt_long (needed by moonscript)
>https://bugzilla.redhat.com/show_bug.cgi?id=731000
>
> lua-inotify -- inotify bindings for Lua (optional requirement for moonscript)
>https://bugzilla.redhat.com/show_bug.cgi?id=731001
>
> Thanks,
>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd

2011-09-04 Thread Marcos Mello 
Reindl Harald  thelounge.net> writes:

> 
> the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd
> is at 0% - why will F16 released WITHOUT making the system clean which
> should have been done for F15
> 
> How many releases will this dirty mix of systemd/sysvinit(lsb in the
> distribution exist until the OS can be called as "clean" like before
> F15?
> 
> 
> 

The following page appears to have an updated status:

https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: emacs and libotf.so.0

2011-09-04 Thread Amit Saha 
Hi,

On 09/05/2011 12:59 AM, Denis Arnaud wrote:
> Hello,
>
> I just came onto a tricky dependency issue, and thought it could be of
> interest to the list.
> emacs requires libotf.so.0, which is the library handling Open Type
> Fonts (OTF), provided by the libotf package.
> Well, fine enough. But libotf.so.0 is also provided by the OpenMPI
> package (not in /usr/lib, but rather in /usr/lib/openmpi/lib).
>
> So, RPM/Yum is misleaded when installing, whenever OpenMPI has
> installed. It results in a cryptic "emacs: error while loading shared
> libraries: libotf.so.0: cannot open shared object file: No such file or
> directory" error message (I put it here in plain, so that it can be
> indexed by our favourite Web crawlers), or so, when trying to launch
> emacs from a terminal.
>
> I see no clean solution, as both packages (libotf, openmpi) have some
> legitimity to name that libotf.so library like that. And it seems
> impracticable to have RPM handles full paths rather than just library names.
>
> I leave the floor open for debates :)

I have faced this issue before, and have also raised this on this list, 
Pls see [1] for the mail thread.


[1] http://lists.fedoraproject.org/pipermail/devel/2011-July/153812.html

-Amit

-- 
http://echorand.me
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

emacs and libotf.so.0

2011-09-04 Thread Denis Arnaud 
Hello,

I just came onto a tricky dependency issue, and thought it could be of
interest to the list.
emacs requires libotf.so.0, which is the library handling Open Type Fonts
(OTF), provided by the libotf package.
Well, fine enough. But libotf.so.0 is also provided by the OpenMPI package
(not in /usr/lib, but rather in /usr/lib/openmpi/lib).

So, RPM/Yum is misleaded when installing, whenever OpenMPI has installed. It
results in a cryptic "emacs: error while loading shared libraries:
libotf.so.0: cannot open shared object file: No such file or directory"
error message (I put it here in plain, so that it can be indexed by our
favourite Web crawlers), or so, when trying to launch emacs from a terminal.

I see no clean solution, as both packages (libotf, openmpi) have some
legitimity to name that libotf.so library like that. And it seems
impracticable to have RPM handles full paths rather than just library names.

I leave the floor open for debates :)

D
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20110904 changes

2011-09-04 Thread Rawhide Report 
Compose started at Sun Sep  4 08:15:02 UTC 2011

Broken deps for x86_64
--
FlightGear-2.0.0-6.fc16.x86_64 requires libosgViewer.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgUtil.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgSim.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgGA.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgFX.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit)
FlightGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit)
SimGear-2.0.0-6.fc16.i686 requires libosgParticle.so.74
SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74
SimGear-2.0.0-6.fc16.i686 requires libosg.so.74
SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11
SimGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit)
SimGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit)
SimGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit)
SimGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit)
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit)
awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires 
libgnome-menu.so.2()(64bit)
bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit)
caribou-0.3.5-1.fc16.i686 requires libgee.so.2
caribou-0.3.5-1.fc16.x86_64 requires libgee.so.2()(64bit)
1:cheese-3.0.2-2.fc16.x86_64 requires libgee.so.2()(64bit)
1:cheese-libs-3.0.2-2.fc16.i686 requires libgee.so.2
1:cheese-libs-3.0.2-2.fc16.x86_64 requires libgee.so.2()(64bit)
cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools
coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit)
coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit)
comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py
comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires 
libedataserver-1.2.so.14()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit)
deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet
dh-make-0.55-3.fc15.noarch requires debhelper
ease-0.4-7.fc17.i686 requires libgee.so.2
ease-0.4-7.fc17.x86_64 requires libgee.so.2()(64bit)
ease-devel-0.4-7.fc17.i686 requires pkgconfig(gee-1.0)
ease-devel-0.4-7.fc17.x86_64 requires pkgconfig(gee-1.0)
ekiga-3.3.1-3.fc17.x86_64 requires libpt.so.2.10.1()(64bit)
ekiga-3.3.1-3.fc17.x86_64 requires libcamel-1.2.so.28()(64bit)
emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave
emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit)
emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit)
empathy-3.1.90.1-2.fc17.x86_64 requires libgee.so.2()(64bit)
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2
fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2
fawkes-core-0.4.2-4.fc16.i68

Re: What is "Error: Protected multilib versions: ..."?

2011-09-04 Thread Sam Varshavchik 

Richard W.M. Jones writes:


glibc-common-2.14.90-4.x86_64
glibc-common-2.14.90-1.x86_64


This means that rpm/yum aborted in a middle of a upgrade.

You should clean this up using rpm -e glibc-common-2.14.90-1.x86_64



pgpf62s8f7GEk.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What is "Error: Protected multilib versions: ..."?

2011-09-04 Thread Niels de Vos 
And now to the list as well...
On 4 Sep 2011 10:01, "Niels de Vos"  wrote:
> On 4 Sep 2011 09:45, "Richard W.M. Jones"  wrote:
>>
>> I get this error all the time, but I can't find a coherent explanation
>> for what it means.
>>
>> What is the precise meaning of the "protected multilib versions" error?
>>
>> # yum install /lib/ld-linux.so.2
>> [...]
>> Error: Protected multilib versions: glibc-2.14.90-4.i686 !=
> glibc-2.14.90-1.x86_64
>>
>> # yum install /lib/ld-linux.so.2 glibc-2.14.90-4.x86_64
>> Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
>> Setting up Install Process
>> Package glibc-2.14.90-4.x86_64 already installed and latest version
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package glibc.i686 0:2.14.90-4 will be installed
>> --> Processing Dependency: libfreebl3.so for package:
glibc-2.14.90-4.i686
>> --> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package:
> glibc-2.14.90-4.i686
>> --> Running transaction check
>> ---> Package nss-softokn-freebl.i686 0:3.12.10-4.fc16 will be installed
>> --> Finished Dependency Resolution
>> Error: Protected multilib versions: glibc-2.14.90-4.i686 !=
> glibc-2.14.90-1.x86_64
>>
>> # yum install glibc-2.14.90-4.x86_64
>> Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
>> Setting up Install Process
>> Package glibc-2.14.90-4.x86_64 already installed and latest version
>> Nothing to do
>>
>> Bonus question. How come rpm/yum has allowed me to install multiple
>> different versions of glibc? (I have never knowingly forced any
>> installation on this machine).
>>
>> # rpm -qa | grep glibc
>> glibc-utils-2.14.90-4.x86_64
>> glibc-2.14.90-1.x86_64
>> glibc-headers-2.14.90-4.x86_64
>> glibc-debuginfo-common-2.14.90-4.x86_64
>> glibc-2.14.90-4.x86_64
>> glibc-static-2.14.90-4.x86_64
>> glibc-debuginfo-2.14.90-4.x86_64
>> glibc-devel-2.14.90-4.x86_64
>> glibc-debuginfo-common-2.14-2.x86_64
>> glibc-common-2.14.90-4.x86_64
>> glibc-common-2.14.90-1.x86_64
>
> It seems that you have 2x glibc.x86_64, not a 32-bit one. Likely some
> previous update was interrupted and never finished?
yum-complete-transaction
> or similar might be able to help you here.
>
> Hth,
> Niels
>
>>
>> Rich.
>>
>> --
>> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
>> libguestfs lets you edit virtual machines. Supports shell scripting,
>> bindings from many languages. http://libguestfs.org
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

What is "Error: Protected multilib versions: ..."?

2011-09-04 Thread Richard W.M. Jones 
I get this error all the time, but I can't find a coherent explanation
for what it means.

What is the precise meaning of the "protected multilib versions" error?

# yum install /lib/ld-linux.so.2
[...]
Error: Protected multilib versions: glibc-2.14.90-4.i686 != 
glibc-2.14.90-1.x86_64

# yum install /lib/ld-linux.so.2 glibc-2.14.90-4.x86_64
Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
Setting up Install Process
Package glibc-2.14.90-4.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package glibc.i686 0:2.14.90-4 will be installed
--> Processing Dependency: libfreebl3.so for package: glibc-2.14.90-4.i686
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: 
glibc-2.14.90-4.i686
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.12.10-4.fc16 will be installed
--> Finished Dependency Resolution
Error: Protected multilib versions: glibc-2.14.90-4.i686 != 
glibc-2.14.90-1.x86_64

# yum install glibc-2.14.90-4.x86_64
Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
Setting up Install Process
Package glibc-2.14.90-4.x86_64 already installed and latest version
Nothing to do

Bonus question.  How come rpm/yum has allowed me to install multiple
different versions of glibc?  (I have never knowingly forced any
installation on this machine).

# rpm -qa | grep glibc
glibc-utils-2.14.90-4.x86_64
glibc-2.14.90-1.x86_64
glibc-headers-2.14.90-4.x86_64
glibc-debuginfo-common-2.14.90-4.x86_64
glibc-2.14.90-4.x86_64
glibc-static-2.14.90-4.x86_64
glibc-debuginfo-2.14.90-4.x86_64
glibc-devel-2.14.90-4.x86_64
glibc-debuginfo-common-2.14-2.x86_64
glibc-common-2.14.90-4.x86_64
glibc-common-2.14.90-1.x86_64

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20110903 changes

2011-09-04 Thread Thomas Spura 
On Sat, 3 Sep 2011 12:37:37 +
Rawhide Report wrote:
> Broken deps for x86_64
> --
>   FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgViewer.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgUtil.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgText.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgSim.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgParticle.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgGA.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgFX.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosgDB.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libosg.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires
> libOpenThreads.so.11()(64bit) SimGear-2.0.0-6.fc16.i686 requires
> libosgParticle.so.74 SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74
>   SimGear-2.0.0-6.fc16.i686 requires libosg.so.74
>   SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11
>   SimGear-2.0.0-6.fc16.x86_64 requires
> libosgParticle.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires
> libosgDB.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires
> libosg.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires
> libOpenThreads.so.11()(64bit)

Some i686 updates make it to the broken deps for x86_64, others don't...

Why that?

Tom
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel