Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

[Bruno Wolff III]

On Sun, Nov 20, 2011 at 11:16:32 -0600,
  Bruno Wolff III  wrote:
> 
> I don't think it is directly related. It is odd that the include is getting
> flagged rather than an actual use. That could be a boost - gcc interaction.

I noticed that adding some extra includes that were used in wesnoth
source files that used BOOST_FOREACH without a problem fixed the issue
in one (that's all I tried so far) source file that did have the problem.
I don't know if those includes included some other boost include file
or if they defined something used without definition in the problem source
files and for some reason the error doesn't show up for 1.47.

It's getting too late for me to do more now.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] 2011-11-21 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2011-11-22
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

This is a reminder of the upcoming QA meeting.  Please add any topic
suggestions to the meeting wiki page:
https://fedoraproject.org/wiki/QA/Meetings/2021

The current proposed agenda is include below.  If no topics beyond the
standard "Previous meeting follow-up" and "AutoQA update" topics are
present or proposed, the meeting will be canceled.

== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. FUDCon NA hackfest planning
3. Fedora 17 Test Day planning
4. Upcoming QA events
5. AutoQA update 
6. Open Discussion - 
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Libs with applications

[Richard Vickery]

Does anybody know of anything I can try in Fedora 16 to get the other half
of my files from the Deja DUP backup?

Thanks,

Richard
On Nov 20, 2011 7:17 AM, "Steve Grubb"  wrote:

> Hello,
>
> I was curious how many library packages we have that also includes
> applications in
> them, so I wrote a small shell script:
>
> http://people.redhat.com/sgrubb/security/lib-bin-check
>
> On my F16 installation, it finds around 60 packages that are libraries with
> applications. I'd like to ask if anyone else sees this as a problem? For
> example, if a
> 32 bit library is installed, which application is left - the 64 or 32 bit
> one? And
> wouldn't that also pull in unnecessary dependencies?
>
> -Steve
> --
> 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

Re: Libs with applications

[John5342]

On Sun, Nov 20, 2011 at 19:33, Steve Grubb  wrote:
> On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
>> On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler  wrote:
>> > Steve Grubb wrote:
>> >> For example, if a 32 bit library is installed, which application is left
>> >> - the 64 or 32 bit one?
>> >
>> > If you install ONLY the 32-bit multilib, the 32-bit version.
>> > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
>> > (on all the platforms where 64-bit is preferred, which includes x86_64
>> > and now also ppc64).
>> > If you install ONLY the 64-bit package, the 64-bit version.
>>
>> Yeah which means there isn't really a problem here.
>
> Well, yeah there is the other problem of dependencies and getting a smaller 
> minimal
> install. For example, libnotify.
>
> # ldd /usr/bin/notify-send | wc -l
> 44
> # ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
> 12
>
> or how about libmsn
> # ldd /usr/bin/msntest | wc -l
> 20
> # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
> 9

I am the maintainer of libmsn. msntest probably could be moved to a
subpackage but it is a small program. All of the dependencies found by
ldd are already required by the applications using libmsn and msntest
is also very useful for checking if a problem connecting to msn is
caused by libmsn or the settings/applications using it. I would be
happy to move msntest into a subpackage if it is specifically
requested but under the current circumstances it would gain nothing
and just add an extra package to the repos.

-- 
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libcdio update coming to rawhide

[Adrian Reber]

On Tue, Nov 15, 2011 at 09:52:57AM +0100, Adrian Reber wrote:
> I will soon update libcdio to 0.83 in rawhide which requires a rebuild
> of following the packages:
> 
> audacious-plugins
> cdw
> gvfs
> kover
> libcddb
> oxine
> pragha
> pycdio
> qmmp
> xmms2
> 
> I will rebuild these packages if the corresponding maintainers do not
> object.

rebuilds done. Three with a failure:

gvfs http://koji.fedoraproject.org/koji/getfile?taskID=3527348&name=build.log
File not found: 
/builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/libexec/gvfsd-smb
File not found: 
/builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/libexec/gvfsd-smb-browse
File not found: 
/builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/share/gvfs/mounts/smb-browse.mount
File not found: 
/builddir/build/BUILDROOT/gvfs-1.11.0-4.fc17.x86_64/usr/share/gvfs/mounts/smb.mount

pragha   http://koji.fedoraproject.org/koji/taskinfo?taskID=3527953
current-playlist.c:2772:2: error: 'g_strncasecmp' is deprecated (declared at 
/usr/include/glib-2.0/glib/gstrfuncs.h:182) [-Werror=deprecated-declarations]

xmms2 http://koji.fedoraproject.org/koji/taskinfo?taskID=3528387
+ ./waf configure --prefix=/usr --libdir=/usr/lib64 --with-ruby-libdir= 
--with-perl-archdir=/usr/lib64/perl5 --with-pkgconfigdir=/usr/lib64/pkgconfig 
-j1
/usr/bin/env: python: Permission denied

all of those errors do not look libcdio related.

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

Re: Libs with applications

[Toshio Kuratomi]

On Sun, Nov 20, 2011 at 02:33:34PM -0500, Steve Grubb wrote:
> On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
> > On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler  
> > wrote:
> > > Steve Grubb wrote:
> > >> For example, if a 32 bit library is installed, which application is left
> > >> - the 64 or 32 bit one?
> > > 
> > > If you install ONLY the 32-bit multilib, the 32-bit version.
> > > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
> > > (on all the platforms where 64-bit is preferred, which includes x86_64
> > > and now also ppc64).
> > > If you install ONLY the 64-bit package, the 64-bit version.
> > 
> > Yeah which means there isn't really a problem here.
> 
> Well, yeah there is the other problem of dependencies and getting a smaller 
> minimal 
> install. For example, libnotify.
> 
> # ldd /usr/bin/notify-send | wc -l
> 44
> # ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
> 12
> 
> or how about libmsn
> # ldd /usr/bin/msntest | wc -l
> 20
> # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
> 9
> 
> I didn't test all of them, but the extra dependencies are unneeded.
> 
This is a different problem -- it should be solved with subpackages (putting
the applications in a separate subpackage from the library).  Opening bugs,
proposing patches, and exercising provenpackager abilities to resolve these
is generally appreciated.  Do be careful of the few packages where currently
packages assume the utilities are in the library package and not having them
there may subtly change desired behaviour.  (I think most of those will be
present on this page:
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets
)

-Toshio


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

Re: Libs with applications

[Steve Grubb]

On Sunday, November 20, 2011 02:14:09 PM drago01 wrote:
> On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler  wrote:
> > Steve Grubb wrote:
> >> For example, if a 32 bit library is installed, which application is left
> >> - the 64 or 32 bit one?
> > 
> > If you install ONLY the 32-bit multilib, the 32-bit version.
> > If you install BOTH the 64-bit and 32-bit packages, the 64-bit version
> > (on all the platforms where 64-bit is preferred, which includes x86_64
> > and now also ppc64).
> > If you install ONLY the 64-bit package, the 64-bit version.
> 
> Yeah which means there isn't really a problem here.

Well, yeah there is the other problem of dependencies and getting a smaller 
minimal 
install. For example, libnotify.

# ldd /usr/bin/notify-send | wc -l
44
# ldd /usr/lib64/libnotify.so.1.2.3 | wc -l
12

or how about libmsn
# ldd /usr/bin/msntest | wc -l
20
# ldd /usr/lib64/libmsn.so.0.3.0 | wc -l
9

I didn't test all of them, but the extra dependencies are unneeded.

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

Re: Libs with applications

[drago01]

On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler  wrote:
> Steve Grubb wrote:
>> For example, if a 32 bit library is installed, which application is left -
>> the 64 or 32 bit one?
>
> If you install ONLY the 32-bit multilib, the 32-bit version.
> If you install BOTH the 64-bit and 32-bit packages, the 64-bit version (on
> all the platforms where 64-bit is preferred, which includes x86_64 and now
> also ppc64).
> If you install ONLY the 64-bit package, the 64-bit version.

Yeah which means there isn't really a problem here.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Libs with applications

[Kevin Kofler]

Steve Grubb wrote:
> For example, if a 32 bit library is installed, which application is left -
> the 64 or 32 bit one?

If you install ONLY the 32-bit multilib, the 32-bit version.
If you install BOTH the 64-bit and 32-bit packages, the 64-bit version (on 
all the platforms where 64-bit is preferred, which includes x86_64 and now 
also ppc64).
If you install ONLY the 64-bit package, the 64-bit version.

Kevin Kofler

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

Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

[Bruno Wolff III]

On Sun, Nov 20, 2011 at 18:13:14 +0100,
  Denis Arnaud  wrote:
> 2011/11/20 Bruno Wolff III 
> 
> > Is there any expected semantic change for using BOOST_FOREACH?
> > I am having trouble rebuilding Wesnoth and get an error:
> > foreach.hpp:6:17: error: 'boost::BOOST_FOREACH' has not been declared
> > and foreach.hpp is:
> > #ifndef FOREACH_HPP
> > #define FOREACH_HPP
> >
> > #include 
> >
> > #define foreach BOOST_FOREACH
> >
> > #endif
> >
> 
> Could you check whether it is related to what happened last time (with
> Boost-1.47 on Fedora 16):
> http://lists.fedoraproject.org/pipermail/devel/2011-July/154705.html?

I don't think it is directly related. It is odd that the include is getting
flagged rather than an actual use. That could be a boost - gcc interaction.

I am only going to have limited time to look at this for the rest of the
day as I have some social stuff planned for today.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

[Denis Arnaud]

2011/11/20 Bruno Wolff III 

> Is there any expected semantic change for using BOOST_FOREACH?
> I am having trouble rebuilding Wesnoth and get an error:
> foreach.hpp:6:17: error: 'boost::BOOST_FOREACH' has not been declared
> and foreach.hpp is:
> #ifndef FOREACH_HPP
> #define FOREACH_HPP
>
> #include 
>
> #define foreach BOOST_FOREACH
>
> #endif
>

Could you check whether it is related to what happened last time (with
Boost-1.47 on Fedora 16):
http://lists.fedoraproject.org/pipermail/devel/2011-July/154705.html?

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

Re: FAS mails in Spanish?

[Toshio Kuratomi]

On Sun, Nov 20, 2011 at 12:22:50AM +0100, Martin Sourada wrote:
> Hi,
> 
> just a few minutes ago I received a mail from FAS (I've double checked
> that the info inside is correct and that it indeed came from fedora
> infra machines) informing me of a user requesting a membership in one
> of the groups I have sponsor status in. That wouldn't be surprising
> were it not for the text being in Spanish (or maybe Portugal, I don't
> speak these languages so I cannot tell them apart just by looking):
> 
> "El usuario Fedora @user-nick-and-mail-address@ ha
> solicitado membresia para @user-nick@ en el grupo @group-name@ y
> necesita un patrocinador.."
> 
> Now, the mail text is so simple I can understand the important part
> without the need to translate, but I certainly would prefer to receive
> such e-mails in English. Is there a chance I've set something wrong?
> I've checked I have locale set to en in FAS web...
> 
I fixed this prior to the recent fas release (made it use en -- a full fix
would use the sponsor's locale but that would potentially slow the code way
down so would need testing) but it seemed to late to push it into final.
I can try to get a release with this out sometime in the next month. If
someone else would like to do it, though, that could potentially speed
things up -- there's a few other releases of things that I've already
committed to that have priority over this and a few things that have equal
priority with it.

-Toshio


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

Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

[Bruno Wolff III]

Is there any expected semantic change for using BOOST_FOREACH?
I am having trouble rebuilding Wesnoth and get an error:
foreach.hpp:6:17: error: 'boost::BOOST_FOREACH' has not been declared
and foreach.hpp is:
#ifndef FOREACH_HPP
#define FOREACH_HPP

#include 

#define foreach BOOST_FOREACH

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

Re: boost soname bump

[Bruno Wolff III]

On Sun, Nov 20, 2011 at 08:05:34 -0600,
  Bruno Wolff III  wrote:
> It looks like there was a soname bump in boost yesterday. Boost affects
> enough stuff, that there really should have been a heads up message posted to
> the devel list about this.

It looks like there may have been a semantic change in how BOOST_FOREACH
is used. The upstream docs for it don't seem to have changed, but wesnoth
isn't rebuilding today. gcc hasn't changed since the last successful
build of Wesnoth, so it is likely to be due to the boost change.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide

[Denis Arnaud]

Hi,

according to the dedicated Bugzilla feature
request,
Boost  has just been
upgraded  (from
1.47.0  to
1.48.0)
on Rawhide (only). A ticket has been
openfor the release
engineering team to follow it.

Sorry, I have just been reminded/made aware that I should have posted that
message BEFORE pushing the build job to Koji. Well, it is now too late. At
least, that message is sent.

Regards

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

Re: Libs with applications

[Steve Grubb]

On Sunday, November 20, 2011 10:26:09 AM Steve Grubb wrote:
> On Sunday, November 20, 2011 10:20:51 AM Josh Boyer wrote:
> > On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb  wrote:
> > > Hello,
> > > 
> > > I was curious how many library packages we have that also includes
> > > applications in them, so I wrote a small shell script:
> > > 
> > > http://people.redhat.com/sgrubb/security/lib-bin-check
> > 
> > That just checks for a path.  It doesn't check if the "application" is
> > just a shell script, which is noarch.

New script posted. This dropped the list by about half.


> > > On my F16 installation, it finds around 60 packages that are libraries
> > > with applications. I'd like to ask if anyone else sees this as a
> > > problem? For example, if a 32 bit library is installed, which
> > > application is left - the 64 or 32 bit one? And wouldn't that also pull
> > > in unnecessary dependencies?
> > 
> > Again, not if it's noarch.  The list of packages you found with
> > problems would have been nice.

libreport-gtk-2.0.6.x86_64
libgnome-2.32.1.x86_64
libtar-1.2.11.x86_64
libreport-newt-2.0.6.x86_64
libgpg-error-1.10.x86_64
libEMF-1.0.4.x86_64
libnotify-0.7.4.x86_64
libselinux-2.1.6.x86_64
libiptcdata-1.0.4.x86_64
libsamplerate-0.1.8.x86_64
libkgeomap-2.3.0.x86_64
libgnomekbd-3.2.0.x86_64
libmsn-4.2.x86_64
libmx-1.4.0.x86_64
libreport-2.0.6.x86_64
libxslt-1.1.26.x86_64
libvirt-0.9.6.x86_64
libcanberra-0.28.x86_64
libtunepimp-0.5.3.x86_64
libidn-1.22.x86_64
libcanberra-gtk3-0.28.x86_64
libgnome-media-profiles-3.0.0.x86_64
libhangul-0.0.12.x86_64
libcroco-0.6.2.x86_64
libkactivities-6.1.x86_64
libieee1284-0.2.11.x86_64
libgpod-0.8.2.x86_64
libwnck3-3.2.1.x86_64

But this is just my system and not an everything install.

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

Re: strange koji behaviour

[Michael Schwendt]

On Sun, 20 Nov 2011 16:33:38 +0100, AR (Adrian) wrote:

> I just tried to rebuild kover and it failed during build with a strange
> error:
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=3527418&name=build.log&offset=-4000
> 
> The reason for this error is, however, a broken dependency.
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=3527418&name=root.log&offset=-4000
> 
> I thought if something failed during setup of the buildroot it shouldn't
> even start to build the package. This seems to be broken right now. The
> broken dependency is fixed and it builds now.
> 
> Same happened with audacious-plugins.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3527273

Sounds familiar:

  install of buildroot failed but install started
  https://fedorahosted.org/rel-eng/ticket/4791
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

strange koji behaviour

[Adrian Reber]

I just tried to rebuild kover and it failed during build with a strange
error:

http://koji.fedoraproject.org/koji/getfile?taskID=3527418&name=build.log&offset=-4000

The reason for this error is, however, a broken dependency.

http://koji.fedoraproject.org/koji/getfile?taskID=3527418&name=root.log&offset=-4000

I thought if something failed during setup of the buildroot it shouldn't
even start to build the package. This seems to be broken right now. The
broken dependency is fixed and it builds now.

Same happened with audacious-plugins.
http://koji.fedoraproject.org/koji/taskinfo?taskID=3527273

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

Re: boost soname bump

[Thomas Spura]

2011/11/20 Jussi Lehtola 

> Is the bump for real this time? I remember that some time ago the
> soname was bumped but then returned, so I had to do two unneeded builds.
> --
>

Unless there are too much problems with this yes:
https://fedoraproject.org/wiki/Features/F17Boost148
https://bugzilla.redhat.com/show_bug.cgi?id=754865

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

Re: Libs with applications

[Steve Grubb]

On Sunday, November 20, 2011 10:20:51 AM Josh Boyer wrote:
> On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb  wrote:
> > Hello,
> > 
> > I was curious how many library packages we have that also includes
> > applications in them, so I wrote a small shell script:
> > 
> > http://people.redhat.com/sgrubb/security/lib-bin-check
> 
> That just checks for a path.  It doesn't check if the "application" is
> just a shell script, which is noarch.

OK, simple fix. I'll post an improved script in a little while.


> > On my F16 installation, it finds around 60 packages that are libraries
> > with applications. I'd like to ask if anyone else sees this as a
> > problem? For example, if a 32 bit library is installed, which
> > application is left - the 64 or 32 bit one? And wouldn't that also pull
> > in unnecessary dependencies?
> 
> Again, not if it's noarch.  The list of packages you found with
> problems would have been nice.

After I fix the script, I'll post the packages.

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

Re: Libs with applications

[Josh Boyer]

On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb  wrote:
> Hello,
>
> I was curious how many library packages we have that also includes 
> applications in
> them, so I wrote a small shell script:
>
> http://people.redhat.com/sgrubb/security/lib-bin-check

That just checks for a path.  It doesn't check if the "application" is
just a shell script, which is noarch.

> On my F16 installation, it finds around 60 packages that are libraries with
> applications. I'd like to ask if anyone else sees this as a problem? For 
> example, if a
> 32 bit library is installed, which application is left - the 64 or 32 bit 
> one? And
> wouldn't that also pull in unnecessary dependencies?

Again, not if it's noarch.  The list of packages you found with
problems would have been nice.

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

Re: boost soname bump

[Jussi Lehtola]

On Sun, 20 Nov 2011 08:05:34 -0600
Bruno Wolff III  wrote:
> It looks like there was a soname bump in boost yesterday. Boost
> affects enough stuff, that there really should have been a heads up
> message posted to the devel list about this.

+1

Is the bump for real this time? I remember that some time ago the
soname was bumped but then returned, so I had to do two unneeded builds.
-- 
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Libs with applications

[Steve Grubb]

Hello,

I was curious how many library packages we have that also includes applications 
in 
them, so I wrote a small shell script:

http://people.redhat.com/sgrubb/security/lib-bin-check

On my F16 installation, it finds around 60 packages that are libraries with 
applications. I'd like to ask if anyone else sees this as a problem? For 
example, if a 
32 bit library is installed, which application is left - the 64 or 32 bit one? 
And 
wouldn't that also pull in unnecessary dependencies?

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

boost soname bump

[Bruno Wolff III]

It looks like there was a soname bump in boost yesterday. Boost affects
enough stuff, that there really should have been a heads up message posted to
the devel list about this.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?

[Michael Schwendt]

On Wed, 09 Nov 2011 10:42:10 -0500, TL (Tom) wrote:

> > On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote:
> >> I plan to provide the 1.2.x libpng shared library (and only the library,
> >> not its devel support files) in a libpng-compat subpackage for the time
> >> being.
> 
> > Any reason why the compat package ships the libpng-1.2.pc pkg-config
> > file?
> 
> Yeah: I tried it without first, and found that I couldn't rebuild
> anything.  There are boatloads of packages that have pkgconfig(libpng12)
> as an RPM-visible dependency, so if the compat package doesn't supply
> it, those packages won't install and you can't rebuild any of their
> dependencies.  I have no idea why it was considered a good thing for RPM
> to track this type of dependency, but it does.

It is fragile, unfortunately, but not bad. 

Automatic Provides/Requires for pkg-config interpackage dependencies are
helpful. Packagers have had problems getting the -devel dep-chains as
complete as necessary to not break the .pc file inter-dependencies.

However, one could say that you've injected a broken package into the
build-system by including a .pc file it in without including the
corresponding headers and library. A compat package is not supposed to
be a -devel package either (unless it is a special case of a compat -devel
package).

The fundamental problem with the automatic pkg-config provides is the
extra version in the .pc file name. Those extra versions are poor design,
a poor choice by the developers of the library's .pc file, because
pkg-config has means to query the internal version in the .pc file
instead.

With

  pkgconfig(libpng) = 1.2.46
  pkgconfig(libpng12) = 1.2.46

once libpng12.pc gets removed from the distribution, the dep-chains
break, of course.

As a temporary work-around, you could have provided that thing manually
in the libpng-devel upgrade instead of including the actual libpng12.pc
file:

  Provides: pkgconfig(libpng12) = %{version}-%{release}

Any configure script or .pc file using a hardcoded "libpng12" name
would fail to build, but that would be better IMO than offering an
incomplete broken compat package that confuses the buildroots.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel