rawhide report: 20121228 changes
Compose started at Fri Dec 28 08:15:12 UTC 2012 Broken deps for x86_64 -- [OpenImageIO] OpenImageIO-1.0.9-2.fc19.i686 requires libwebp.so.2 OpenImageIO-1.0.9-2.fc19.x86_64 requires libwebp.so.2()(64bit) [dogtag-pki] dogtag-pki-10.0.0-0.16.b3.fc19.noarch requires dogtag-pki-server-theme = 0:10.0.0 [ember] ember-0.6.3-3.fc19.x86_64 requires libOgreMain.so.1.7.4()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [evolution-rss] 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libevolution-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemiscwidgets.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemail-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libedataserverui-3.0.so.5()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libcamel-1.2.so.42()(64bit) [freeipa] freeipa-server-3.1.0-1.fc19.x86_64 requires dogtag-pki-server-theme [freewrl] freewrl-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 freewrl-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) libEAI-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 libEAI-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdal] gdal-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit) gdal-java-1.9.1-14.fc19.i686 requires libwebp.so.2 gdal-java-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit) gdal-libs-1.9.1-14.fc19.i686 requires libwebp.so.2 gdal-libs-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit) gdal-perl-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit) gdal-ruby-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit) [ghc-wai-extra] ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSwai-1.2.0.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvoid-0.5.6-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvault-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunix-2.5.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStime-1.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStext-0.11.2.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSparsec-3.1.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmtl-2.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmonad-control-0.3.1.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSlifted-base-0.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSinteger-gmp-0.4.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShttp-types-0.6.11-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShashable-1.1.2.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfilepath-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfast-logger-0.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdlist-0.5-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires
F-18 Branched report: 20121228 changes
Compose started at Fri Dec 28 09:15:47 UTC 2012 Summary: Added Packages: 0 Removed Packages: 0 Upgraded Packages: 0 Compose finished at Fri Dec 28 13:08:29 UTC 2012 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20121228 changes
Le vendredi 28 décembre 2012 à 13:02 +, Fedora Rawhide Report a
écrit :
Compose started at Fri Dec 28 08:15:12 UTC 2012
Broken deps for x86_64
--
[OpenImageIO]
OpenImageIO-1.0.9-2.fc19.i686 requires libwebp.so.2
OpenImageIO-1.0.9-2.fc19.x86_64 requires libwebp.so.2()(64bit)
a rebuild was enough to solve the deps issue, so maybe a PP could run
it ?
[ember]
ember-0.6.3-3.fc19.x86_64 requires libOgreMain.so.1.7.4()(64bit)
do not build, need a older version of Ogre
[evolution-rss]
1:evolution-rss-0.3.92-3.fc19.x86_64 requires
libevolution-utils.so()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires
libemiscwidgets.so()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemail-utils.so()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires
libedataserverui-3.0.so.5()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires
libcamel-1.2.so.42()(64bit)
failed
checking for EVOLUTION_RSS_EPLUGIN... no
configure: error: Package requirements ( glib-2.0 = 2.16.2gtk+-3.0 =
2.99.3libsoup-2.4 = 2.2evolution-plugin-3.0 = 2.91.6
evolution-shell-3.0 = 2.91.6libemail-utils libemail-engine
libevolution-utilslibebook-1.2 ) were not met:
No package 'libemail-utils' found
No package 'libevolution-utils' found
As I think evolution changed upstream, this is surely something easy to fix.
[freewrl]
freewrl-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7
freewrl-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit)
libEAI-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7
libEAI-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit)
Do not compile due to change in xulrunner :
/usr/include/xulrunner-17.0.1/jsapi.h:3649:1: note: expected 'struct
JSObject **' but argument is of type 'struct JSObject *'
world_script/JScript.c: In function 'JSCreateScriptContext':
world_script/JScript.c:407:3: warning: implicit declaration of function
'JS_NewCompartmentAndGlobalObject' [-Wimplicit-function-declaration]
world_script/JScript.c:407:14: warning: assignment makes pointer from integer
without a cast [enabled by default]
world_script/JScript.c:410:3: error: too few arguments to function
'JS_NewGlobalObject'
[gdal]
gdal-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit)
gdal-java-1.9.1-14.fc19.i686 requires libwebp.so.2
gdal-java-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit)
gdal-libs-1.9.1-14.fc19.i686 requires libwebp.so.2
gdal-libs-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit)
gdal-perl-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit)
gdal-ruby-1.9.1-14.fc19.x86_64 requires libwebp.so.2()(64bit)
Rebuild seems to be enough
[leptonica]
leptonica-1.69-3.fc19.i686 requires libwebp.so.2
leptonica-1.69-3.fc19.x86_64 requires libwebp.so.2()(64bit)
same as the others, a rebuild seems to be enough
[meshmagick]
meshmagick-0.6.0-13.svn2898.fc18.x86_64 requires
libOgreMain.so.1.7.4()(64bit)
meshmagick-libs-0.6.0-13.svn2898.fc18.i686 requires libOgreMain.so.1.7.4
meshmagick-libs-0.6.0-13.svn2898.fc18.x86_64 requires
libOgreMain.so.1.7.4()(64bit)
Fail to build due to some boost error :
/usr/bin/c++-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-I/builddir/build/BUILD/meshmagick/include -I/usr/include/OGRE-o
CMakeFiles/meshmagick_bin.dir/src/main.cpp.o
-c /builddir/build/BUILD/meshmagick/src/main.cpp
Linking CXX executable meshmagick
/usr/bin/cmake -E cmake_link_script CMakeFiles/meshmagick_bin.dir/link.txt
--verbose=1
/usr/bin/c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-Wl,-z,relro CMakeFiles/meshmagick_bin.dir/src/main.cpp.o -o meshmagick
-rdynamic libmeshmagick.so.0.6.0 -lOgreMain
/usr/bin/ld: CMakeFiles/meshmagick_bin.dir/src/main.cpp.o: undefined reference
to symbol '_ZN5boost6system15system_categoryEv'
/usr/bin/ld: note: '_ZN5boost6system15system_categoryEv' is defined in DSO
/lib64/libboost_system-mt.so.1.50.0 so try adding it to the linker command line
/lib64/libboost_system-mt.so.1.50.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: Leaving directory `/builddir/build/BUILD/meshmagick'
[mygui]
mygui-3.2.0-2.fc19.i686 requires libCommon.so
mygui-3.2.0-2.fc19.x86_64 requires libCommon.so()(64bit)
mygui-demos-3.2.0-2.fc19.x86_64 requires libCommon.so()(64bit)
mygui-tools-3.2.0-2.fc19.x86_64 requires libCommon.so()(64bit)
Rebuild fine, but the Requires is still present.
[root]
root-graf3d-gl-5.34.02-1.fc19.x86_64 requires libGLEW.so.1.7()(64bit)
doesn't even let a srpm be created on F18, and fail on this line :
%if %{?fedora}%{!?fedora:0} = 17 || %{?rhel}%{!?rhel:0} = 7
( and as a
Re: pulseaudio maintainership status
On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I know upstream is moving really fast these days, but I thinbk any risk is alleviated by Rex's backport - we can safely identify any showstoppers within a fedora release cycle. 1.1 for F17 is way to far behind IMHO given that upstream is now at 3.0. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pillow, actively developed and (mostly) python3 compatible PIL (python-imaging)
On 12/23/2012 02:45 AM, Sandro Mani wrote: Hello all, Working on a python project using PIL, and wanting to port it to python3, I got bitten by the absence of a python3 compatible PIL. Doing some research, there seems to be an actively developed PIL fork, called Pillow, which can be found here [1]. It describes itself as Pillow is the friendly PIL fork. PIL is the Python Imaging Library. Pillow was started for and is currently maintained by the Plone community. But it is used by many other folks in the Python web community, and probably elsewhere too. The fork author's goal is to foster packaging improvements via: - Publicized development and solicitation of community support. - Exploration of packaging problems within the fork, most noticably via adding setuptools support but also via clean up refactoring of packaging code. Now, the PIL project has been rather inactive lately (last release in 2009), and there seems to be some general agreement that Pillow is a likely candidate to succeed PIL, and in particular to bring python3 support see the discussion at [2] and [3]. Now, there already seems to have been some discussion about adopting it in Fedora (at least, it was mentioned in [4]), and I'd like to bring up the issue again. I've packaged the latest Pillow release (1.7.8) here [5], based on the python-imaging package, and the state is the following - Compiles for both python2 and python3, both variants pass the self-tests - Python 3 support is all upstream code, except for pysane, which I needed to patch (and I'll propose the changes upstream once github is back alive) - Python 2 looks like a drop-in replacement for PIL, except that you need to write i.e. from PIL import Image instead of directly import Image (the latter was allowed only by a PIL.pth file in the site-packages dir, and looked like a hack anyway - with the changes for python3 compatibility, the files in the PIL directory use relative imports, and hence the import Image does not work anymore, one could still patch away the relative imports in the python2 variant for 100% compatibility though) - Note: because of what I think is a nasty python3-distutils bug (shared-library extension incorrect, see [6]) I needed to patch a file in the python3 distutils modules for the package to compile, see [7]. So, since Pillow seems to be the most likely candidate for python3-imaging, the questions are: - Do we want Pillow to succeed PIL in Fedora? * According to [3], it is likely that Pillow will soon become an unfriendly fork of PIL, so Pillow-PIL compatibility is likely to break in the future * But still being compatible at the moment, I'd say it would be easier to make the transition now - Python2 and 3, or only the python-3 variant? - Plus some packaging questions for the maintainers (I could co-maintain if desired): * Keep the package name? * Need new review request? - Sandro [1] https://github.com/python-imaging/Pillow/ [2] http://mail.python.org/pipermail/image-sig/2012-October/007059.html [3] http://mail.python.org/pipermail/image-sig/2012-December/007120.html [4] http://mail.python.org/pipermail/image-sig/2012-October/007099.html [5] http://smani.fedorapeople.org/python-imaging-1.7.8-1.fc19.src.rpm [6] http://mail.python.org/pipermail/python-dev/2012-December/123278.html [7] http://smani.fedorapeople.org/python3.3-so_ext.patch FWIW I have been considering changing the source code to pillow ever since pillow appeared. :-) If we make the switch we should do it all the way. The unfriendly aspect of the fork is due to the fact that pillow will have more features that PIL. This is IMHO. :-) -- José Matos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pillow, actively developed and (mostly) python3 compatible PIL (python-imaging)
On 28.12.2012 17:14, José Matos wrote: On 12/23/2012 02:45 AM, Sandro Mani wrote: Hello all, Working on a python project using PIL, and wanting to port it to python3, I got bitten by the absence of a python3 compatible PIL. Doing some research, there seems to be an actively developed PIL fork, called Pillow, which can be found here [1]. It describes itself as Pillow is the friendly PIL fork. PIL is the Python Imaging Library. Pillow was started for and is currently maintained by the Plone community. But it is used by many other folks in the Python web community, and probably elsewhere too. The fork author's goal is to foster packaging improvements via: - Publicized development and solicitation of community support. - Exploration of packaging problems within the fork, most noticably via adding setuptools support but also via clean up refactoring of packaging code. Now, the PIL project has been rather inactive lately (last release in 2009), and there seems to be some general agreement that Pillow is a likely candidate to succeed PIL, and in particular to bring python3 support see the discussion at [2] and [3]. Now, there already seems to have been some discussion about adopting it in Fedora (at least, it was mentioned in [4]), and I'd like to bring up the issue again. I've packaged the latest Pillow release (1.7.8) here [5], based on the python-imaging package, and the state is the following - Compiles for both python2 and python3, both variants pass the self-tests - Python 3 support is all upstream code, except for pysane, which I needed to patch (and I'll propose the changes upstream once github is back alive) - Python 2 looks like a drop-in replacement for PIL, except that you need to write i.e. from PIL import Image instead of directly import Image (the latter was allowed only by a PIL.pth file in the site-packages dir, and looked like a hack anyway - with the changes for python3 compatibility, the files in the PIL directory use relative imports, and hence the import Image does not work anymore, one could still patch away the relative imports in the python2 variant for 100% compatibility though) - Note: because of what I think is a nasty python3-distutils bug (shared-library extension incorrect, see [6]) I needed to patch a file in the python3 distutils modules for the package to compile, see [7]. So, since Pillow seems to be the most likely candidate for python3-imaging, the questions are: - Do we want Pillow to succeed PIL in Fedora? * According to [3], it is likely that Pillow will soon become an unfriendly fork of PIL, so Pillow-PIL compatibility is likely to break in the future * But still being compatible at the moment, I'd say it would be easier to make the transition now - Python2 and 3, or only the python-3 variant? - Plus some packaging questions for the maintainers (I could co-maintain if desired): * Keep the package name? * Need new review request? - Sandro [1] https://github.com/python-imaging/Pillow/ [2] http://mail.python.org/pipermail/image-sig/2012-October/007059.html [3] http://mail.python.org/pipermail/image-sig/2012-December/007120.html [4] http://mail.python.org/pipermail/image-sig/2012-October/007099.html [5] http://smani.fedorapeople.org/python-imaging-1.7.8-1.fc19.src.rpm [6] http://mail.python.org/pipermail/python-dev/2012-December/123278.html [7] http://smani.fedorapeople.org/python3.3-so_ext.patch FWIW I have been considering changing the source code to pillow ever since pillow appeared. :-) If we make the switch we should do it all the way. The unfriendly aspect of the fork is due to the fact that pillow will have more features that PIL. This is IMHO. :-) I've written a feature page for the PIL-Pillow switch here [1]. [1] https://fedoraproject.org/wiki/Features/Pillow -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20121228 changes
On Fri, Dec 28, 2012 at 03:39:03PM +0100, Michael Scherer wrote: So, if proven packager could help to clean the list by rebuilding the following, that would be nice : - spacechart - leptonica - OpenImageIO - gdal Rebuilds kicked off: http://koji.fedoraproject.org/koji/taskinfo?taskID=4823027 http://koji.fedoraproject.org/koji/taskinfo?taskID=4823028 http://koji.fedoraproject.org/koji/taskinfo?taskID=4823029 http://koji.fedoraproject.org/koji/taskinfo?taskID=4823030 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20121228 changes
On 12/28/2012 12:34 PM, Richard W.M. Jones wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=4823027 http://koji.fedoraproject.org/koji/taskinfo?taskID=4823028 http://koji.fedoraproject.org/koji/taskinfo?taskID=4823029 http://koji.fedoraproject.org/koji/taskinfo?taskID=48230 Thanks. I pushed the new version of libwebp after verifying the dependencies did rebuild fine but hadn't gotten to do that in Koji yest night. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On Fri, Dec 28, 2012 at 3:34 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I don't agree. We're moments from release and the 3.0 release hasn't been out for that long and it's likely that while it might fix the one bug it could introduce any number of other bugs. I know upstream is moving really fast these days, but I thinbk any risk is alleviated by Rex's backport - we can safely identify any showstoppers within a fedora release cycle. There's a working backport patch for a platform that isn't really supported in Fedora and it works on other virtual platforms without issue. While I would love to see 3.0 in Fedora 18 due to it's support for UCM which is used extensively in ARM I'm not even pushing it because I know it could break more than it might well fix. 1.1 for F17 is way to far behind IMHO given that upstream is now at 3.0. Why? it works and is relatively stable, there's a lot of change between 1.1, 2.0, 2.1 and 3.0 which could introduce any number of other bugs and regressions in a release that is suppose to be stable. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Enlightenment for Fedora
Hi I am working on bringing in Enlightenment back into Fedora. I am going to be copying the packages at http://repos.fedorapeople.org/repos/sundaram/enlightenment/ as I work on them. This would just be a temporary experimental repo. I have updated the existing dependencies in the Fedora repo to the latest versions since yesterday (libeina, evas, eet, ecore, libwebp) and I have packaged eio and evas-generic-loaders so far. I know a few people have been working on this earlier. so if anyone is interested, do drop me a mail offlist and we can collaborate. I would be happy to let anyone else take over as well if you are so inclined. Thanks Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On Dec 28, 2012, at 12:25 PM, Peter Robinson pbrobin...@gmail.com wrote: On Fri, Dec 28, 2012 at 3:34 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I don't agree. We're moments from release and the 3.0 release hasn't been out for that long and it's likely that while it might fix the one bug it could introduce any number of other bugs. Yeah, the F18 ship has sailed, we're way past freeze. In fact it needs to be in Rawhide soon enough to get into F19. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Enlightenment for Fedora
Are you plan package only stable versions or versionf from SVN? 2012/12/29 Rahul Sundaram methe...@gmail.com Hi I am working on bringing in Enlightenment back into Fedora. I am going to be copying the packages at http://repos.fedorapeople.org/repos/sundaram/enlightenment/ as I work on them. This would just be a temporary experimental repo. I have updated the existing dependencies in the Fedora repo to the latest versions since yesterday (libeina, evas, eet, ecore, libwebp) and I have packaged eio and evas-generic-loaders so far. I know a few people have been working on this earlier. so if anyone is interested, do drop me a mail offlist and we can collaborate. I would be happy to let anyone else take over as well if you are so inclined. Thanks Rahul -- 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: Enlightenment for Fedora
On 12/29/2012 01:23 AM, Vascom wrote: Are you plan package only stable versions or versionf from SVN? For now, the focus is to get the packages through the review process. SVN builds can be scripted if there is sufficient interest Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File ZMQ-Constants-1.02.tar.gz uploaded to lookaside cache by jpo
A file has been added to the lookaside cache for perl-ZMQ-Constants: 3fdca9bc0a605a80c564c7b1fddcaf30 ZMQ-Constants-1.02.tar.gz -- 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-ZMQ-Constants] * Update to version 1.02
commit bc5d614d128a292a299ba963726c123c17d4b4b0
Author: Jose Pedro Oliveira j...@di.uminho.pt
Date: Fri Dec 28 16:18:58 2012 +
* Update to version 1.02
.gitignore |1 +
perl-ZMQ-Constants.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b9f2361..32ce1e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/ZMQ-Constants-1.01.tar.gz
+/ZMQ-Constants-1.02.tar.gz
diff --git a/perl-ZMQ-Constants.spec b/perl-ZMQ-Constants.spec
index c253221..4b5d175 100644
--- a/perl-ZMQ-Constants.spec
+++ b/perl-ZMQ-Constants.spec
@@ -1,6 +1,6 @@
Name: perl-ZMQ-Constants
-Version:1.01
-Release:2%{?dist}
+Version:1.02
+Release:1%{?dist}
Summary:Constants for the libzmq library
License:GPL+ or Artistic
@@ -48,6 +48,9 @@ make test
%changelog
+* Fri Dec 28 2012 Jose Pedro Oliveira jpo at di.uminho.pt - 1.02-1
+- Update to 1.02.
+
* Thu Nov 1 2012 Jose Pedro Oliveira jpo at di.uminho.pt - 1.01-2
- Handle comment #1 items of the review ticket #868528.
diff --git a/sources b/sources
index 792a285..37a9e16 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-89e61e2b720af64ff0b153de870dc12c ZMQ-Constants-1.01.tar.gz
+3fdca9bc0a605a80c564c7b1fddcaf30 ZMQ-Constants-1.02.tar.gz
--
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 890665] New: perl-ExtUtils-XSpp-0.1603 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=890665 Bug ID: 890665 Summary: perl-ExtUtils-XSpp-0.1603 is available Product: Fedora Version: rawhide Component: perl-ExtUtils-XSpp Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Reporter: upstream-release-monitor...@fedoraproject.org Latest upstream release: 0.1603 Current version in Fedora Rawhide: 0.1602 URL: http://search.cpan.org/dist/ExtUtils-XSpp/ 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 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9n0YIb237ha=cc_unsubscribe -- 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 890567] perl-Test-Strict-0.16 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=890567 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Test-Strict-0.15 is|perl-Test-Strict-0.16 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.16 Current version in Fedora Rawhide: 0.14 URL: http://search.cpan.org/dist/Test-Strict/ 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 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=k6dULZMDHKa=cc_unsubscribe -- 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-ZMQ-Constants/f18] * Update to version 1.02
Summary of changes: bc5d614... * Update to version 1.02 (*) (*) 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-ZMQ-Constants/f17] * Update to version 1.02
Summary of changes: bc5d614... * Update to version 1.02 (*) (*) 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 890721] New: perl-Net-Amazon-S3 in Fedora 17 is dated and needs to be updated to stop warnings
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=890721 Bug ID: 890721 Summary: perl-Net-Amazon-S3 in Fedora 17 is dated and needs to be updated to stop warnings Product: Fedora Version: 17 Component: perl-Net-Amazon-S3 Severity: medium Priority: unspecified Reporter: pau...@arid.us Description of problem: perl-Net-Amazon-S3 in Fedora 17 is at 0.53. A change in Perl syntax has made syntax used in Net/Amazon/S3/Request/ListBucket.pm to be considered deprecated and Perl produces a warning when trying to use the package. Version-Release number of selected component (if applicable): perl-Net-Amazon-S3-0.53-3.fc17.noarch How reproducible: Easily reproduced with the 1-line Perl program as shown below. Steps to Reproduce: 1. perl -e use Net::Amazon::S3 Actual results: Use of qw(...) as parentheses is deprecated at /usr/share/perl5/vendor_perl/Net/Amazon/S3/Request/ListBucket.pm line 22. Expected results: No warnings. Additional info: CPAN is currently at 0.58. I noted the syntax related to this function was changed in that version. It's a trivial syntax change and if it's not possible to use newer source code from CPAN, I would suggest at least incorporating that small syntax change into 0.53-xx used in Fedora. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pq3py00oEXa=cc_unsubscribe -- 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
