Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
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
boost soname bump
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
Libs with applications
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
Re: boost soname bump
On Sun, 20 Nov 2011 08:05:34 -0600 Bruno Wolff III br...@wolff.to 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
Re: Libs with applications
On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb sgr...@redhat.com 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: Libs with applications
On Sunday, November 20, 2011 10:20:51 AM Josh Boyer wrote: On Sun, Nov 20, 2011 at 10:17 AM, Steve Grubb sgr...@redhat.com 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: boost soname bump
2011/11/20 Jussi Lehtola jussileht...@fedoraproject.org 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
strange koji behaviour
I just tried to rebuild kover and it failed during build with a strange error: http://koji.fedoraproject.org/koji/getfile?taskID=3527418name=build.logoffset=-4000 The reason for this error is, however, a broken dependency. http://koji.fedoraproject.org/koji/getfile?taskID=3527418name=root.logoffset=-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: strange koji behaviour
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=3527418name=build.logoffset=-4000 The reason for this error is, however, a broken dependency. http://koji.fedoraproject.org/koji/getfile?taskID=3527418name=root.logoffset=-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
Re: Libs with applications
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 sgr...@redhat.com 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
[Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide
Hi, according to the dedicated Bugzilla feature requesthttps://bugzilla.redhat.com/show_bug.cgi?id=754865, Boost https://admin.fedoraproject.org/pkgdb/acls/name/boost has just been upgraded http://koji.fedoraproject.org/koji/taskinfo?taskID=3526523 (from 1.47.0 http://www.boost.org/users/news/version_1_47_0 to 1.48.0http://www.boost.org/users/news/version_1_48_0) on Rawhide (only). A ticket has been openhttps://fedorahosted.org/rel-eng/ticket/4982for 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: boost soname bump
On Sun, Nov 20, 2011 at 08:05:34 -0600, Bruno Wolff III br...@wolff.to 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
Re: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide
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 boost/foreach.hpp #define foreach BOOST_FOREACH #endif -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FAS mails in Spanish?
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
2011/11/20 Bruno Wolff III br...@wolff.to 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 boost/foreach.hpp #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: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide
On Sun, Nov 20, 2011 at 18:13:14 +0100, Denis Arnaud denis.arnaud_fed...@m4x.org wrote: 2011/11/20 Bruno Wolff III br...@wolff.to 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 boost/foreach.hpp #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: Libs with applications
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: Libs with applications
On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler kevin.kof...@chello.at 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
On Sunday, November 20, 2011 02:14:09 PM drago01 wrote: On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler kevin.kof...@chello.at 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
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 kevin.kof...@chello.at 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: libcdio update coming to rawhide
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=3527348name=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
On Sun, Nov 20, 2011 at 19:33, Steve Grubb sgr...@redhat.com wrote: On Sunday, November 20, 2011 02:14:09 PM drago01 wrote: On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler kevin.kof...@chello.at 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: Libs with applications
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 sgr...@redhat.com 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
[Test-Announce] 2011-11-21 @ 16:00 UTC - Fedora QA Meeting
# 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 - your topic here -- 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: [Heads-Up][ABI Change] Boost has been upgraded to 1.48.0 on Rawhide
On Sun, Nov 20, 2011 at 11:16:32 -0600, Bruno Wolff III br...@wolff.to 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
[perl-Data-FormValidator/f16] update to 4.70
Summary of changes: 63686e1... update to 4.70 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Data-FormValidator/f15] update to 4.70
Summary of changes: 63686e1... update to 4.70 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 755283] New: perl-Gtk2-1.241 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Gtk2-1.241 is available https://bugzilla.redhat.com/show_bug.cgi?id=755283 Summary: perl-Gtk2-1.241 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Gtk2 AssignedTo: tcall...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 1.241 Current version in Fedora Rawhide: 1.240 URL: http://search.cpan.org/dist/Gtk2/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 746941] perl-Mojolicious-2.30 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=746941 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-2.28 is|perl-Mojolicious-2.30 is |available |available --- Comment #19 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-11-20 06:39:21 EST --- Latest upstream release: 2.30 Current version in Fedora Rawhide: 1.99 URL: http://search.cpan.org/dist/Mojolicious/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
