Vivifying deprecated perl-Business-CreditCard
Hello, I'd like to vivify deprecated and orphaned package `perl-Business-CreditCard'. In my opinion, the package has been deprecated by accident as it has been working wihtout any reported bugs. Re-review for this package, needed by Fedora unorphaning process (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package), is available on https://bugzilla.redhat.com/show_bug.cgi?id=730638. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Create rpm package for pjproject.
Hi to all, I'm trying to create the rpm packages for pjproject to help sflphone request: https://bugzilla.redhat.com/show_bug.cgi?id=692131 Pjproject is a set of libraries written in C language for building embedded/non-embedded VoIP applications. My review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=728302 I don't understand where is my mistake in spec file. I can't create packages for 64 bit architecture, the install process try to put the files library in '/usr/lib', not in '/usr/lib64' on my local system. I try to use mock to create packages for other distro but I have similar error to my koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3272843 Could anybody give me a suggestion? Thank you very much. -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Create rpm package for pjproject.
On Mon, 15 Aug 2011 11:31:29 +0200, MS (Mario) wrote:
Hi to all,
I'm trying to create the rpm packages for pjproject to help sflphone
request:
https://bugzilla.redhat.com/show_bug.cgi?id=692131
Pjproject is a set of libraries written in C language for building
embedded/non-embedded VoIP applications.
My review request is here:
https://bugzilla.redhat.com/show_bug.cgi?id=728302
I don't understand where is my mistake in spec file. I can't create packages
for 64 bit architecture, the install process try to put the files library in
'/usr/lib', not in '/usr/lib64' on my local system.
Well, some projects hardcode /usr/lib (and similar paths) in their build
framework without providing a simple command-line option to change it.
You may need to examine the files to find out where and why it thinks
/usr/lib is the place to use, then come up with a patch (or a sed substitution)
in the %prep section, so you can insert the value %{_libdir} expands to.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110815 changes
Compose started at Mon Aug 15 08:16:01 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcryptui.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(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 libclucene.so.0()(64bit) bluetile-0.5.3-11.fc16.x86_64 requires ghc(xmonad-contrib-0.9.2) = 0:d669bbdb9b9f7adb145fcb61825dec73 cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave empathy-3.1.4-1.fc16.x86_64 requires libfolks.so.24()(64bit) empathy-3.1.4-1.fc16.x86_64 requires libfolks-telepathy.so.24()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.i686 requires libboost_system-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_serialization-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_filesystem-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_serialization-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) garden-1.0.8-3.fc15.x86_64 requires liballeg.so.4.2()(64bit) glom-1.18.3-1.fc16.x86_64 requires libepc-1.0.so.2()(64bit) glom-libs-1.18.3-1.fc16.i686 requires libepc-1.0.so.2 glom-libs-1.18.3-1.fc16.x86_64 requires libepc-1.0.so.2()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libupnp.so.3()(64bit) gmediaserver-0.13.0-7.fc15.x86_64 requires libthreadutil.so.2()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64
Re: Create rpm package for pjproject.
In data 15/8/2011 12:21:51, Michael Schwendt ha scritto:
Well, some projects hardcode /usr/lib (and similar paths) in their build
framework without providing a simple command-line option to change it.
You may need to examine the files to find out where and why it thinks
/usr/lib is the place to use, then come up with a patch (or a sed
substitution) in the %prep section, so you can insert the value
%{_libdir} expands to.
Thank you, I create a little patch for the Makefile, I create the packages
without problems.
https://bugzilla.redhat.com/show_bug.cgi?id=728302#c9
Thank you!
--
Mario Santagiuliana
www.marionline.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On 8/13/11 2:23 PM, Jim Meyering wrote: I'd start with -O2 -D_FORTIFY_SOURCE=2 and something like this subset of -Wall: -Warray-bounds -Wchar-subscripts -Wsequence-point gcc now has: -Werror= Make the specified warning into an error. The specifier for a warning is appended, for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings, for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect. There's quite a few warnings we could reasonably promote to errors like this. FESCO would be happy to listen to a proposal for such, if anyone feels like doing the research. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for today's FESCo meeting (2011-08-15)
I am apologizing for the late meeting invitation. Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = no tickets = New business = no tickets = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Tomas Mraz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110815 changes
Compose started at Mon Aug 15 13:15:35 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_serialization-mt.so.1.46.1()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_iostreams-mt.so.1.46.1()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_program_options-mt.so.1.46.1()(64bit) LuxRender-0.7.1-6.fc16.x86_64 requires libboost_regex-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_serialization-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_iostreams-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_program_options-mt.so.1.46.1()(64bit) LuxRender-core-0.7.1-6.fc16.x86_64 requires libboost_regex-mt.so.1.46.1()(64bit) OpenImageIO-0.10.0-2.fc15.i686 requires libboost_regex-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_program_options-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_thread-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_system-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libGLEW.so.1.5 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_filesystem-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.i686 requires libboost_python-mt.so.1.46.0 OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_regex-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_filesystem-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_program_options-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_system-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libGLEW.so.1.5()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_python-mt.so.1.46.0()(64bit) OpenImageIO-0.10.0-2.fc15.x86_64 requires libboost_thread-mt.so.1.46.0()(64bit) QuantLib-test-1.1-1.fc16.x86_64 requires libboost_unit_test_framework.so.1.46.1()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcryptui.so.0()(64bit) 1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26 1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler.so.13()(64bit) apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler-glib.so.6()(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 libclucene.so.0()(64bit) claws-mail-plugins-geolocation-3.7.9-7.fc16.x86_64 requires libcogl.so.1()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) collectd-snmp-4.10.3-7.fc16.x86_64 requires
Duplicate perl packages - perl-Compress-Raw-Zlib
Does anybody know what's going on with this? Base perl has a sub package for perl-Compress-Raw-Zlib (which gets its own version numbering). It seems to have been there for quite a while. Recently (March of last year) perl-Compress-Raw-Zlib was brought in as its own package (https://bugzilla.redhat.com/show_bug.cgi?id=573929) but the existing sub package was never removed, and exists to this day. Can somebody tell me what's going on here? Which one is the true package, which one needs to go away? I care because now we have mismatched version numbers for this package, and it is causing some interesting scenarios when trying to use Fedora repos as a koji external repo. There may be more cases of this, I haven't done an exhaustive search. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Duplicate perl packages - perl-Compress-Raw-Zlib
On 08/15/2011 06:42 PM, Jesse Keating wrote: Does anybody know what's going on with this? Base perl has a sub package for perl-Compress-Raw-Zlib (which gets its own version numbering). It seems to have been there for quite a while. Recently (March of last year) perl-Compress-Raw-Zlib was brought in as its own package (https://bugzilla.redhat.com/show_bug.cgi?id=573929) but the existing sub package was never removed, and exists to this day. Can somebody tell me what's going on here? Which one is the true package, which one needs to go away? I care because now we have mismatched version numbers for this package, and it is causing some interesting scenarios when trying to use Fedora repos as a koji external repo. There may be more cases of this, I haven't done an exhaustive search. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating Updates of core modules were sometimes hard and we used this approach few last releases: https://fedoraproject.org/wiki/Perl/updates#Updates_of_Perl_core_modules It should be working in rpm, but I wasn't aware of koji problems. I suppose that now we can live without dual life modules, because Perl modules in core are updated more often. But I'd rather discuss it with Perl SIG members before any action. -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Duplicate perl packages - perl-Compress-Raw-Zlib
On Aug 15, 2011, at 10:07 AM, Marcela Mašláňová wrote: On 08/15/2011 06:42 PM, Jesse Keating wrote: Does anybody know what's going on with this? Base perl has a sub package for perl-Compress-Raw-Zlib (which gets its own version numbering). It seems to have been there for quite a while. Recently (March of last year) perl-Compress-Raw-Zlib was brought in as its own package (https://bugzilla.redhat.com/show_bug.cgi?id=573929) but the existing sub package was never removed, and exists to this day. Can somebody tell me what's going on here? Which one is the true package, which one needs to go away? I care because now we have mismatched version numbers for this package, and it is causing some interesting scenarios when trying to use Fedora repos as a koji external repo. There may be more cases of this, I haven't done an exhaustive search. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating Updates of core modules were sometimes hard and we used this approach few last releases: https://fedoraproject.org/wiki/Perl/updates#Updates_of_Perl_core_modules It should be working in rpm, but I wasn't aware of koji problems. I suppose that now we can live without dual life modules, because Perl modules in core are updated more often. But I'd rather discuss it with Perl SIG members before any action. Upon further looking at the koji problem, these packages may not actually be causing my root issue, since they do come from separate SRPMs. However I am curious if this strategy has ever gone though the packaging committee, releng, or fesco. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Meeting minutes/summary for 2011-08-15 fesco meeting
=== #fedora-meeting: FESCO (2011-08-15) === Meeting started by t8m at 17:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-08-15/fesco.2011-08-15-17.00.log.html . Meeting summary --- * init process (t8m, 17:00:30) * FESCo members in/not in provenpackager/sponsors (t8m, 17:05:25) * ACTION: pjones will file a ticket to create sponsor-feedback alias that will contain packager-sponsor-members and fesco-list (t8m, 17:28:11) * https://fedorahosted.org/fas/ticket/142 (pjones, 17:28:57) * ACTION: notting will fwd the feedback e-mails to the fesco list (t8m, 17:35:57) * Fedora Engineering Services tickets (t8m, 17:39:58) * https://fedorahosted.org/fedora-engineering-services/report/6 (t8m, 17:40:08) * Next week's chair (t8m, 17:42:03) * ACTION: sgallagh to be chair on 2011-08-29 meeting (t8m, 17:44:30) * ACTION: nirik to be chair next week - on 2011-08-22 meeting (t8m, 17:44:59) * Open Floor (t8m, 17:45:08) * LINK: https://fedorahosted.org/fesco/ticket/660 (sgallagh, 18:00:31) Meeting ended at 18:03:26 UTC. Action Items * pjones will file a ticket to create sponsor-feedback alias that will contain packager-sponsor-members and fesco-list * notting will fwd the feedback e-mails to the fesco list * sgallagh to be chair on 2011-08-29 meeting * nirik to be chair next week - on 2011-08-22 meeting Action Items, by person --- * nirik * nirik to be chair next week - on 2011-08-22 meeting * notting * notting will fwd the feedback e-mails to the fesco list * pjones * pjones will file a ticket to create sponsor-feedback alias that will contain packager-sponsor-members and fesco-list * sgallagh * sgallagh to be chair on 2011-08-29 meeting * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (60) * sgallagh (56) * t8m (48) * pjones (27) * notting (9) * cwickert (8) * ajax (5) * zodbot (4) * mmaslano (4) * gholms (1) * jsmith (1) * mjg59 (0) - 17:00:01 t8m #startmeeting FESCO (2011-08-15) 17:00:01 zodbot Meeting started Mon Aug 15 17:00:01 2011 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:09 * sgallagh is here 17:00:14 * ajax waves 17:00:17 t8m #meetingname fesco 17:00:17 zodbot The meeting name has been set to 'fesco' 17:00:18 * mmaslano is here 17:00:24 t8m #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 17:00:24 zodbot Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:00:25 * pjones is here eagerly awaiting this exciting agenda. 17:00:30 t8m #topic init process 17:00:44 t8m Hi all 17:00:48 * nirik is here. 17:00:50 * notting is here 17:01:01 * jsmith is here (lurking) 17:01:10 t8m So we can start I assume 17:02:17 t8m there are no meeting tickets so this will be really fast 17:02:26 gholms Seriously? Nice. 17:02:44 * nirik nods. 17:02:45 sgallagh Well, I have one thing to bring up in the open discussion period 17:02:45 notting i thought nirik was having a followup from last week about fesco members in/not in provenpackager/sponsors? 17:02:54 t8m (except for my extremely lousy internet connection today) 17:03:11 nirik Oh yeah. I looked for that, but couldn't find it in old meeting logs... ;( 17:03:28 nirik so, I think we will need to draft up something and this time document it. ;) 17:03:30 t8m notting, yes, I saw that in last week meeting log 17:04:02 * cwickert is here 17:04:06 t8m anyone to write the draft? 17:04:59 nirik I've not. What do folks think about this? 17:05:06 sgallagh Did we decide on the main points? Are we automatically granting provenpackager/sponsor to FESCo members? 17:05:14 sgallagh Do they keep it outside of their terms? 17:05:20 sgallagh Also, what about proventester? 17:05:25 t8m #topic FESCo members in/not in provenpackager/sponsors 17:05:40 nirik provenpackager you mean? 17:06:08 t8m nirik, I think he really means proventester 17:06:14 sgallagh nirik: No, I mean if we're going to be automatically granting provenpackager and sponsor, should we also be proventesters? 17:06:15 t8m as well 17:06:26 nirik proventester is trivial to become. 17:06:31 cwickert is there something I can read to get the background of this? 17:06:37 nirik file ticket, agree you read the page, done. 17:06:54 nirik cwickert: the question came up last time that some fesco members are not sponsors. 17:07:04 nirik so they don't see the feedback on sponsor/provenpackager requests 17:07:11 sgallagh Or even provenpackager (as in my case) 17:07:15 nirik that is sent to the sponsor alias. 17:07:28 cwickert and where is the problem with that? 17:08:05 nirik cwickert: then they have difficulty voting on
Re: To Require or not to Require?
On Sat, 2011-08-13 at 09:19 +0200, Michael Schwendt wrote: On Fri, 12 Aug 2011 12:08:50 -0400, SS (Simo) wrote: If rpmbuild does not add an implicit requires with libraryX = version we built against then it is certainly broken. One could also argue that an activity like yum install ... ought to search for and apply the latest available updates of needed packages. Such behaviour has been rejected some years ago, if memory serves correctly. It was rejected with good reason, I think. I do not think we should be adding functionality into yum which: 1. violates the principle of least surprise for the admin 2. covers up for not-specific-enough requirements in the packaging. It just feels like it would be fixing a problem at the wrong layer. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 730279] perlbrew-0.28 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=730279 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #11 from Fedora Update System upda...@fedoraproject.org 2011-08-15 16:25:17 EDT --- Package perlbrew-0.28-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perlbrew-0.28-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perlbrew-0.28-1.fc16 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Test-Announce] Fedora 16 Alpha Release Candidate 4 (RC4) Available Now!
As per the Fedora 16 schedule [1], Fedora 16 Alpha Release Candidate 4 (RC4) is now available for testing. Please see the following pages for download links and testing instructions. In general, official live images arrive a few hours after the install images: see the links below for updates. When they appear, the download directory should be the same as that for install images, except with the trailing /Fedora/ replaced by /Live/. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Security Lab: https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. task#23: Create Fedora 16 Alpha release candidate (RC) - live and traditional https://fedorahosted.org/rel-eng/ticket/4859 F16 Alpha Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713560 F16 Alpha Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713563 [1] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ 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
packaging wxPdfDocument
Hey all, I would like to package wxPdfDocument [1], a class library for creating PDF documents in a C++ application. As I use it in production environments since 2009 with no problems, I would like to package it for Fedora in order to have it available in the official repos. The review request is at [2]. It currently builds successfully under i686 but not in x86_64 because of a /usr/lib - /usr/lib64 dir name issue. But I read this morning how to solve it in another message in this list, so I will test it on an x86_64 machine as soon as I can. [1] http://wxcode.sourceforge.net/components/wxpdfdoc/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=730764 kind regards Domingo Becker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Rapid DHCP
On Wed, 2011-08-03 at 13:43 -0400, Nathaniel McCallum wrote: On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle b...@bfccomputing.com wrote: On 08/03/2011 01:19 PM, Dan Williams wrote: The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing. Nice, that will help almost everybody, but possibly it could break somebody who's depending explicitly on IPv6 (or IPv4 in the other case) for an app and now thinks the network is up. How do apps, e.g. Thunderbird, know when they're online? dbus, /sys? If this change happens, there ought to be a way for that small slice of apps to check to see that the stack they demand is really up, if they're depending on it (more directly than parsing text output of userland tools). Probably this already exists, right? It seems like NM's state transitions need to become more explicit. 1. IPv4 connected 2. IPv6 connected 3. internet connected (including proxy discovery) I wrote a blog post about this: http://blogs.gnome.org/dcbw/2011/06/14/networkmanager-and-dual-stack-addressing/ And we could do this. But it's unlikely that app authors would actually are about this en masse since it's more than just a single yes/no sort of thing. Next, you've got DNS lookups which can be either IPv4 or IPv6 depending on what the DNS server returns; if you do an IPv4 request and the site's DNS server returns an record, what do you do with that if you don't have IPv6 connectivity yet? Basically it just gets more complicated, and I'm not optimistic that app authors will really hook into the additional information. But it may still be worth trying. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To Require or not to Require?
On Mon, 15 Aug 2011 16:20:47 -0400, SV (seth) wrote: On Sat, 2011-08-13 at 09:19 +0200, Michael Schwendt wrote: On Fri, 12 Aug 2011 12:08:50 -0400, SS (Simo) wrote: If rpmbuild does not add an implicit requires with libraryX = version we built against then it is certainly broken. One could also argue that an activity like yum install ... ought to search for and apply the latest available updates of needed packages. Such behaviour has been rejected some years ago, if memory serves correctly. It was rejected with good reason, I think. I do not think we should be adding functionality into yum which: 1. violates the principle of least surprise for the admin 2. covers up for not-specific-enough requirements in the packaging. Well, I can understand that point of view partially. The rationale isn't entirely convincing, though. The more explicitly versioned dependencies we would add to packages (either manually or automatically during rpmbuild), the more updates a yum install would pull in. It won't be a full update, but could break other installed packages. Running out-of-date installations is not only a problem when a newly installed package works only with latest updates. Ordinary bugs in dependencies can also be a reason why the newly installed package will need a full yum update before it would work [at all or correctly]. Ever seen users with an app startup crash and yum update APP-PKG-NAME not fixing it becuase yum update LIB-PKG-NAME was necessary? It just feels like it would be fixing a problem at the wrong layer. Where is the right layer? Do we need to adjust the packaging policies wrt updates? Fedora 15 by default displays update notifications less frequently. The package installer could at least notify the user about available updates immediately after installing a package. Some updates could be important, especially if they are a dependency of the newly installed package. Users with out-of-date installations often are harder to support not just because of old issues they run into. If application misbehaviour is fixed in a system library, there is a library package update, but the application package normally isn't rebuilt just to add to it a specific-enough requirement on the updated library. This isn't limited to one programming language. Even a Python app could crash at run-time because of a bug in a Python module with an update that has not been installed yet. I think we are ill-advised if we publish a steady flood of updates (even for old dist releases), but want users to install updates less frequently. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc causing crashes in most anything that does DNS lookups in F16
On Mon, 2011-08-08 at 15:24 -0700, Adam Williamson wrote: Hey, folks. So lately Firefox has been crashing a ton for me on F16 (and Evolution's been disappearing silently too - bet it's the same cause). Today I fired it up from a console and found out what the error was: __libc_res_nquery: Assertion `hp != hp2' failed. then I tried to use Epiphany for a bit and found it was crashing on exactly the same error! A bit of detective work led to: https://bugs.archlinux.org/task/24615 apparently Arch has been seeing the same thing. They've addressed it by reverting the following upstream glibc commit: http://sourceware.org/git/?p=glibc.git;a=commit;h=4769ae77fc6c8dacea6476addb015c8797848cdd I've just built an F16 glibc with that reversion to test locally, haven't installed it yet. Just wanted to flag this up and see if anyone else has seen the same thing, and whether we should just revert the change in Fedora, fix it, deal with upstream or what... I suspect it may be a _bit_ more complicated than 'any failed DNS query invariably causes app to crash in all situations', as I'd have expected a bit more of an outcry. But I'm certainly getting a ton of crashes here. It may depend a little on exact DNS server configuration or something. So Shawn Starr mentioned on IRC that his Firefox was crashing a ton in F16, and sure enough, when I asked him to run from a console, turned out he was hitting this. He found an upstream report with a patch: http://sourceware.org/bugzilla/show_bug.cgi?id=13013 it'd be great if we could get that into Fedora glibc. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Rapid DHCP
On Mon, Aug 15, 2011 at 05:25:49PM -0500, Dan Williams wrote: On Wed, 2011-08-03 at 13:43 -0400, Nathaniel McCallum wrote: On Wed, Aug 3, 2011 at 1:38 PM, Bill McGonigle b...@bfccomputing.com wrote: On 08/03/2011 01:19 PM, Dan Williams wrote: The Ubuntu NM maintainer has posted a WIP patch that makes NM say it's connected immediately if at least one of IPv4 or IPv6 completes. Currently if both are enabled, NM won't say it's connected until both are done (and result in either success or failure). That at least speeds up the perceived connection speed, which isn't a bad thing. Nice, that will help almost everybody, but possibly it could break somebody who's depending explicitly on IPv6 (or IPv4 in the other case) for an app and now thinks the network is up. How do apps, e.g. Thunderbird, know when they're online? dbus, /sys? If this change happens, there ought to be a way for that small slice of apps to check to see that the stack they demand is really up, if they're depending on it (more directly than parsing text output of userland tools). Probably this already exists, right? It seems like NM's state transitions need to become more explicit. 1. IPv4 connected 2. IPv6 connected 3. internet connected (including proxy discovery) I wrote a blog post about this: http://blogs.gnome.org/dcbw/2011/06/14/networkmanager-and-dual-stack-addressing/ And we could do this. But it's unlikely that app authors would actually are about this en masse since it's more than just a single yes/no sort of thing. Next, you've got DNS lookups which can be either IPv4 or IPv6 depending on what the DNS server returns; if you do an IPv4 request and the site's DNS server returns an record, what do you do with that if you don't have IPv6 connectivity yet? Basically it just gets more complicated, and I'm not optimistic that app authors will really hook into the additional information. But it may still be worth trying. Have you seen the IETF's Happy Eyeballs drafts? It explains how to implement apps and systems to provide the best user experience in the face of various IPv4 + IPv6 connectivity combinations. http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-03 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 730658] New: Unbundle DateTime::Locale and DateTime::TimeZone
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Unbundle DateTime::Locale and DateTime::TimeZone https://bugzilla.redhat.com/show_bug.cgi?id=730658 Summary: Unbundle DateTime::Locale and DateTime::TimeZone Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-DateTime AssignedTo: st...@silug.org ReportedBy: iarn...@gmail.com QAContact: extras...@fedoraproject.org CC: st...@silug.org, iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Our perl-DateTime package bundles DateTime::Locale and DateTime::TimeZone. To simplify maintenance, I would like to unbundle them and maintain them as separate packages. (DateTime::TimeZone gets updated fairly frequently, but it's not possible to get automatic notifications from Upstream Release Monitoring, for example). It's also worth noting that neither suse nor debian bundle these modules. The original rationale for bundling was due to circular (build) dependencies. This no longer applies for DateTime::Locale (DateTime::Locale does not require DateTime). For DateTime::TimeZone, the circular dependencies can temporarily be avoided using perl_bootstrap macro and appropriate filtering. I've filed bug 730656 and bug 730657 for review of new perl-DateTime-Locale and perl-DateTime-TimeZone packages. -- 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 730658] Unbundle DateTime::Locale and DateTime::TimeZone
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=730658 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Blocks||730656, 730657 -- 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 730658] Unbundle DateTime::Locale and DateTime::TimeZone
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=730658 --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-08-15 05:40:40 EDT --- I've prepared an updated spec that only includes DateTime. And since upstream doesn't appear to have used 4 digits in the version number for a couple of years, now, I think it's worthwhile bumping epoch again and reverting to upstream's 2 digit version number. Spec URL: http://iarnell.home.xs4all.nl/review/perl-DateTime.spec SRPM URL: http://iarnell.home.xs4all.nl/review/perl-DateTime-0.70-1.fc17.src.rpm -- 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 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 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Shipwright-2.4.29 is |perl-Shipwright-2.4.30 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-08-15 06:45:48 EDT --- Latest upstream release: 2.4.30 Current version in Fedora Rawhide: 2.4.28 URL: http://search.cpan.org/dist/Shipwright/ 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 715559] perl-Mojolicious-1.77 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=715559 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-1.76 is|perl-Mojolicious-1.77 is |available |available --- Comment #15 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-08-15 06:44:16 EDT --- Latest upstream release: 1.77 Current version in Fedora Rawhide: 1.65 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
[Bug 730658] Unbundle DateTime::Locale and DateTime::TimeZone
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=730658 Petr Sabata psab...@redhat.com changed: What|Removed |Added CC||psab...@redhat.com --- Comment #2 from Petr Sabata psab...@redhat.com 2011-08-15 06:45:50 EDT --- (In reply to comment #0) I've filed bug 730656 and bug 730657 for review of new perl-DateTime-Locale and perl-DateTime-TimeZone packages. I'll take a look at those. -- 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 730658] Unbundle DateTime::Locale and DateTime::TimeZone
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=730658 --- Comment #3 from Iain Arnell iarn...@gmail.com 2011-08-15 06:53:41 EDT --- Thanks, Petr. Unless Steve shows up, I would also appreciate a review of the changes here too. It's not strictly required, but I basically rebuilt the spec from scratch, so I think having a second pair of eyes take a look would be sensible. -- 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the rawhide 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 rawhide 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
Re: Switch use in awstats
On 08/13/2011 06:07 PM, Emmanuel Seyman wrote: Hi, Petr. I noticed yesterday that you had patched awstats to use if statements instead of the switch module. The switch module is now back in Fedora (it was removed from Perl core in 5.14 and is now a package in its own right) so feel free to remove your patch, awstats should build fine without it. Emmanuel Hello Emmanuel, I didn't package Switch module on purpose. Switch was removed from perl core, because it had a lot of bug reports. I suppose using if-else is safer. Switch was packaged last week by spot, so maintainers could use it, but they don't have to if they wish. Best regards, Marcela -- 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 730658] Unbundle DateTime::Locale and DateTime::TimeZone
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=730658 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|st...@silug.org |psab...@redhat.com --- Comment #4 from Petr Sabata psab...@redhat.com 2011-08-15 08:43:49 EDT --- (In reply to comment #3) Thanks, Petr. Unless Steve shows up, I would also appreciate a review of the changes here too. It's not strictly required, but I basically rebuilt the spec from scratch, so I think having a second pair of eyes take a look would be sensible. Sure, no problem :) -- 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
Re: Switch use in awstats
2011/8/15 Marcela Mašláňová mmasl...@redhat.com: On 08/13/2011 06:07 PM, Emmanuel Seyman wrote: Hi, Petr. I noticed yesterday that you had patched awstats to use if statements instead of the switch module. The switch module is now back in Fedora (it was removed from Perl core in 5.14 and is now a package in its own right) so feel free to remove your patch, awstats should build fine without it. Emmanuel Hello Emmanuel, I didn't package Switch module on purpose. Switch was removed from perl core, because it had a lot of bug reports. I suppose using if-else is safer. Switch was packaged last week by spot, so maintainers could use it, but they don't have to if they wish. Or use Perl's native switch syntax: given/when. See Switch statements in perlsyn for details. -- Iain. -- 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
Re: Switch use in awstats
On 08/15/2011 03:04 PM, Iain Arnell wrote: 2011/8/15 Marcela Mašláňová mmasl...@redhat.com: On 08/13/2011 06:07 PM, Emmanuel Seyman wrote: Hi, Petr. I noticed yesterday that you had patched awstats to use if statements instead of the switch module. The switch module is now back in Fedora (it was removed from Perl core in 5.14 and is now a package in its own right) so feel free to remove your patch, awstats should build fine without it. Emmanuel Hello Emmanuel, I didn't package Switch module on purpose. Switch was removed from perl core, because it had a lot of bug reports. I suppose using if-else is safer. Switch was packaged last week by spot, so maintainers could use it, but they don't have to if they wish. Or use Perl's native switch syntax: given/when. See Switch statements in perlsyn for details. Um, given/when have almost the same amount of bugs ;-) I'm not saying do not use new syntax. But as a maintainer of many packages I prefer older syntax. -- 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-Perlbal-XS-HTTPHeaders
perl-Perlbal-XS-HTTPHeaders has broken dependencies in the F-16 tree: On x86_64: perl-Perlbal-XS-HTTPHeaders-0.20-3.fc15.x86_64 requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Perlbal-XS-HTTPHeaders-0.20-3.fc15.i686 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-Shipwright
perl-Shipwright has broken dependencies in the F-16 tree: On x86_64: perl-Shipwright-2.4.24-2.fc16.noarch requires perl(that) On i386: perl-Shipwright-2.4.24-2.fc16.noarch requires perl(that) 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-Eval-LineNumbers
perl-Eval-LineNumbers has broken dependencies in the F-16 tree: On x86_64: perl-Eval-LineNumbers-0.31-1.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Eval-LineNumbers-0.31-1.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-CGI-Application-Structured-Tools
perl-CGI-Application-Structured-Tools has broken dependencies in the F-16 tree: On x86_64: perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires perl(tmpl_var) perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires main_module) perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires perl(tmpl_var On i386: perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires perl(tmpl_var) perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires main_module) perl-CGI-Application-Structured-Tools-0.013-3.fc16.noarch requires perl(tmpl_var 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
Re: Duplicate perl packages - perl-Compress-Raw-Zlib
On Aug 15, 2011, at 10:07 AM, Marcela Mašláňová wrote: On 08/15/2011 06:42 PM, Jesse Keating wrote: Does anybody know what's going on with this? Base perl has a sub package for perl-Compress-Raw-Zlib (which gets its own version numbering). It seems to have been there for quite a while. Recently (March of last year) perl-Compress-Raw-Zlib was brought in as its own package (https://bugzilla.redhat.com/show_bug.cgi?id=573929) but the existing sub package was never removed, and exists to this day. Can somebody tell me what's going on here? Which one is the true package, which one needs to go away? I care because now we have mismatched version numbers for this package, and it is causing some interesting scenarios when trying to use Fedora repos as a koji external repo. There may be more cases of this, I haven't done an exhaustive search. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating Updates of core modules were sometimes hard and we used this approach few last releases: https://fedoraproject.org/wiki/Perl/updates#Updates_of_Perl_core_modules It should be working in rpm, but I wasn't aware of koji problems. I suppose that now we can live without dual life modules, because Perl modules in core are updated more often. But I'd rather discuss it with Perl SIG members before any action. Upon further looking at the koji problem, these packages may not actually be causing my root issue, since they do come from separate SRPMs. However I am curious if this strategy has ever gone though the packaging committee, releng, or fesco. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- 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
Re: Duplicate perl packages - perl-Compress-Raw-Zlib
On 08/15/2011 07:07 PM, Marcela Mašláňová wrote: On 08/15/2011 06:42 PM, Jesse Keating wrote: Does anybody know what's going on with this? Base perl has a sub package for perl-Compress-Raw-Zlib (which gets its own version numbering). It seems to have been there for quite a while. Recently (March of last year) perl-Compress-Raw-Zlib was brought in as its own package (https://bugzilla.redhat.com/show_bug.cgi?id=573929) but the existing sub package was never removed, and exists to this day. Can somebody tell me what's going on here? Which one is the true package, which one needs to go away? I care because now we have mismatched version numbers for this package, and it is causing some interesting scenarios when trying to use Fedora repos as a koji external repo. There may be more cases of this, I haven't done an exhaustive search. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating Updates of core modules were sometimes hard and we used this approach few last releases: https://fedoraproject.org/wiki/Perl/updates#Updates_of_Perl_core_modules It should be working in rpm, but I wasn't aware of koji problems. I suppose that now we can live without dual life modules, because Perl modules in core are updated more often. But I'd rather discuss it with Perl SIG members before any action. There are two solutions: a/ don't ship sub-package from core perl and override them by package in Fedora. This will work well for perl-Compress-Raw-Zlib - 2.033 in perl, 2.037 in separated package, but we will have borken debuginfo. b/ remove dual life modules, which are outside of perl - will solve problem of broken debuginfo https://bugzilla.redhat.com/show_bug.cgi?id=694704 Removal doesn't work for perl-Compress-Raw-Zlib, but it might work for other packages. Core modules are now updated more often, so we might not need dual life process. Opinions? Better proposal? -- Marcela Mašláňová BaseOS team Brno -- 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
Re: Duplicate perl packages - perl-Compress-Raw-Zlib
2011/8/15 Marcela Mašláňová mmasl...@redhat.com: There are two solutions: a/ don't ship sub-package from core perl and override them by package in Fedora. This will work well for perl-Compress-Raw-Zlib - 2.033 in perl, 2.037 in separated package, but we will have borken debuginfo. Doesn't broken debuginfo only come into play if we install the package from cpan into core archlib directory. As long as we keep it in separate vendorarch, there's no problem. b/ remove dual life modules, which are outside of perl - will solve problem of broken debuginfo https://bugzilla.redhat.com/show_bug.cgi?id=694704 Removal doesn't work for perl-Compress-Raw-Zlib, but it might work for other packages. Core modules are now updated more often, so we might not need dual life process. Anything but this. We *will* end up wanting newer versions at some point and be forced to go back to using unwieldy patches in perl.spec again. Opinions? Better proposal? Well, since Jesse then came back and wrote that koji doesn't seem to be affected after all: Upon further looking at the koji problem, these packages may not actually be causing my root issue, since they do come from separate SRPMs. How about option (c). Keep things just as they are? Or if there is a problem with koji, how about (d) fix koji. It's a broken assumption that only binary sub-packages from a single source rpm can exist in an external repo (I use koji at work to build packages against SLES - Novell has a habit of releasing only affected sub-packages as updates - if they fix a problem that only affects bind-libs, for example, you'll only see a new bind-libs rpm in their updates repo and be expected to install that with the original base package. I'm fairly certain that I patched mergerepo to ignore this restriction). -- Iain. -- 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
