Re: [Status] - Fedora Haskell SIG
This mail was intended for Haskell SIG list. Sorry for the devel wide mail. On Sun, Sep 25, 2011 at 11:25 AM, lakshminaras2...@gmail.com lakshminaras2...@gmail.com wrote: 1) gtk2hs updates available on rawhide (0.12.1) https://bugzilla.redhat.com/show_bug.cgi?id=739876 2) ghc-rpm-macros related bug on f14,f15 fixed. New builds of haskell packages should have the correct rpm hash information from now on 3) Pending reviews requiring owners ghc-wai - https://bugzilla.redhat.com/show_bug.cgi?id=736602 (need by yesod) ghc-Agda - https://bugzilla.redhat.com/show_bug.cgi?id=710031 (needed by Agda package) There are other reviews that require owners and haven't been mentioned above. If you have reviews that need an owner, please send an email to the list. Thanks -- Regards Lakshmi Narasimhan T V -- Regards Lakshmi Narasimhan T V -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9.1 and Lucene Core for F16
Hi, W dniu 11 września 2011 22:47 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: 2011/9/11 Tom Lane t...@redhat.com: =?ISO-8859-2?Q?Micha=B3_Piotrowski?= mkkp...@gmail.com writes: 2011/9/11 Tom Lane t...@redhat.com: Yeah. I have done test packaging of 9.1rc1 already, so it's pretty much ready to go on my end. I would be prepared to push 9.1 into f16 on Monday if there were enough people willing to test and up-karma it before the freeze ... any volunteers out there? I don't have F16, but I can rebuild packages and test on F15 if this will have some test value. F15 is where I've been doing my own testing. It's the F16 packages that would need karma, though. I tried to upgrade to F16 at Wednesday, but preupgrade failed somewhere. Next week I will not be able to upgrade because my vacation ended and I need a fully functioning system over the next few days (I've got a large webapp deployment). So I am afraid that I will not be useful for testing PGSQL 9.1 on F16. The database weenie in me says that trying to push 9.1.0 into F16 at this late date is insane. I'm willing to do it if we can get enough testing attention, but I think it has to be honest testing in an F16-alpha environment. If I find some time I'll try to install F16 on VM, but I do not know whether such tests will be useful. It seems to me that best and most valuable tests would be just do some regular work on DB. I'm using PostgreSQL 9.1 on F16 for a week and did not notice any problems (except slower start). I used preupgrade to update system - after changing database directory in service file I had a working database. From my POV this update was painless :) Great job. Thanks! -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
On Sat, 24 Sep 2011 08:48:16 -0500 Richard Shaw wrote: I just took over the akmods package at RPM Fusion and one of the many BZ requests is to convert it to systemd. The current suggestion is: [Unit] Description=Builds and install new kmods from akmod packages After=syslog.target Before=prefdm.service [Service] Type=oneshot ExecStart=-/usr/sbin/akmods --from-init [Install] WantedBy=multi-user.target But this only works for people using the video driver akmod packages. There are also other packages such as network drivers and possibly others. Is there some way to make this more dynamic so that the run dependencies can be defined by what akmod packages are installed? I think I remember reading a thread where one unit file can call other unit files? Is there some way to setup a akmods.d/ type directory where the individual akmod driver packages can stick unit files? You can have every akmod-* package ship a /lib/systemd/system/akmod-*.target file to specify the ordering, e.g. akmod-foo-video-driver.target: [Unit] Description=akmod for foo After=akmods.service Before=prefdm.service And ship a symlink /lib/systemd/system/akmods.service.wants/akmod-*.target Or, instead of building all the modules from akmods.service, you can build them using 'akmods --akmod ...' from their own akmod-*.service where the ordering will be defined as needed. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110925 changes
Compose started at Sun Sep 25 08:15:16 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46 389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46 389-admin-1.1.23-1.fc17.i686 requires libicudata.so.46 389-admin-1.1.23-1.fc17.x86_64 requires libicuuc.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicui18n.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicudata.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.i686 requires libicuuc.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicui18n.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicudata.so.46 389-adminutil-1.1.14-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicudata.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicudata.so.46()(64bit) R-core-2.13.1-4.fc17.i686 requires libicuuc.so.46 R-core-2.13.1-4.fc17.i686 requires libicui18n.so.46 R-core-2.13.1-4.fc17.x86_64 requires libicuuc.so.46()(64bit) R-core-2.13.1-4.fc17.x86_64 requires libicui18n.so.46()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) 1:anerley-0.3.0-3.fc17.i686 requires libcogl.so.2 1:anerley-0.3.0-3.fc17.x86_64 requires libcogl.so.2()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicuuc.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicui18n.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) bluetile-0.5.3-12.fc17.x86_64 requires libHSpango-0.12.0-ghc7.0.4.so()(64bit) bluetile-0.5.3-12.fc17.x86_64 requires libHSgtk-0.12.0-ghc7.0.4.so()(64bit) bluetile-0.5.3-12.fc17.x86_64 requires libHSglib-0.12.0-ghc7.0.4.so()(64bit) bluetile-0.5.3-12.fc17.x86_64 requires libHSglade-0.12.0-ghc7.0.4.so()(64bit) bluetile-0.5.3-12.fc17.x86_64 requires libHSgio-0.12.0-ghc7.0.4.so()(64bit) bluetile-0.5.3-12.fc17.x86_64 requires libHScairo-0.12.0-ghc7.0.4.so()(64bit) bluetile-0.5.3-12.fc17.x86_64 requires ghc(pango-0.12.0) = 0:6defb18f3b0a95dc8750a2e7e2b75f47 bluetile-0.5.3-12.fc17.x86_64 requires ghc(gtk-0.12.0) = 0:1f632497e2adb1ca58eafe6e80ba6849 bluetile-0.5.3-12.fc17.x86_64 requires ghc(glib-0.12.0) = 0:6c035e26ff59497b45e0ba131f8e7109 bluetile-0.5.3-12.fc17.x86_64 requires ghc(glade-0.12.0) = 0:885f7e4ab12284e314b029cec6fd9af6 bluetile-0.5.3-12.fc17.x86_64 requires ghc(gio-0.12.0) = 0:99d30ef09e181ca08d871b72e0923b31 bluetile-0.5.3-12.fc17.x86_64 requires ghc(cairo-0.12.0) = 0:0f0db7bd16540db34af2e7f3a09ec4bc claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libcogl.so.2()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-0.10.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 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) couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64
Problems with the %{?_isa} macro in dependencies
Hi,
I have tried using the %{_isa} macro in a couple of my packages as
instructed in
http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
and I'm having problems with it.
First case:
The arch-specific libvoikko spell checking package requires the Finnish
morphology, which is in the arch-specific malaga-suomi-voikko package. I
did the following change (the versioned dependency was unnecessary):
-Requires: malaga-suomi-voikko = 1.4
+Requires: malaga-suomi-voikko%{?_isa}
Now AutoQA's depcheck says there is a problem with the i686 dependency
on x86_64:
http://autoqa.fedoraproject.org/results/198794-autotest/10.5.124.164/depcheck/results/libvoikko-3.3.1-0.2..html
SKIPBROKEN: libvoikko-3.3.1-0.2.rc1.fc16.i686 from pending has
depsolving problems
SKIPBROKEN: -- Package: libvoikko-3.3.1-0.2.rc1.fc16.i686 (pending)
-- Requires: malaga-suomi-voikko(x86-32)
Second case:
I'm renaming the openoffice.org-voikko package to libreoffice-voikko.
Review request: https://bugzilla.redhat.com/show_bug.cgi?id=739331,
spec: http://vpv.fedorapeople.org/packages/libreoffice-voikko.spec.
The Provides and Obsoletes are as follows:
Provides: openoffice.org-voikko = %{version}-%{release}
Obsoletes:openoffice.org-voikko 3.1.2-6
This works, but if I change the Obsoletes to
Obsoletes:openoffice.org-voikko%{?_isa} 3.1.2-6
then the package does not obsolete openoffice.org-voikko any more, which
results in file conflicts.
Could someone please explain what's going on here?
--
Ville-Pekka Vainio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[X-Post] Fedora medical needs package maintainers
Hello all, If you've been following the planet[1], you'd know that my GSoC project this year was packaging for the Fedora Medical SIG. I packaged quite a few of them during the GSoC period[2]. The issue here is that I cannot maintain these packages: I do not use them. Are any maintainers here interested in these packages? Please apply for co-maintainer-ship if you are, and I will hand the packages over to you. I am going to orphan these packages in the next few weeks so others can take them over. This is the best path to take in the interests of fedora medical in the long term. If you are interested in maintaining these packages but are not a sponsored maintainer, please have a look at this link[3]. I will gladly mentor anyone who is interested in contributing to fedora as a package maintainer. [1] http://planet.fedoraproject.org [2] http://dodoincfedora.wordpress.com/2011/08/20/fedora-gsoc-report/ [3] http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer -- Thanks, Regards, Ankur: FranciscoD http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problems with the %{?_isa} macro in dependencies
On Sun, 25 Sep 2011 18:55:42 +0300
Ville-Pekka Vainio vpvai...@iki.fi wrote:
First case:
The arch-specific libvoikko spell checking package requires the
Finnish morphology, which is in the arch-specific malaga-suomi-voikko
package. I did the following change (the versioned dependency was
unnecessary): -Requires: malaga-suomi-voikko = 1.4
+Requires: malaga-suomi-voikko%{?_isa}
Libraries are multilib'd. malaga-suomi-voikko only contains data
files (in arch specific directories), thus it isn't multilib'd = the
32-bit data package isn't available on x86_64 and you get the
dependency problem.
Second case:
I'm renaming the openoffice.org-voikko package to libreoffice-voikko.
Review request: https://bugzilla.redhat.com/show_bug.cgi?id=739331,
spec: http://vpv.fedorapeople.org/packages/libreoffice-voikko.spec.
The Provides and Obsoletes are as follows:
Provides: openoffice.org-voikko = %{version}-%{release}
Obsoletes:openoffice.org-voikko 3.1.2-6
This works, but if I change the Obsoletes to
Obsoletes:openoffice.org-voikko%{?_isa} 3.1.2-6
then the package does not obsolete openoffice.org-voikko any more,
which results in file conflicts.
The obsolete doesn't work, since then you're not obsoleting the
package, instead you're obsoleting what the package provides:
$ rpm -q openoffice.org-voikko
openoffice.org-voikko-3.1.2-3.fc15.x86_64
$ rpm -q --provides openoffice.org-voikko
voikko.so()(64bit)
voikko.so(UDK_3_0_0)(64bit)
openoffice.org-voikko = 3.1.2-3.fc15
openoffice.org-voikko(x86-64) = 3.1.2-3.fc15
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problems with the %{?_isa} macro in dependencies
Thanks for the advice! I've made a libvoikko build without the %{_isa}
macro in the malaga-suomi-voikko dependency.
--
Ville-Pekka Vainio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
On Sun, Sep 25, 2011 at 7:01 AM, Michal Schmidt mschm...@redhat.com wrote: You can have every akmod-* package ship a /lib/systemd/system/akmod-*.target file to specify the ordering, e.g. akmod-foo-video-driver.target: [Unit] Description=akmod for foo After=akmods.service Before=prefdm.service And ship a symlink /lib/systemd/system/akmods.service.wants/akmod-*.target So this method will run on the earliest requirement of all installed akmod packages? Or, instead of building all the modules from akmods.service, you can build them using 'akmods --akmod ...' from their own akmod-*.service where the ordering will be defined as needed. Here they provide their own .service file and akmods could be run more than once during boot if the user has more than one akmod package installed? I like the first option because it seems more elegant, but also more complicated. I like the second option because it puts the onus of getting the .service file right on the maintainer of the driver package and not me :) Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
About Feature enhancement Updates Policy
Hi, I've read the examples about updates allowed and I've read in examples section: http://fedoraproject.org/wiki/Updates_Policy#Examples Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also completely updates the user interface to use pie menus. This would be a feature enhancement with a major user experience change, and would not be allowed. Is that requirement honored? Because unless I miss something there is a lot of updates that include only enhancements. Is not my will to create a controversy but perhaps there is something in the guideliness that needs (at the risk of sounding repeating) update And let's say that we have a package foo-5.5 that has libfoo.so 1.0.0 and you make a package 6.0 with library libfoo.so 2.0.0. What should I do: a. Submit foo 6.0 as an update b. Submit foo 6.0 that coexists with foo 5.5 c. Submit foo 6.0 only for rawhide. What is the right option? Sorry if I did 2 questions at once. Thanks in advance -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About Feature enhancement Updates Policy
On Sun, 25 Sep 2011 15:19:45 -0300 Sergio Belkin seb...@gmail.com wrote: Hi, I've read the examples about updates allowed and I've read in examples section: http://fedoraproject.org/wiki/Updates_Policy#Examples Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also completely updates the user interface to use pie menus. This would be a feature enhancement with a major user experience change, and would not be allowed. Is that requirement honored? Because unless I miss something there is a lot of updates that include only enhancements. Is not my will to create a controversy but perhaps there is something in the guideliness that needs (at the risk of sounding repeating) update Perhaps you mean 'enforced' ? If there is an enhancement update that adds to, but doesn't change the user experience, thats fine. And let's say that we have a package foo-5.5 that has libfoo.so 1.0.0 and you make a package 6.0 with library libfoo.so 2.0.0. What should I do: a. Submit foo 6.0 as an update b. Submit foo 6.0 that coexists with foo 5.5 c. Submit foo 6.0 only for rawhide. What is the right option? As with most things in life: It depends. ;) Very likely the answer is c. If there's a security bug or serious problem that is solved only in the new version and can't be easily backported to the existing one you could push it in stable releases. You should ask for an exception for that most likely. Note that if other packages depend on this library, you MUST coordinate with all consumers of that library to make sure they work with the new version and push the update at the same time, etc. b would be an option if there's some reason to keep the old version around... ie, consumers aren't updating to work with the new version and won't for a long time. This would also be done in rawhide unless there was a very good reason not to. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need systemd unit file help.
Richard Shaw wrote: On Sun, Sep 25, 2011 at 7:01 AM, Michal Schmidt mschm...@redhat.com wrote: Or, instead of building all the modules from akmods.service, you can build them using 'akmods --akmod ...' from their own akmod-*.service where the ordering will be defined as needed. Here they provide their own .service file and akmods could be run more than once during boot if the user has more than one akmod package installed? I think the idea is to run it only for each specific akmod, not for all at once. I like the first option because it seems more elegant, but also more complicated. I like the second option because it puts the onus of getting the .service file right on the maintainer of the driver package and not me :) I think the second option is more elegant, it fits more into the spirit of parallelized boot. I guess it even allows building independent akmods in parallel. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-HTML-FormatText-WithLinks-AndTables
perl-HTML-FormatText-WithLinks-AndTables has broken dependencies in the F-16 tree: On x86_64: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Test-Version
perl-Test-Version has broken dependencies in the F-16 tree: On x86_64: perl-Test-Version-1.0.0-3.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Test-Version-1.0.0-3.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Unicode-CheckUTF8
perl-Unicode-CheckUTF8 has broken dependencies in the F-16 tree: On x86_64: perl-Unicode-CheckUTF8-1.03-2.fc15.x86_64 requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Unicode-CheckUTF8-1.03-2.fc15.i686 requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- 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-Net-SSLeay] Update to 1.41
commit 5af17268bb1149dffcdd444718b0e83859763988
Author: Paul Howarth p...@city-fan.org
Date: Sun Sep 25 15:10:23 2011 +0100
Update to 1.41
- New upstream release 1.41
- fixed incorrect const signatures for 1.0 that were causing warnings; now
have clean compile with 0.9.8a through 1.0.0
- BR: perl(Carp)
perl-Net-SSLeay.spec |9 -
sources |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-SSLeay.spec b/perl-Net-SSLeay.spec
index f0afc00..6809aee 100644
--- a/perl-Net-SSLeay.spec
+++ b/perl-Net-SSLeay.spec
@@ -1,5 +1,5 @@
Name: perl-Net-SSLeay
-Version: 1.40
+Version: 1.41
Release: 1%{?dist}
Summary: Perl extension for using OpenSSL
Group: Development/Libraries
@@ -9,6 +9,7 @@ Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MIKEM/Net-SSLeay-%{version}
Patch0:Net-SSLeay-1.40-UTF8.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildRequires: openssl-devel, pkgconfig
+BuildRequires: perl(Carp)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(MIME::Base64)
BuildRequires: perl(Test::Exception)
@@ -79,6 +80,12 @@ rm -rf %{buildroot}
%{_mandir}/man3/Net::SSLeay*.3*
%changelog
+* Sun Sep 25 2011 Paul Howarth p...@city-fan.org - 1.41-1
+- update to 1.41
+ - fixed incorrect const signatures for 1.0 that were causing warnings; now
+have clean compile with 0.9.8a through 1.0.0
+- BR: perl(Carp)
+
* Fri Sep 23 2011 Paul Howarth p...@city-fan.org - 1.40-1
- update to 1.40
- fixed incorrect argument type in call to SSL_set1_param
diff --git a/sources b/sources
index 703f107..a6f524b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d2402e5f4d92c2b2701053c02d15fa22 Net-SSLeay-1.40.tar.gz
+10b2df94613c19f81cbf3b3123cffcec Net-SSLeay-1.41.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-Net-SSLeay] Created tag perl-Net-SSLeay-1.41-1.fc17
The lightweight tag 'perl-Net-SSLeay-1.41-1.fc17' was created pointing to: 5af1726... Update to 1.41 -- 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
File Shipwright-2.4.30.tar.gz uploaded to lookaside cache by cheeselee
A file has been added to the lookaside cache for perl-Shipwright: fe89aae1a3a035e7477773c3ac11 Shipwright-2.4.30.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-Shipwright/f16] Update to 2.4.30
commit f7ed23978979f870a5ec9b45f11c0c3efb7cff08
Author: Robin Lee cheese...@fedoraproject.org
Date: Mon Sep 26 09:47:35 2011 +0800
Update to 2.4.30
.gitignore |1 +
perl-Shipwright.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9b02abf..18f7626 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Shipwright-2.4.24.tar.gz
/Shipwright-2.4.28.tar.gz
+/Shipwright-2.4.30.tar.gz
diff --git a/perl-Shipwright.spec b/perl-Shipwright.spec
index 57a7ee2..f2e36f5 100644
--- a/perl-Shipwright.spec
+++ b/perl-Shipwright.spec
@@ -1,5 +1,5 @@
Name: perl-Shipwright
-Version:2.4.28
+Version:2.4.30
Release:1%{?dist}
Summary:Build and Manage Self-contained Software Bundle
License:GPL+ or Artistic
@@ -76,6 +76,9 @@ make test %{?_smp_mflags}
%{_mandir}/man3/*
%changelog
+* Sat Sep 24 2011 Robin Lee cheese...@fedoraproject.org - 2.4.30-1
+- Update to 2.4.30
+
* Wed Jul 27 2011 Robin Lee cheese...@fedoraproject.org - 2.4.28-1
- Update to 2.4.28 (#712671)
- Use rpm 4.9 style filter
diff --git a/sources b/sources
index 3d5f697..71acff0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cb7eabeb556c15522f312a1e55ea59ac Shipwright-2.4.28.tar.gz
+fe89aae1a3a035e7477773c3ac11 Shipwright-2.4.30.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-Shipwright] Update to 2.4.30
Summary of changes: f7ed239... Update to 2.4.30 (*) (*) 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 728487] perl-Shipwright-2.4.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=728487 Robin Lee robinlee.s...@gmail.com changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #2 from Robin Lee robinlee.s...@gmail.com 2011-09-25 23:33:31 EDT --- built 2.4.30 for rawhide and f16 -- 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
