rawhide report: 20110518 changes
Compose started at Wed May 18 08:15:03 UTC 2011 Broken deps for x86_64 -- R-Rsolid-0.9.31-2.fc15.x86_64 requires libhdf5.so.6()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-10.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) 1:anerley-0.2.14-5.fc15.i686 requires libcamel-1.2.so.23 1:anerley-0.2.14-5.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) beldi-0.9.25-3.fc15.x86_64 requires libhal-storage.so.1()(64bit) beldi-0.9.25-3.fc15.x86_64 requires libhal.so.1()(64bit) beldi-0.9.25-3.fc15.x86_64 requires hal callweaver-javascript-1.2.1-8.fc16.x86_64 requires libjs.so.1()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) cyphesis-0.5.24-3.fc15.x86_64 requires libwfmath-0.3.so.4()(64bit) cyphesis-0.5.24-3.fc15.x86_64 requires libskstream-0.3.so.4()(64bit) cyphesis-0.5.24-3.fc15.x86_64 requires libmercator-0.2.so.6()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.0-8.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) evolution-couchdb-0.5.3-1.fc16.x86_64 requires libcamel-provider-1.2.so.23()(64bit) evolution-couchdb-0.5.3-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) evolution-rss-0.2.90-19.20110307git.fc16.x86_64 requires libcamel-provider-1.2.so.23()(64bit) evolution-rss-0.2.90-19.20110307git.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) evolution-sharp-0.21.1-12.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal 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.i686 requires libgvc.so.5 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-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gdl-0.9.1-2.fc16.x86_64 requires libhdf5.so.6()(64bit) gdl-python-0.9.1-2.fc16.x86_64 requires libhdf5.so.6()(64bit) gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) giggle-0.5-4.fc15.i686 requires libcamel-1.2.so.23 giggle-0.5-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-device-manager-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-devel-0.2-6.fc15.i686 requires hal-devel = 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.i686 requires pkgconfig(hal) gnome-device-manager-devel-0.2-6.fc15.x86_64 requires hal-devel = 0:0.5.10 gnome-device-manager-devel-0.2-6.fc15.x86_64 requires pkgconfig(hal) gnome-device-manager-libs-0.2-6.fc15.i686 requires libhal.so.1 gnome-device-manager-libs-0.2-6.fc15.i686 requires hal = 0:0.5.10 gnome-device-manager-libs-0.2-6.fc15.x86_64 requires libhal.so.1()(64bit) gnome-device-manager-libs-0.2-6.fc15.x86_64 requires hal = 0:0.5.10 gnome-launch-box-0.4-20.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-phone-manager-0.66-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-phone-manager-telepathy-0.66-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-eds-2.91.92-1.fc16.x86_64 requires libcamel-1.2.so.23()(64bit) gnome-python2-applet-2.32.0-1.fc14.x86_64 requires
Re: glibc-2.13.90-12 needs testing - re-adds RPC API
On Mon, 2011-05-16 at 14:26 -0400, Bill Nottingham wrote: Notably, this re-adds the RPC API to glibc's exported interface, so please test that rebuilding your applications still works, or works again. https://admin.fedoraproject.org/updates/glibc-2.13.90-12 there is number of headers that are no longer in glibc-headers (see comments in the link above). This is not surprise some builds fail. Is it somewhere documented? What about replacement? Is someone preparing -devel package containing missing headers? Thanks, Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to build noarch package on only certain architectures?
On Tuesday, May 17, 2011 10:43:47 AM Richard W.M. Jones wrote: On Tue, May 17, 2011 at 09:33:51AM -0400, Josh Boyer wrote: On Tue, May 17, 2011 at 9:28 AM, Kevin Fenzi ke...@scrye.com wrote: Is there some other way to add a noarch package that doesn't build on some architectures? Sadly this is a nasty situation. (I'm in the same boat with munin). There are 2 answers, neither ideal (I'd love to hear better): 1. Make your package archfull. Add ExcludeArch/ExclusiveArch. 2. Leave it noarch and ExcludeArch: ppc64, then try and keep rebuilding it until you hit a non ppc builder. 3. See if you can modify the package to do runtime determinism of whether the dependency is there, and only use that functionality if it's present. Personally I think that if that can't be done, then option 1 is the right way to go. 4. Post a patch to fix RPM. This is a bug or shortcoming in RPM. It affected some mingw32 packages as well IIRC -- they are noarch and can be built anywhere, but we wanted to %check them using wine which only runs on i386. Rich. make it archeful with a noarch subpackage that has the noarch bits. if you do it ExclusiveArch for the base arch you want it built on it would work as you want Dennis 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: F-15 Branched report: 20110517 changes
On Tuesday, May 17, 2011 08:46:15 PM Kevin Kofler wrote: Branched Report wrote: Broken deps for x86_64 Are we going to get these uninstallable packages cleared up from the Everything tree before sending the release to the mirrors? Otherwise, they're going to come haunt us at each and every depcheck for F15+updates. (AFAIK, at least repoclosure still complains even when the dependency is fixed in updates.) Updated Packages: Uhm, what's up with these? Were they already used in the RC3 compose? Are we getting an RC4 after all? It's quite surprising to see 4 updates pushed to Branched after the mail declaring the release gold. Kevin Kofler They were in RC3 but did not have the karma to get pushed to stable when i pushed the builds we included for blockers. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 704221] missing the Joystick.pm module
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=704221 Hans de Goede hdego...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG Last Closed||2011-05-18 10:19:47 --- Comment #1 from Hans de Goede hdego...@redhat.com 2011-05-18 10:19:47 EDT --- The upstream 2.1.3 SDL_Perl tarbal does not contain a Joystick.pm file, neither does the 2.2.6 version. We cannot include that which is not there in the package. -- 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
[Bug 704221] missing the Joystick.pm module
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=704221 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com --- Comment #2 from Iain Arnell iarn...@gmail.com 2011-05-18 10:39:55 EDT --- Upstream seems to have renamed the distribution to SDL rather than SDL_Perl. http://search.cpan.org/~kthakore/SDL-2.532/ does contain SDL::Joystick. -- 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
Re: F-15 Branched report: 20110515 changes
On Tue, May 17, 2011 at 11:33:35 -0400, Tom Callaway tcall...@redhat.com wrote: Lately, I've been trying to resolve as many of these as reasonably possible. Here's what I know: sear-0.6.3-14.fc12.x86_64 requires liberis-1.3.so.15()(64bit) https://admin.fedoraproject.org/updates/sear-0.6.3-18.fc15 Going forward sear will get more attention from me. I have most of the worldforge stack updated in rawhide. I still need to do cyphesis and sear, but the rest are current upstream releases. sunbird-1.0-0.33.b2pre.fc15.x86_64 requires libnotify.so.1()(64bit) Probably should be removed/obsoleted by lightning/thunderbird. I think the probably can be dropped. See: https://bugzilla.redhat.com/show_bug.cgi?id=684377 Upstream support for the standalone client has been dropped. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Build failing - ld aborting
2 for 2 now: libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/4.6.0/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.6.0/crtbeginS.o .libs/assocdata.o .libs/basic_fun_cl.o .libs/basic_fun.o .libs/basic_fun_jmg.o .libs/basic_op.o .libs/basic_pro.o .libs/basic_pro_jmg.o .libs/CFMTLexer.o .libs/color.o .libs/convert2.o .libs/datatypes.o .libs/dcommon.o .libs/dcompiler.o .libs/default_io.o .libs/dinterpreter.o .libs/dnode.o .libs/dpro.o .libs/dstructdesc.o .libs/dstructgdl.o .libs/dvar.o .libs/envt.o .libs/extrat.o .libs/FMTIn.o .libs/FMTLexer.o .libs/fmtnode.o .libs/FMTOut.o .libs/FMTParser.o .libs/gdleventhandler.o .libs/gdlexception.o .libs/gdlgstream.o .libs/GDLInterpreter.o .libs/GDLLexer.o .libs/GDLParser.o .libs/gdlpsstream.o .libs/gdlsvgstream.o .libs/gdlpython.o .libs/GDLTreeParser.o .libs/gdlwinstream.o .libs/gdlxstream.o .libs/getfmtast.o .libs/graphics.o .libs/gsl_fun.o .libs/ifmt.o .libs/initct.o .libs/initsysvar.o .libs/io.o .libs/libinit_cl.o .libs/libinit.o .libs/libinit_jmg.o .libs/math_fun.o .libs/math_fun_jmg.o .libs/math_utl.o .libs/ncdf_att_cl.o .libs/ncdf_cl.o .libs/ncdf_dim_cl.o .libs/ncdf_var_cl.o .libs/new.o .libs/objects.o .libs/ofmt.o .libs/math_fun_ac.o .libs/libinit_ac.o .libs/math_fun_gm.o .libs/libinit_gm.o .libs/math_fun_ng.o .libs/libinit_ng.o .libs/plotting.o .libs/print.o .libs/print_tree.o .libs/read.o .libs/str.o .libs/terminfo.o .libs/topython.o .libs/typetraits.o .libs/hdf_fun.o .libs/hdf_pro.o .libs/magick_cl.o .libs/gdlwidget.o .libs/widget.o .libs/basegdl.o .libs/hdf5_fun.o .libs/libinit_mes.o .libs/file.o .libs/image.o .libs/gdljournal.o .libs/convol.o .libs/convol_inc0.o .libs/convol_inc1.o .libs/convol_inc2.o .libs/sigfpehandler.o .libs/gdlzstream.o .libs/arrayindex.o .libs/fftw.o .libs/mpi.o .libs/plot3d_nr.o .libs/grib.o .libs/prognode.o .libs/prognodeexpr.o .libs/datatypesref.o .libs/lapack.o .libs/gshhs.o .libs/newprognode.o .libs/pythongdl.o -lantlr -L/usr/X11R6/lib64 -L/usr/X11R6/lib -lX11 -lncurses -L/usr/lib/hdf -ldl -lreadline -lgsl -lgslcblas -lplplotd -lplplotcxxd -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lMagick++ -lMagickCore -lnetcdf /usr/lib/hdf/libmfhdf.a /usr/lib/hdf/libdf.a -ljpeg -lz -L/usr/lib/hdf5 -lhdf5 -lfftw3 -lfftw3f -lpython2.7 -ludunits2 -lgrib_api -ljasper -L/usr/lib/gcc/i686-redhat-linux/4.6.0 -L/usr/lib/gcc/i686-redhat-linux/4.6.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-redhat-linux/4.6.0/crtendS.o /usr/lib/gcc/i686-redhat-linux/4.6.0/../../../crtn.o -O2 -m32 -march=i686 -mtune=atom -Wl,-z -Wl,muldefs -pthread -pthread -Wl,-soname -Wl,libgdl.so.0 -o .libs/libgdl.so.0.0.0 collect2: ld terminated with signal 6 [Aborted] Any ideas what might cause this? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build failing - ld aborting
On 05/18/2011 03:47 PM, Orion Poplawski wrote: 2 for 2 now: libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/4.6.0/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.6.0/crtbeginS.o .libs/assocdata.o .libs/basic_fun_cl.o .libs/basic_fun.o .libs/basic_fun_jmg.o .libs/basic_op.o .libs/basic_pro.o .libs/basic_pro_jmg.o .libs/CFMTLexer.o .libs/color.o .libs/convert2.o .libs/datatypes.o .libs/dcommon.o .libs/dcompiler.o .libs/default_io.o .libs/dinterpreter.o .libs/dnode.o .libs/dpro.o .libs/dstructdesc.o .libs/dstructgdl.o .libs/dvar.o .libs/envt.o .libs/extrat.o .libs/FMTIn.o .libs/FMTLexer.o .libs/fmtnode.o .libs/FMTOut.o .libs/FMTParser.o .libs/gdleventhandler.o .libs/gdlexception.o .libs/gdlgstream.o .libs/GDLInterpreter.o .libs/GDLLexer.o .libs/GDLParser.o .libs/gdlpsstream.o .libs/gdlsvgstream.o .libs/gdlpython.o .libs/GDLTreeParser.o .libs/gdlwinstream.o .libs/gdlxstream.o .libs/getfmtast.o .libs/graphics.o .libs/gsl_fun.o .libs/ifmt.o .libs/initct.o .libs/initsysvar.o .libs/io.o .libs/libinit_cl.o .libs/libinit.o .libs/libinit_jmg.o .libs/math_fun.o .libs/math_fun_jmg.o .libs/math_utl.o .libs/ncdf_att_cl.o .libs/ncdf_cl.o .libs/ncdf_dim_cl.o .libs/ncdf_var_cl.o .libs/new.o .libs/objects.o .libs/ofmt.o .libs/math_fun_ac.o .libs/libinit_ac.o .libs/math_fun_gm.o .libs/libinit_gm.o .libs/math_fun_ng.o .libs/libinit_ng.o .libs/plotting.o .libs/print.o .libs/print_tree.o .libs/read.o .libs/str.o .libs/terminfo.o .libs/topython.o .libs/typetraits.o .libs/hdf_fun.o .libs/hdf_pro.o .libs/magick_cl.o .libs/gdlwidget.o .libs/widget.o .libs/basegdl.o .libs/hdf5_fun.o .libs/libinit_mes.o .libs/file.o .libs/image.o .libs/gdljournal.o .libs/convol.o .libs/convol_inc0.o .libs/convol_inc1.o .libs/convol_inc2.o .libs/sigfpehandler.o .libs/gdlzstream.o .libs/arrayindex.o .libs/fftw.o .libs/mpi.o .libs/plot3d_nr.o .libs/grib.o .libs/prognode.o .libs/prognodeexpr.o .libs/datatypesref.o .libs/lapack.o .libs/gshhs.o .libs/newprognode.o .libs/pythongdl.o -lantlr -L/usr/X11R6/lib64 -L/usr/X11R6/lib -lX11 -lncurses -L/usr/lib/hdf -ldl -lreadline -lgsl -lgslcblas -lplplotd -lplplotcxxd -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lMagick++ -lMagickCore -lnetcdf /usr/lib/hdf/libmfhdf.a /usr/lib/hdf/libdf.a -ljpeg -lz -L/usr/lib/hdf5 -lhdf5 -lfftw3 -lfftw3f -lpython2.7 -ludunits2 -lgrib_api -ljasper -L/usr/lib/gcc/i686-redhat-linux/4.6.0 -L/usr/lib/gcc/i686-redhat-linux/4.6.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-redhat-linux/4.6.0/crtendS.o /usr/lib/gcc/i686-redhat-linux/4.6.0/../../../crtn.o -O2 -m32 -march=i686 -mtune=atom -Wl,-z -Wl,muldefs -pthread -pthread -Wl,-soname -Wl,libgdl.so.0 -o .libs/libgdl.so.0.0.0 collect2: ld terminated with signal 6 [Aborted] Any ideas what might cause this? A bug in collect2 or the OOM killer. Have a look at the output of dmesg. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 704221] missing the Joystick.pm module
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=704221 --- Comment #3 from Hans de Goede hdego...@redhat.com 2011-05-18 10:52:32 EDT --- (In reply to comment #2) Upstream seems to have renamed the distribution to SDL rather than SDL_Perl. http://search.cpan.org/~kthakore/SDL-2.532/ does contain SDL::Joystick. The problem with releases 2.2.x is that the API has changed and none of the programs in Fedora actually using perl-SDL have been adopted to the new API, which given that the new API is not stable yet (3.0 will be the first release with the new API being stable) is not surprising, see: http://sdl.perl.org/ -- 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
Re: Special thanks to gnome3 and systemd developers
On 05/18/2011 10:20 AM, Bruno Wolff III wrote: While everyone that worked on the F15 release deserves thanks and congrats, I'd like to give a special thanks to the systemd and gnome3 developers because of the large amount of work needed to implement those features. By working hard to get these into F15, they helped meet Fedora's goal of being First. +100 -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build failing - ld aborting
On 05/18/2011 08:48 AM, Andrew Haley wrote: On 05/18/2011 03:47 PM, Orion Poplawski wrote: collect2: ld terminated with signal 6 [Aborted] Any ideas what might cause this? A bug in collect2 or the OOM killer. Have a look at the output of dmesg. Andrew. That was my thought too I guess. On 32-bit only. On my local mock builder I get more information: collect2: ld terminated with signal 6 [Aborted], core dumped *** glibc detected *** /usr/bin/ld: free(): invalid size: 0x0ea8ac18 *** === Backtrace: = /lib/libc.so.6(+0x73055)[0x556f9055] /usr/lib/libbfd-2.21.51.0.9-1.fc16.so(objalloc_free+0x2c)[0x55636ecc] /usr/lib/libbfd-2.21.51.0.9-1.fc16.so(_bfd_delete_bfd+0x3e)[0x555a89de] /usr/lib/libbfd-2.21.51.0.9-1.fc16.so(bfd_close+0x98)[0x555a8e18] /usr/bin/ld[0x804be8c] /lib/libc.so.6(__libc_start_main+0xf3)[0x5569f513] /usr/bin/ld[0x804c2dd] http://sourceware.org/bugzilla/show_bug.cgi?id=12779 https://bugzilla.redhat.com/show_bug.cgi?id=705826 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc-2.13.90-12 needs testing - re-adds RPC API
Jiri Skala (jsk...@redhat.com) said: On Mon, 2011-05-16 at 14:26 -0400, Bill Nottingham wrote: Notably, this re-adds the RPC API to glibc's exported interface, so please test that rebuilding your applications still works, or works again. https://admin.fedoraproject.org/updates/glibc-2.13.90-12 there is number of headers that are no longer in glibc-headers (see comments in the link above). This is not surprise some builds fail. Is it somewhere documented? What about replacement? Is someone preparing -devel package containing missing headers? If there are problems with it, please comment in the update file new bugs... I was just passing the info on. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Security release criterion proposal
Hey, all. The topic of whether and which security issues should block releases has come up several times before. While we haven't actually had many really serious security issues to worry about since the introduction of the current release criteria system, I think it's certainly something we should take into account. At the same time, it's fairly established in practice that we don't just consider anything worth issuing a CVE for as a release-blocking bug. So, to capture what I believe would be the intent of the project, I propose this as an Alpha release criterion for F16 onwards. (For those on devel and security lists who may not be completely familiar with the release criteria / blocker system, this would mean that any bug for an issue which breached the criterion should be considered a release blocker for any Alpha, Beta or Final release). # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release Points to consider: * Possible variants to the type of vulnerability covered...do we also want to make local privesc vulns blocking? Conversely, do we want to make only remote *root* execution vulns blocking? I don't know if anyone would want to go as far as making DoS vulns release blocking, but speak up if you would! (Of course there is again the local/remote distinction to consider there: 'all DoS vulns' would be a much tighter standard than 'remote DoS vulns'). * The caveat about where the issue is exploitable is important because if you can't exploit it from the installer or a live image, it becomes less relevant whether we ship with it or not, because you would be safe with the first post-install update assuming we submitted an update for the issue promptly. But it may be the case that we want to broaden it out to also cover issues that can be exploited from a default DVD install, if we consider the window between install and first update (if updates repos aren't used during installation) to be unacceptable. * We have a system whereby the criteria get more onerous from Alpha to Beta to Final, so it could be the case that we accept worse security issues in Alpha than in Beta and so on; we could have a loose criterion for Alpha and a tighter one for Beta. In this case it felt sensible to me to just go with one criterion, but please say if you disagree. * The aim of the release criteria is more to codify existing practice than to extend it; we have taken security issues as release blockers before and considered but rejected less serious ones, but we have done so on an ad hoc basis. I tried to write the criterion to reflect our past practice on this. So precedents are important here; if you have any that contradict the proposed criterion, please do cite them. Feedback please! Thanks :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release Points to consider: One more 'point to consider' that I forgot: for most things we only consider the 'desktop' and KDE live images as capable of blocking the release, but I thought for security issues it makes sense to broaden this out to all the images we actually ship as part of the release. This is definitely up for debate, though; it would be possible to tighten it down to only desktop and KDE, or to only the most commonly-used spins, or something. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On 05/18/2011 03:57 PM, Adam Williamson wrote: Feedback please! Thanks:) Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with insert type of exploits here )? Don't we need individual(s) from the security team that will be doing actively security audit during the development cycle and reporting back to QA? Would not applying this security release proposal to final only suffice? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, May 18, 2011 at 08:57:17 -0700, Adam Williamson awill...@redhat.com wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release Points to consider: I think there may be some remote exploits that we wouldn't want to block for. For example if wesnoth turns out to be vulnerable to the game server or one of the other clients, I don't thank is something we'd want to block for. If firefox was vulnerable to web pages you visit being able to execute unsandboxed code, then I feel it's a close call. I'd prefer not to limit remote code execution to just root. User data and network bandwidth are valuable. Then we also need to worry about local root exploits being used in combination with non-root remote code exploits. I think it is also worth considering whether the exploits are really exploitable with our default configuration (selinux in enforcing mode). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On 05/18/2011 09:58 PM, Jóhann B. Guðmundsson wrote: On 05/18/2011 03:57 PM, Adam Williamson wrote: Feedback please! Thanks:) Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with insert type of exploits here )? No. SELInux (or firewall) is not a first line of defense. These get turned off by some users and we need to be sure we aren't relying on them solely. If there are important security issues, they should be fixed before release regardless of whether SELinux would mitigate them or not Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 16:28 +, Jóhann B. Guðmundsson wrote: On 05/18/2011 03:57 PM, Adam Williamson wrote: Feedback please! Thanks:) Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with insert type of exploits here )? I kinda considered that to be implicit in the criterion as written, but as two people have asked about it, obviously we should clarify that :) Don't we need individual(s) from the security team that will be doing actively security audit during the development cycle and reporting back to QA? Well, 'enforcing' the criteria is a separate issue from determining them, and we don't really need to discuss it here. Having an explicit criterion adds value even if we don't set up a formal validation system, because it gives us solid ground to review any security issues which get proposed as release blockers on an ad hoc basis. Would not applying this security release proposal to final only suffice? Well, I mean, it depends what you mean by 'suffice' :). I worked on the basis that we probably don't want to ship any widely-distributed 'release' with a major security issue, but as I wrote, it's certainly up for debate. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On 5/18/11 11:57 AM, Adam Williamson wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release Seems reasonable at first glance. One anecdotal experience: FC5 (wow) shipped with an X server that was vulnerable to a local root exploit: due to a bug, normal users could set the X server's module path, and the server would always load a certain module first, so you could just set an ELF constructor that called exec(/bin/sh) and win. The public commit to fix the issue was 20 March 2006, the exact day of the FC5 release, so I suspect we chose the embargo date on that basis. Which, I think, was the right move. The concern I would have with an explicit policy like this is the schedule effects. We would not be able to commit or build a package with the embargoed fix until after the embargo date. _Then_ we compose. Then we test (unless we think existing testing is sufficient). Then we push to mirrors. Then we make the release links public. That whole process is still on the order of a week I think, which is slightly longer than one would desire. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, May 18, 2011 at 10:27:07PM +0530, Rahul Sundaram wrote: On 05/18/2011 09:58 PM, Jóhann B. Guðmundsson wrote: On 05/18/2011 03:57 PM, Adam Williamson wrote: Feedback please! Thanks:) Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with insert type of exploits here )? No. SELInux (or firewall) is not a first line of defense. These get turned off by some users and we need to be sure we aren't relying on them solely. If there are important security issues, they should be fixed before release regardless of whether SELinux would mitigate them or not I have to disagree on this point, I think SELinux and the firewall are in fact valid vulnerability mitigation paths and since they are in fact enabled by default with the release then they should be able to satisfy the requirements for release criteria. I don't think we as a project can handle the long list of what users can and can't do once their system is installed, I personally think that in these release criteria we should focus on what is and isn't vulnerable from a default installation. If a user decides to turn of PackageKit, turn off the firewall, disable SELinux, and not manually pull package updates there's not much we can do for them. (And yes, I am aware this isn't the case you brought up but I'm simply trying to point out the slippery slope of what if the user does X? that we could get ourselves into that would make it difficult for us as a community to QA. Just my opinion ... questions, comments, and snide remarks welcome as always :) -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
Adam Williamson wrote: Hey, all. The topic of whether and which security issues should block releases has come up several times before. Indeed it has. The decision was always that it's not a good idea. I don't see how the situation has changed to warrant beating that dead horse again. # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release. It's impossible to ship an exploit-free release just like it's impossible to ship a bug-free release. We have a process for security fixes, it's called updates. I don't see how a 0-day update wouldn't be an appropriate resolution for a security issue. Now if you are talking about NTH, then yes, security fixes should be NTH. Maybe even all of them. But I don't think we should be blocking or delaying any release for them. We can't fix them all anyway. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On 05/18/2011 05:18 PM, Adam Miller wrote: On Wed, May 18, 2011 at 10:27:07PM +0530, Rahul Sundaram wrote: On 05/18/2011 09:58 PM, Jóhann B. Guðmundsson wrote: On 05/18/2011 03:57 PM, Adam Williamson wrote: Feedback please! Thanks:) Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us withinsert type of exploits here )? No. SELInux (or firewall) is not a first line of defense. These get turned off by some users and we need to be sure we aren't relying on them solely. If there are important security issues, they should be fixed before release regardless of whether SELinux would mitigate them or not I have to disagree on this point, I think SELinux and the firewall are in fact valid vulnerability mitigation paths and since they are in fact enabled by default with the release then they should be able to satisfy the requirements for release criteria. I don't think we as a project can handle the long list of what users can and can't do once their system is installed, I personally think that in these release criteria we should focus on what is and isn't vulnerable from a default installation. If a user decides to turn of PackageKit, turn off the firewall, disable SELinux, and not manually pull package updates there's not much we can do for them. (And yes, I am aware this isn't the case you brought up but I'm simply trying to point out the slippery slope of what if the user does X? that we could get ourselves into that would make it difficult for us as a community to QA. That is my take on the scenario along with do we actually need any security release criteria surrounding the rest ( the issue that selinux does not catch ) as opposed to just ping the security team on case by case bases should the need arise and get them to assess the situation and then either flag the bug a blocker nth or a non blocker.. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On 5/18/11 1:22 PM, Kevin Kofler wrote: Adam Williamson wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release. The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too. We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible. Also: twelve month. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote: On 5/18/11 1:22 PM, Kevin Kofler wrote: Adam Williamson wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release. The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too. We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible. Also: twelve month. Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Guidelines Change] Changes to the Packaging Guidelines
Here are the latest changes to the Fedora Packaging Guidelines: --- A section has been added to the SysVInitScript guidelines covering the optional situation where a package that uses systemd unit files as the default also includes sysv initscripts in a subpackage: https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files --- The GIO scriptlets have been changed to not conditionalize the %post invocation. This works around a multilib issue. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GIO_modules --- The guideline that prohibits Fedora packages from using /srv has been updated to better represent what the FHS has to say about /srv and to clarify the expectations for Fedora packages which may be configured to use /srv. https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv --- It was brought to the FPC's attention that while the new Guidelines covering MinGW packaging were technically correct, Fedora 16 did not yet contain the necessary toolchain to support the new Guidelines, nor was it clear that it would arrive in rawhide anytime soon. Accordingly, the old MinGW guidelines were put back in place at: https://fedoraproject.org/wiki/Packaging:MinGW The new MinGW guidelines remain approved, but are not active and packagers should not use them at this time. If/when the necessary toolchain components are packaged in Fedora, these guidelines will be re-enabled. In addition, the current MinGW guidelines were improved slightly to support the new SRPM naming standard. This is intended to prevent new MinGW packages from having to be re-reviewed when the new MinGW guidelines take effect. --- These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC). Many thanks to Kalev Lember, Matthew Miller, Michael Schwendt, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~spot ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Mon, 2011-05-16 at 18:59 +0200, Lennart Poettering wrote: On Mon, 16.05.11 14:32, Michal Hlavinka (mhlav...@redhat.com) wrote: when ups recieves command for shutdown, it does not shutdown power immediately, but after 30 seconds. Given that this command should be executed after umount, synced disks,... when everything is ready for power off... 30 seconds proved to be enough time for this. This is not the case and never has been the case. The root disks traditionally could not be unmounted and hence MD/DM/MP and so on could not be disassembled before going down. Delaying shutdown by 30s is hack, not a fix for a race. What race are we talking about exactly ? You do realize that the *UPS* itself is programmed to shut down after 30 seconds ? there is no sleep(30) here ... UPS code like that needs to sit in the kernel itself to properly work. Adding userspace kludges which invokes this from userspace is a recipe for desaster. If *you* wan't to write kernel drivers for tons of UPS models using serial/usb/network/... connections with tons of protocols (with incomplete documentation)... it's your freedom to do so ;) Well, what can I say. I don't maintain UPS stuff, I don't use UPS stuff. Oh this was *very* clear, no doubt you have never seen one. And given you haven't can you stop prescribing how things should work and instead discuss how we can make things work as things stand now ? You are the one pushing systemd, it is your duty to address the cases when it has to step out of the perfect world and actually meet the reality of how things actually work out there. I am just pointing you to the fact that the current approach here is racy, but sorry, I won't fix this for you. Given a lot of UPSes have drivers written in proprietary Java programs and communicate to the device via serial/usbserial, there isn't much you can do on the kernel driver front. You just need to provide for the right hooks so that the thing can be called as close as possible from the actual halt, when the root filesystem has been remounted r/o. And of course w/o killing the driver before that happens. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, May 18, 2011 at 10:44:16AM -0700, Adam Williamson wrote: Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it Yes. so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. No. Shipping a safe product is a goal that ethically demands our best effort, even if we'll never be totally successful. Not being able to get them all makes the ones we can get more important, not less. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On 5/18/11 1:44 PM, Adam Williamson wrote: On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote: On 5/18/11 1:22 PM, Kevin Kofler wrote: Adam Williamson wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release. The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too. We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible. Also: twelve month. Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point. It's a rationally argued position, but argued from an initial state that does not reflect reality. I mean, the conclusion from that line of reasoning is that all releases are futile: any sufficiently severe bug unknown at release time could be discovered later, and could be so crippling as to make the release useless. I don't necessarily disagree with that logic either. However, we've decided to do releases. Therefore we ought to have some standard of quality for release content definition. After that it's all a matter of drawing the line. I'd argue that knowingly exposing the user to a remote root exploit is actively negligent behaviour; remote user code execution, less so but still very bad; local privilege escalation, less so still. I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Special thanks to gnome3 and systemd developers
On Wed, 2011-05-18 at 09:20 -0500, Bruno Wolff III wrote: While everyone that worked on the F15 release deserves thanks and congrats, I'd like to give a special thanks to the systemd and gnome3 developers because of the large amount of work needed to implement those features. By working hard to get these into F15, they helped meet Fedora's goal of being First. +1K -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo meeting (2011-05-18)
=== #fedora-meeting: FESCO (2011-05-18) === Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-05-18/fesco.2011-05-18-17.30.log.html Meeting summary --- * init process (nirik, 17:30:01) * #515 Investigate a features repo for stable releases (nirik, 17:32:32) * will remove from meeting agenda for now, will bring back up when there is progress to report. (nirik, 17:33:32) * #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 17:33:41) * issue with pie, being followed up with binutils folks before we enable globally. (nirik, 17:35:35) * #588 promote praveenp to sponsor (nirik, 17:35:43) * AGREED: praveenp is approved for sponsor. (nirik, 17:40:44) * #589 Porting from sysVinit init scripts to systemd unit files (nirik, 17:41:06) * AGREED: Ask for a feature page to track and coordinate, will file a FES ticket for any interested fes folks to work on them, try and get done in f16, cleanups welcome while converting. (nirik, 17:49:50) * F15 and Elections (nirik, 17:50:05) * Open Floor (nirik, 17:51:55) * kudos to everyone on f15. (nirik, 17:55:27) * #589 Porting from sysVinit init scripts to systemd unit files (redux) (nirik, 17:59:42) * Open Floor again (nirik, 18:21:52) Meeting ended at 18:23:43 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (87) * Viking-Ice (37) * notting (12) * cwickert (12) * mjg59 (11) * mmaslano (9) * zodbot (8) * ajax (7) * mdomsch (4) * kylem (3) * SMParrish (0) * mclasen (0) -- 17:30:01 nirik #startmeeting FESCO (2011-05-18) 17:30:01 zodbot Meeting started Wed May 18 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 nirik #meetingname fesco 17:30:01 zodbot The meeting name has been set to 'fesco' 17:30:01 nirik #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:01 nirik #topic init process 17:30:09 * notting is here 17:30:19 mjg59 Here 17:30:57 ajax also here 17:31:00 kylem yo 17:31:19 * nirik waves and waits another minute for more folks to wander in 17:31:42 * cwickert is here 17:31:56 * mmaslano here 17:32:22 nirik ok, lets go ahead and dive in. 17:32:32 nirik #topic #515 Investigate a features repo for stable releases 17:32:33 nirik .fesco 515 17:32:34 zodbot nirik: #515 (Investigate a features repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515 17:32:37 nirik any news on this one? 17:32:44 cwickert nope, sorry 17:32:51 cwickert this is becoming a running gar 17:32:52 cwickert gag 17:33:00 cwickert I suggest we take it off the agenda for now 17:33:03 nirik no problem... lots of busyness with release coming up. 17:33:08 nirik ok, can do that... 17:33:13 cwickert I will set the meeting keyword once I have something to show 17:33:19 nirik sounds good. 17:33:32 nirik #info will remove from meeting agenda for now, will bring back up when there is progress to report. 17:33:41 nirik #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:33:41 nirik .fesco 563 17:33:42 zodbot nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 17:33:54 nirik ajax: I think someone ran into an issue with this? so we are holding off on it for now? 17:34:24 ajax yeah, -pie implies a semantic change to apps that we think is unintentional 17:34:51 ajax it's being followed up with the binutils people though 17:34:57 nirik cool. 17:35:25 ajax hopefully i'll have an update (or better, a fix) next week 17:35:30 ajax defer in the meantime though 17:35:35 nirik #info issue with pie, being followed up with binutils folks before we enable globally. 17:35:37 nirik sounds good. 17:35:43 nirik #topic #588 promote praveenp to sponsor 17:35:43 nirik .fesco 588 17:35:44 zodbot nirik: #588 (promote praveenp to sponsor) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/588 17:35:56 nirik This was a sponsor request that didn't get much feedback. 17:36:12 nirik mdomsch submitted them, as they are a active dell contributor... 17:36:20 nirik and they want someone to help dell folks get more involved. 17:36:23 notting much or any? 17:36:29 * nirik looks 17:36:50 nirik none. 17:36:58 nirik no negative, no positive. 17:37:39 mmaslano If mdomsh prepared him, I don't see any problem to give sponsorship to praveenp 17:38:01 * cwickert hasn't seen much of Praveen, but trusts Matt 17:38:36 nirik I assume there's an implicit +1 from mdomsch here. ;) 17:39:02 mmaslano yes
Re: Security release criterion proposal
On Wed, 2011-05-18 at 19:22 +0200, Kevin Kofler wrote: Adam Williamson wrote: Hey, all. The topic of whether and which security issues should block releases has come up several times before. Indeed it has. The decision was always that it's not a good idea. I don't see how the situation has changed to warrant beating that dead horse again. # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release. That's certainly a valid concern; does anyone have hard data on this? Either way, it's certainly worth considering that we can do nothing about issues that come to light after release, in relation to the installer and live image. We have a process for security fixes, it's called updates. I don't see how a 0-day update wouldn't be an appropriate resolution for a security issue. Now if you are talking about NTH, then yes, security fixes should be NTH. Maybe even all of them. But I don't think we should be blocking or delaying any release for them. We can't fix them all anyway. No, this would be release blocker stuff, not NTH. But I'm floating a balloon here; if most agree with you, we could consider adding security issues to the NTH principles instead. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote: Hey, all. The topic of whether and which security issues should block releases has come up several times before. While we haven't actually had many really serious security issues to worry about since the introduction of the current release criteria system, I think it's certainly something we should take into account. At the same time, it's fairly established in practice that we don't just consider anything worth issuing a CVE for as a release-blocking bug. So, to capture what I believe would be the intent of the project, I propose this as an Alpha release criterion for F16 onwards. (For those on devel and security lists who may not be completely familiar with the release criteria / blocker system, this would mean that any bug for an issue which breached the criterion should be considered a release blocker for any Alpha, Beta or Final release). # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release I mostly agree with this criterion with one exception below. Points to consider: * Possible variants to the type of vulnerability covered...do we also want to make local privesc vulns blocking? Conversely, do we want to make only remote *root* execution vulns blocking? I don't know if anyone would want to go as far as making DoS vulns release blocking, but speak up if you would! (Of course there is again the local/remote distinction to consider there: 'all DoS vulns' would be a much tighter standard than 'remote DoS vulns'). * The caveat about where the issue is exploitable is important because if you can't exploit it from the installer or a live image, it becomes less relevant whether we ship with it or not, because you would be safe with the first post-install update assuming we submitted an update for the issue promptly. But it may be the case that we want to broaden it out to also cover issues that can be exploited from a default DVD install, if we consider the window between install and first update (if updates repos aren't used during installation) to be unacceptable. I would vote for this slight broadening - that is to make also remotely exploitable issue in the default DVD install a release blocker. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 10:44 -0700, Adam Williamson wrote: On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote: On 5/18/11 1:22 PM, Kevin Kofler wrote: Adam Williamson wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release. The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too. We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible. Also: twelve month. Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point. Is it unthinkable to respin the images with those fixes ? Usually the patches are quite simple to backport, and we are talking about a limited set of bugs (remote root exploit on install) after all. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 14:40 -0400, Simo Sorce wrote: Is it unthinkable to respin the images with those fixes ? Usually the patches are quite simple to backport, and we are talking about a limited set of bugs (remote root exploit on install) after all. Unthinkable, no, but there are various practical issues with doing official re-spins which have meant it's never actually happened, and the project for doing it semi-externally - Unity - is often way behind. One that I wasn't previously aware of, which Spot explained to me recently, is U.S. export regulations; we have to go through a long and tedious regulatory process for official builds, and no-one's particularly keen to start doing that multiple times per cycle for respins. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 14:02 -0400, Adam Jackson wrote: On 5/18/11 1:44 PM, Adam Williamson wrote: On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote: On 5/18/11 1:22 PM, Kevin Kofler wrote: Adam Williamson wrote: # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release. The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too. We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible. Also: twelve month. Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point. It's a rationally argued position, but argued from an initial state that does not reflect reality. I mean, the conclusion from that line of reasoning is that all releases are futile: any sufficiently severe bug unknown at release time could be discovered later, and could be so crippling as to make the release useless. I don't necessarily disagree with that logic either. However, we've decided to do releases. Therefore we ought to have some standard of quality for release content definition. After that it's all a matter of drawing the line. I'd argue that knowingly exposing the user to a remote root exploit is actively negligent behaviour; remote user code execution, less so but still very bad; local privilege escalation, less so still. I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by. Also note that targeting the heaps of poor users that are eager to try the newly shipped Fedora release would be probably much more easy and efficient than targeting one user installing the Fedora here or there a few months later. So yes, definitely remote root and user exploits in the installer, Live CDs, and in my opinion also the default install should be release blockers. By the way do we have statistics about when this kind of blockers happened during our previous releases? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 701252] Upgrade to new upstream version
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=701252 --- Comment #10 from Fedora Update System upda...@fedoraproject.org 2011-05-18 15:58:36 EDT --- perl-Directory-Queue-1.1-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[Bug 701252] Upgrade to new upstream version
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=701252 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Directory-Queue-1.1-1. |perl-Directory-Queue-1.1-1. |fc14|el6 -- 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
[Bug 701252] Upgrade to new upstream version
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=701252 --- Comment #11 from Fedora Update System upda...@fedoraproject.org 2011-05-18 15:59:04 EDT --- perl-Directory-Queue-1.1-1.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[Bug 701252] Upgrade to new upstream version
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=701252 --- Comment #9 from Fedora Update System upda...@fedoraproject.org 2011-05-18 15:57:32 EDT --- perl-Directory-Queue-1.1-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[Bug 701252] Upgrade to new upstream version
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=701252 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Directory-Queue-1.1-1. |perl-Directory-Queue-1.1-1. |el5 |el4 -- 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
[Bug 701252] Upgrade to new upstream version
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=701252 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Directory-Queue-1.1-1. |perl-Directory-Queue-1.1-1. |el6 |el5 -- 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
Re: Security release criterion proposal
Adam Jackson wrote: The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too. We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible. Unknown risk exposure can become known after the release and we'd have to respin all our images for every single security fix to address that. This is just not practical. Also: twelve month. 13 months if you go by that metric, but the 6 months I mentioned are the time between 2 releases, i.e. the time that can pass in the worst case until we release fixed images. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
Few questions here: What does this scope include? Is it merely the LiveCD for GNOME and KDE? Does it also include the DVD install selections for both of these packages? (They are different) What about clearly vulnerable areas, like Web Sever that is push-button selectable on install? Do we make a list of what is installed in these situations and create a watch-list like “crit-path”? IMHO, Local and remote privilege escalation issues with the default configurations should block the release if they are known prior to making the release. My only questions are scope definitions that would clarify exactly what packages we are talking about here. Earlier, someone kindly wrote a STIG script to analyze an installed system. Fixing these permission defaults would go a ways to mitigating issues. Poly-instantiated-tmpdirs would also be NTH by default. Confined users by default would also be an awesome plan. (I can go on, but the big plan is to have a secure by default install, and let the users define where they want to open access up. Anything the user does after firstboot should really not be covered here.) We have to define a clear scope before a decent decision. -dj On Wed, May 18, 2011 at 1:51 PM, Adam Williamson awill...@redhat.comwrote: On Wed, 2011-05-18 at 14:40 -0400, Simo Sorce wrote: Is it unthinkable to respin the images with those fixes ? Usually the patches are quite simple to backport, and we are talking about a limited set of bugs (remote root exploit on install) after all. Unthinkable, no, but there are various practical issues with doing official re-spins which have meant it's never actually happened, and the project for doing it semi-externally - Unity - is often way behind. One that I wasn't previously aware of, which Spot explained to me recently, is U.S. export regulations; we have to go through a long and tedious regulatory process for official builds, and no-one's particularly keen to start doing that multiple times per cycle for respins. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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: Security release criterion proposal
Adam Jackson wrote: It's a rationally argued position, but argued from an initial state that does not reflect reality. I mean, the conclusion from that line of reasoning is that all releases are futile: any sufficiently severe bug unknown at release time could be discovered later, and could be so crippling as to make the release useless. I don't necessarily disagree with that logic either. However, we've decided to do releases. Therefore we ought to have some standard of quality for release content definition. After that it's all a matter of drawing the line. I'd argue that knowingly exposing the user to a remote root exploit is actively negligent behaviour; remote user code execution, less so but still very bad; local privilege escalation, less so still. The thing is, if we block the release for each and every known security issue, considering the time passing between notification and public availability of a fix, we will never be able to release anything. We have to draw the line somewhere, and the best way to do it is to use our time-based schedule. We have done 15 releases successfully that way, what's the reason for changing this approach now? And how can this not lead to a chain of slippage where each slippage for a security fix causes several new security fixes to pop up, for which we slip again, ad infinitum? We cannot fix all security issues any more that we can fix all bugs. We have to get SOMETHING out at some point. I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by. You don't KNOW that it will get the user rooted. Now if the hole is in a service listening to the Internet by default and is getting exploited by an automated worm, you can reasonably say that it WILL get the user rooted, but if it's e.g. a browser vulnerability, it will only hit the users if and when they access an infected or malicious site. Hopefully they'll have installed our 0-day security fix by then! (I'd hope sites like start.fedoraproject.org will not carry some trojan horse!) And your logic is flawed in that you assume that every user installs Fedora the day of the release. That's actually very far from the truth. All your efforts to release without known security vulnerabilities are for naught when the next one inevitably comes up soon after the release and there won't be a fixed set of live images for 6 months. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Wed, 2011-05-18 at 15:43 -0500, dr johnson wrote: Few questions here: What does this scope include? Is it merely the LiveCD for GNOME and KDE? Does it also include the DVD install selections for both of these packages? (They are different) Well, that's part of the discussion I wanted to start. As written it covers anything that actually runs as part of the installation sequence on the DVD and anything you can run directly from within one of the published live images, it's less concerned with post-install scenarios. Do we make a list of what is installed in these situations and create a watch-list like “crit-path”? As I wrote in a previous reply, implementation of planned testing and validation for criteria is a rather different topic from definition of the criteria, and it's probably best to discuss them separately. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On 5/18/11 4:49 PM, Kevin Kofler wrote: The thing is, if we block the release for each and every known security issue, considering the time passing between notification and public availability of a fix, we will never be able to release anything. We have to draw the line somewhere, and the best way to do it is to use our time-based schedule. False induction. I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by. You don't KNOW that it will get the user rooted. Now if the hole is in a service listening to the Internet by default and is getting exploited by an automated worm, you can reasonably say that it WILL get the user rooted, but if it's e.g. a browser vulnerability, it will only hit the users if and when they access an infected or malicious site. Hopefully they'll have installed our 0-day security fix by then! (I'd hope sites like start.fedoraproject.org will not carry some trojan horse!) Now you're drawing lines. Before you were saying this is impossible, we shouldn't try. Moving the goalposts. I'm done arguing with you on this, it's clear you don't know how. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
Tomas Mraz wrote: Also note that targeting the heaps of poor users that are eager to try the newly shipped Fedora release would be probably much more easy and efficient than targeting one user installing the Fedora here or there a few months later. Huh? The heaps of users do not install Fedora the day of the release. Only very few very enthousiastic and very impatient early adopters do that (and I blame them for needlessly swamping our mirrors). Actual users, especially those most likely to try out and install from live images (as opposed to e.g. upgrading an existing release using preupgrade, which pulls in updates automatically), install Fedora whenever they discover it, which can be at any time of our release cycle. For example, we gave out a few dozen Fedora 14 live media less than 2 weeks ago at Linuxwochen Wien! And for several practical reasons I don't want to go into here, the media we handed out at the event were all GA images, not respins. Users downloading the images themselves will probably also opt for the GA ISOs we officially distribute, not unofficial respins we do not officially endorse. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Mon, 16.05.11 14:30, Simo Sorce (sso...@redhat.com) wrote: On Mon, 2011-05-16 at 18:59 +0200, Lennart Poettering wrote: On Mon, 16.05.11 14:32, Michal Hlavinka (mhlav...@redhat.com) wrote: when ups recieves command for shutdown, it does not shutdown power immediately, but after 30 seconds. Given that this command should be executed after umount, synced disks,... when everything is ready for power off... 30 seconds proved to be enough time for this. This is not the case and never has been the case. The root disks traditionally could not be unmounted and hence MD/DM/MP and so on could not be disassembled before going down. Delaying shutdown by 30s is hack, not a fix for a race. What race are we talking about exactly ? Host requests power down from UPS in 30s. Host then continues shut down. If the host now ends up taking more time then expected for shutting down it might still be busy at the time of the power going away. It's a race between UPS powering off and system finishing shutdown. It's a bet that your system is faster than 30s when unmounting the remaining file systems, syncing the MD/DM metadata to disk, syncing ATA and so on (i.e. all the stuff the kernel does when you invoke the reboot() syscall). You do realize that the *UPS* itself is programmed to shut down after 30 seconds ? there is no sleep(30) here ... Yes, but that is irrelevant for the race. UPS code like that needs to sit in the kernel itself to properly work. Adding userspace kludges which invokes this from userspace is a recipe for desaster. If *you* wan't to write kernel drivers for tons of UPS models using serial/usb/network/... connections with tons of protocols (with incomplete documentation)... it's your freedom to do so ;) Well, what can I say. I don't maintain UPS stuff, I don't use UPS stuff. Oh this was *very* clear, no doubt you have never seen one. And given you haven't can you stop prescribing how things should work and instead discuss how we can make things work as things stand now ? Well, I am not stupid. I can see a race when there is one. Are you claiming the race above doesn't exist? You are the one pushing systemd, it is your duty to address the cases when it has to step out of the perfect world and actually meet the reality of how things actually work out there. Right, and so I did. And I also pointed out that the current scheme is borked. I am just pointing you to the fact that the current approach here is racy, but sorry, I won't fix this for you. Given a lot of UPSes have drivers written in proprietary Java programs and communicate to the device via serial/usbserial, there isn't much you can do on the kernel driver front. Hmm? I am pretty sure we don't want to run Java programs at late boot, as root. This would be really bad. In F16 we hope to make it possible to unmount the root fs at shutdown. It will be the first time we can do something like this. To implement this we'll have to copy the shutdown code into a tmpfs and then replace the root dir with the tmpfs. We definitely don't want to copy the JRE into the tmpfs before going down. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
Adam Jackson wrote: On 5/18/11 4:49 PM, Kevin Kofler wrote: The thing is, if we block the release for each and every known security issue, considering the time passing between notification and public availability of a fix, we will never be able to release anything. We have to draw the line somewhere, and the best way to do it is to use our time-based schedule. False induction. Uh no, you can't dismiss my argument that easily… If, say, it takes 2 weeks to get a fix for a critical security issue published/publishable (i.e. developed and put out of embargo), and if there's at least 1 critical security vulnerability in every 2-week interval, we will mathematically never be able to release if we treat all critical security vulnerabilities as blockers. (And that sentence remains true no matter how you define critical.) And this is just one of the possible constellations, and a very simplified one to prove my point. In practice, things are much more stochastic, but there are many possible scenarios in which each slippage will cause another. You show no evidence whatsoever showing that this is not going to happen. So this means you MUST consider the scenario I pointed out at least as a worst- case scenario. (Empirically, I'd actually expect it to be the average-case scenario, but I'll admit I have no statistical evidence to support that.) Now you're drawing lines. Before you were saying this is impossible, we shouldn't try. Moving the goalposts. Call me when you see a security issue which actually fits my description (i.e. an automated worm which successfully exploits a service that's enabled by default, listening to more than just localhost by default and not firewalled by default), and that during the short release candidate time window, even. I haven't seen it happen in any of the 14 releases we did nor the 15th we're doing now, and I don't see it happening any time soon. This is purely theoretical. Now I won't object to putting this exact item on the blocker list, but I don't expect it to get invoked, ever. I DO object to putting anything security-related OTHER than that up as a blocker, because we need to release at some point. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On 05/18/2011 04:04 PM, Lennart Poettering wrote: Host requests power down from UPS in 30s. Host then continues shut down. If the host now ends up taking more time then expected for shutting down it might still be busy at the time of the power going away. It's a race between UPS powering off and system finishing shutdown. It's a bet that your system is faster than 30s when unmounting the remaining file systems, syncing the MD/DM metadata to disk, syncing ATA and so on (i.e. all the stuff the kernel does when you invoke the reboot() syscall). Here's another race. Host requests power down from UPS in 30s. Host completes shutdown. At some point during that 30s interval, commercial power is restored. Result: Host shuts down and never restarts. Sorry about that. The way I've always prevented that is to have the host do a reboot, not a shutdown, but send an immediate shutdown command to the UPS just before sending control to the BIOS for the reboot. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Call for help: porting Sugar to NetworkManager 0.9 for Fedora 15
Hey, all. So, although the Fedora 15 final release has been signed off on, we gave ourselves a bit of wiggle room. The current Sugar implementation is known to have some significant issues, the major one of which is that networking is badly broken. We are aiming to try and fix these and do the Sugar-on-a-stick live spin late, incorporating these fixes, as they do not need to touch any of the other live images or the DVD. The problem with networking is the NetworkManager 0.9 API change; it caught Sugar, both upstream and within Fedora, a bit off guard. When the change was discussed by FESCo the needs of KDE and anaconda were considered and a plan developed, but no-one caught that the same problem affected Sugar: Sugar has its own interface to NetworkManager, and that needs to be either ported to 0.9, or adjusted to use the fallback 0.8ish API that was implemented for knetworkmanager to use. Unfortunately, our go-to Sugar guy, Peter Robinson, is struggling with doing this as it's not really in his wheelhouse, and our upstream contact at Sugar is busy with travel and Sugar release problems, so getting this done has not been smooth sailing so far. Peter would be very grateful of any help anyone could offer with the porting effort (to either the 0.9 or 0.8-ish interface within current NetworkManager; we don't care which, we just want typical Sugar networking to work. We'd like to get this done so we can still spin up a Sugar live image and push it out for release day, which is May 24, but in any case, the sooner the better. If you'd like to help with this, please contact Peter, myself, or Jared Smith via email or IRC, or just reply to this mail. Peter's IRC nick is pbrobinson, mine is adamw, and Jared's is jsmith. Thanks a lot! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Wed, 2011-05-18 at 23:04 +0200, Lennart Poettering wrote: On Mon, 16.05.11 14:30, Simo Sorce (sso...@redhat.com) wrote: On Mon, 2011-05-16 at 18:59 +0200, Lennart Poettering wrote: On Mon, 16.05.11 14:32, Michal Hlavinka (mhlav...@redhat.com) wrote: when ups recieves command for shutdown, it does not shutdown power immediately, but after 30 seconds. Given that this command should be executed after umount, synced disks,... when everything is ready for power off... 30 seconds proved to be enough time for this. This is not the case and never has been the case. The root disks traditionally could not be unmounted and hence MD/DM/MP and so on could not be disassembled before going down. Delaying shutdown by 30s is hack, not a fix for a race. What race are we talking about exactly ? Host requests power down from UPS in 30s. Host then continues shut down. If the host now ends up taking more time then expected for shutting down it might still be busy at the time of the power going away. It's a race between UPS powering off and system finishing shutdown. It's a bet that your system is faster than 30s when unmounting the remaining file systems, syncing the MD/DM metadata to disk, syncing ATA and so on (i.e. all the stuff the kernel does when you invoke the reboot() syscall). You do realize that it is a race to get it done before the UPS runs out of battery anyway ? It's not perfect, but sysadmins are capable of assessing how much time each of their server needs to shut down and make the UPS wait long enough (battery permitting of course). You do realize that the *UPS* itself is programmed to shut down after 30 seconds ? there is no sleep(30) here ... Yes, but that is irrelevant for the race. Call it a race, call it a run, doesn't matter it is how things works in this world right now. I guess you could try to convince UPS vendors to use better ways, but that's not how physical devices available to the public work right now. UPS code like that needs to sit in the kernel itself to properly work. Adding userspace kludges which invokes this from userspace is a recipe for desaster. If *you* wan't to write kernel drivers for tons of UPS models using serial/usb/network/... connections with tons of protocols (with incomplete documentation)... it's your freedom to do so ;) Well, what can I say. I don't maintain UPS stuff, I don't use UPS stuff. Oh this was *very* clear, no doubt you have never seen one. And given you haven't can you stop prescribing how things should work and instead discuss how we can make things work as things stand now ? Well, I am not stupid. I can see a race when there is one. Are you claiming the race above doesn't exist? You are looking at the finger while people are pointing to the moon right now. You are the one pushing systemd, it is your duty to address the cases when it has to step out of the perfect world and actually meet the reality of how things actually work out there. Right, and so I did. And I also pointed out that the current scheme is borked. I am sorry that reality bothers you so much, but it is the hard old real world ... I am just pointing you to the fact that the current approach here is racy, but sorry, I won't fix this for you. Given a lot of UPSes have drivers written in proprietary Java programs and communicate to the device via serial/usbserial, there isn't much you can do on the kernel driver front. Hmm? I am pretty sure we don't want to run Java programs at late boot, as root. This would be really bad. You know, it's not like there is a choice for many models ... In F16 we hope to make it possible to unmount the root fs at shutdown. It will be the first time we can do something like this. To implement this we'll have to copy the shutdown code into a tmpfs and then replace the root dir with the tmpfs. We definitely don't want to copy the JRE into the tmpfs before going down. It is not necessary, the hook can be called before you do that last operation, the driver will command the UPS to wait long enough for that operation to finish in time in 99% of the cases. For the remaining 1% of the cases, admins will have to re-tune the delay once power comes up and they find it wasn't enough time after all. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Wed, 2011-05-18 at 16:48 -0500, Robert Nichols wrote: On 05/18/2011 04:04 PM, Lennart Poettering wrote: Host requests power down from UPS in 30s. Host then continues shut down. If the host now ends up taking more time then expected for shutting down it might still be busy at the time of the power going away. It's a race between UPS powering off and system finishing shutdown. It's a bet that your system is faster than 30s when unmounting the remaining file systems, syncing the MD/DM metadata to disk, syncing ATA and so on (i.e. all the stuff the kernel does when you invoke the reboot() syscall). Here's another race. Host requests power down from UPS in 30s. Host completes shutdown. At some point during that 30s interval, commercial power is restored. Result: Host shuts down and never restarts. Sorry about that. The way I've always prevented that is to have the host do a reboot, not a shutdown, but send an immediate shutdown command to the UPS just before sending control to the BIOS for the reboot. What you should do is to configure the BIOS to always boot on power-up. This way the UPS will remove power, figure out power is returned, reapply power and the BIOS will reboot the machine. That's how this problem should normally be handled, then there is the reality of broken BIOSes, broken UPSs, and general unlucky circumstances :) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-15 Branched report: 20110518 changes
Compose started at Wed May 18 13:15:47 UTC 2011 Broken deps for x86_64 -- db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-3.fc15.noarch requires debhelper file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) glunarclock-0.34.1-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-cpufire-1.6-3.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-music-2.5.1-5.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0 gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2) gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-3.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) 1:gnome-applets-2.32.0-3.fc15.x86_64 requires libgweather.so.1()(64bit) gnome-netstatus-2.28.2-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotd.so.5()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdcm.so.4()(64bit) gnome-pilot-conduits-2.32.1-2.fc15.x86_64 requires libgpilotdconduit.so.3()(64bit) gnome-python2-applet-2.32.0-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-gdl-2.25.3-22.fc15.x86_64 requires libgdl-1.so.3()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gnotime-2.3.0-8.fc15.x86_64 requires libgtkhtml-3.15.so.19()(64bit) gnubiff-2.2.13-4.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-back-0.18.0-4.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-examples-1.3.0-4.fc15.x86_64 requires libobjc.so.2()(64bit) gnustep-gui-0.18.0-2.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-gui-0.18.0-2.fc14.x86_64 requires libobjc.so.2()(64bit) gnustep-gui-libs-0.18.0-2.fc14.i686 requires libobjc.so.2 gnustep-gui-libs-0.18.0-2.fc14.i686 requires libgnustep-base.so.1.20 gnustep-gui-libs-0.18.0-2.fc14.x86_64 requires libgnustep-base.so.1.20()(64bit) gnustep-gui-libs-0.18.0-2.fc14.x86_64 requires libobjc.so.2()(64bit) gold-2.1.12.2-5.fc15.noarch requires perl(Data::Properties) gorm-1.2.12-2.fc15.i686 requires libobjc.so.2 gorm-1.2.12-2.fc15.i686 requires libgnustep-base.so.1.20 gorm-1.2.12-2.fc15.x86_64 requires libgnustep-base.so.1.20()(64bit) gorm-1.2.12-2.fc15.x86_64 requires libobjc.so.2()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) honeyd-1.5c-13.fc15.x86_64 requires libevent-1.4.so.2()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections libopenvrml-0.18.6-4.fc14.1.i686 requires libboost_thread-mt.so.1.44.0 libopenvrml-0.18.6-4.fc14.1.i686 requires libboost_filesystem-mt.so.1.44.0 libopenvrml-0.18.6-4.fc14.1.x86_64 requires libboost_filesystem-mt.so.1.44.0()(64bit) libopenvrml-0.18.6-4.fc14.1.x86_64 requires libboost_thread-mt.so.1.44.0()(64bit) libopenvrml-gl-0.18.6-4.fc14.1.i686 requires libboost_thread-mt.so.1.44.0 libopenvrml-gl-0.18.6-4.fc14.1.i686 requires libboost_filesystem-mt.so.1.44.0 libopenvrml-gl-0.18.6-4.fc14.1.x86_64 requires libboost_filesystem-mt.so.1.44.0()(64bit)
Re: systemd questions
On Wed, May 18, 2011 at 07:42:17PM -0400, Simo Sorce wrote: I am pretty sure we don't want to run Java programs at late boot, as root. This would be really bad. You know, it's not like there is a choice for many models ... That's really not a given. For anything short of us having to send http requests, there's no fundamental reason why this can't be done in-kernel. For cases where we do have to send http requests, well, that's kind of a separate issue (you want to run java after you've unmounted all the filesystems?) It is not necessary, the hook can be called before you do that last operation, the driver will command the UPS to wait long enough for that operation to finish in time in 99% of the cases. For the remaining 1% of the cases, admins will have to re-tune the delay once power comes up and they find it wasn't enough time after all. Or we could work on fixing the problem. We're not talking about an incredibly large maount of code. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On 05/18/2011 09:06 PM, Matthew Garrett wrote: On Wed, May 18, 2011 at 07:42:17PM -0400, Simo Sorce wrote: You know, it's not like there is a choice for many models ... That's really not a given. For anything short of us having to send http requests, there's no fundamental reason why this can't be done in-kernel. For cases where we do have to send http requests, well, that's kind of a separate issue (you want to run java after you've unmounted all the filesystems?) A bunch of individual UPS kernel drivers feels inappropriate to me. But if there is some common kernel functionality that could be used by and help all UPS devices that feels more reasonable. What functionality do think needs be added to the kernel so that the userspace UPS code could be better ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On 05/18/2011 06:42 PM, Simo Sorce wrote: On Wed, 2011-05-18 at 16:48 -0500, Robert Nichols wrote: On 05/18/2011 04:04 PM, Lennart Poettering wrote: Host requests power down from UPS in 30s. Host then continues shut down. If the host now ends up taking more time then expected for shutting down it might still be busy at the time of the power going away. It's a race between UPS powering off and system finishing shutdown. It's a bet that your system is faster than 30s when unmounting the remaining file systems, syncing the MD/DM metadata to disk, syncing ATA and so on (i.e. all the stuff the kernel does when you invoke the reboot() syscall). Here's another race. Host requests power down from UPS in 30s. Host completes shutdown. At some point during that 30s interval, commercial power is restored. Result: Host shuts down and never restarts. Sorry about that. The way I've always prevented that is to have the host do a reboot, not a shutdown, but send an immediate shutdown command to the UPS just before sending control to the BIOS for the reboot. What you should do is to configure the BIOS to always boot on power-up. This way the UPS will remove power, figure out power is returned, reapply power and the BIOS will reboot the machine. Telling my UPS to turn off merely shuts down the inverter. If it is not currently running on the inverter (because commercial power is available), that is effectively a no-op, and power at the UPS output remains on. Telling the BIOS to boot on power-up (which is how mine is configured, BTW) does nothing since _power_never_went_away_. All the BIOS sees is a command to shut down, which it does. And stays that way. Absent manual intervention, the only thing that would bring the system back up would be a power failure long enough to exceed the capacity of the essentially unloaded UPS, and that would be _quite_ a long time. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Wed, May 18, 2011 at 09:27:23PM -0400, Genes MailLists wrote: On 05/18/2011 09:06 PM, Matthew Garrett wrote: On Wed, May 18, 2011 at 07:42:17PM -0400, Simo Sorce wrote: You know, it's not like there is a choice for many models ... That's really not a given. For anything short of us having to send http requests, there's no fundamental reason why this can't be done in-kernel. For cases where we do have to send http requests, well, that's kind of a separate issue (you want to run java after you've unmounted all the filesystems?) A bunch of individual UPS kernel drivers feels inappropriate to me. Drivers have to live somewhere. We've traditionally put them in the kernel rather than in userland. But if there is some common kernel functionality that could be used by and help all UPS devices that feels more reasonable. What functionality do think needs be added to the kernel so that the userspace UPS code could be better ? If the kernel is able to send requests itself then it can do so when it would otherwise be requesting that the firmware halt the system. That means you can guarantee that the system is in a consistent state. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Thu, 2011-05-19 at 02:06 +0100, Matthew Garrett wrote: On Wed, May 18, 2011 at 07:42:17PM -0400, Simo Sorce wrote: I am pretty sure we don't want to run Java programs at late boot, as root. This would be really bad. You know, it's not like there is a choice for many models ... That's really not a given. For anything short of us having to send http requests, there's no fundamental reason why this can't be done in-kernel. For cases where we do have to send http requests, well, that's kind of a separate issue (you want to run java after you've unmounted all the filesystems?) It is not necessary, the hook can be called before you do that last operation, the driver will command the UPS to wait long enough for that operation to finish in time in 99% of the cases. For the remaining 1% of the cases, admins will have to re-tune the delay once power comes up and they find it wasn't enough time after all. Or we could work on fixing the problem. We're not talking about an incredibly large maount of code. We are however talking about a lot of different upses and while it is not specifically fedora's problem we do need to have this handled before rhel7, for example, is run on serious systems. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security release criterion proposal
On Thu, 2011-05-19 at 10:00 +0800, Eugene Teo wrote: I say, local privilege escalations with publicly available exploits, and remotely triggerable vulnerabilities. If such an issue is known before Final, we should attempt to address it before releasing. Note, a release criterion would have a stronger result: you say 'attempt to address it before releasing', but the effect of a release criterion is that issues which breach it *must* be fixed before we release; the release would slip until it was addressed. If you want a weaker effect, the NTH process (which works off more flexible 'principles' rather than strict criteria) is appropriate: an NTH bug is one for which we will break a release freeze to take a fix, but which doesn't block the release (if a fix isn't ready in time, we still go ahead and release). Once we have consensus on a release criterion - or not having a release criterion - I'll make a follow-up proposal for an NTH principle to cover less serious security issues. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
On Wed, May 18, 2011 at 10:42:02PM -0400, seth vidal wrote: We are however talking about a lot of different upses and while it is not specifically fedora's problem we do need to have this handled before rhel7, for example, is run on serious systems. If it's a functional requirement, it'll get written. Fedora's decision making process isn't beholden to the RHEL release cycle, and nor should it be. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Ouch/f14] 0.0401 bump
Summary of changes: 9b50363... 0.0401 bump (*) (*) 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 701119] perl-Ouch-0.0401 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=701119 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-05-18 05:57:50 EDT --- perl-Ouch-0.0401-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-Ouch-0.0401-1.fc15 -- 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 701119] perl-Ouch-0.0401 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=701119 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2011-05-18 05:57:24 EDT --- perl-Ouch-0.0401-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-Ouch-0.0401-1.fc14 -- 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 701119] perl-Ouch-0.0401 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=701119 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|MODIFIED Bug 701119 depends on bug 701237, which changed state. Bug 701237 Summary: Review Request: perl-Test-Trap - Trap exit codes, exceptions, output, etc https://bugzilla.redhat.com/show_bug.cgi?id=701237 What|Old Value |New Value Status|MODIFIED|ON_QA Status|ON_QA |CLOSED Resolution||ERRATA -- 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 705744] New: perl-App-cpanminus-1.4007 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-App-cpanminus-1.4007 is available https://bugzilla.redhat.com/show_bug.cgi?id=705744 Summary: perl-App-cpanminus-1.4007 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-App-cpanminus AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 1.4007 Current version in Fedora Rawhide: 1.4006 URL: http://search.cpan.org/dist/App-cpanminus/ 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 705744] perl-App-cpanminus-1.4007 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=705744 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com |ppi...@redhat.com AssignedTo|mmasl...@redhat.com |ppi...@redhat.com -- 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
File App-cpanminus-1.4007.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-App-cpanminus: 56fc1d8fce7da489e64c20597392ebc7 App-cpanminus-1.4007.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-App-cpanminus] 1.4007 bump
commit a13bf0e0928d0e88871d0bfeb3f04f804a934c50
Author: Petr Písař ppi...@redhat.com
Date: Wed May 18 13:03:08 2011 +0200
1.4007 bump
LWP is optional since this package bundles HTTP::Tiny. Upstream
recognized LWP being heavy. Follow upstream decision in RPM package
dependencies.
.gitignore |1 +
perl-App-cpanminus.spec |8 ++--
sources |2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8ae55e2..40e7c8f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.4004.tar.gz
/App-cpanminus-1.4005.tar.gz
/App-cpanminus-1.4006.tar.gz
+/App-cpanminus-1.4007.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index caf00c4..4b800b8 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,5 +1,5 @@
Name: perl-App-cpanminus
-Version:1.4006
+Version:1.4007
Release:1%{?dist}
Summary:Library for get, unpack, build and install CPAN modules
License:GPL+ or Artistic
@@ -18,7 +18,6 @@ Requires: perl(Getopt::Long)
Requires: perl(IO::File)
Requires: perl(IO::Socket)
Requires: perl(JSON)
-Requires: perl(LWP)
Requires: perl(Module::Build)
Requires: perl(Parse::CPAN::Meta)
Requires: perl(Time::Local)
@@ -63,6 +62,11 @@ make test
%{_bindir}/cpanm
%changelog
+* Wed May 18 2011 Petr Pisar ppi...@redhat.com - 1.4007-1
+- 1.4007 bump
+- LWP is optional since this package bundles HTTP::Tiny. Upstream recognized
+ LWP being heavy. Follow upstream decision in RPM package dependencies.
+
* Tue May 17 2011 Petr Pisar ppi...@redhat.com - 1.4006-1
- 1.4006 bump
- Fix obsoleted version string
diff --git a/sources b/sources
index 7ff7012..a1fdeab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-31fdeb09bfd81ee102f083fac989cd67 App-cpanminus-1.4006.tar.gz
+56fc1d8fce7da489e64c20597392ebc7 App-cpanminus-1.4007.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 705744] perl-App-cpanminus-1.4007 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=705744 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-cpanminus-1.4007-1 ||.fc16 Resolution||RAWHIDE Last Closed||2011-05-18 07:37:39 -- 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
File CGI-PSGI-0.15.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-CGI-PSGI: 58a39711add2b48229710688c5f81cfd CGI-PSGI-0.15.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-CGI-PSGI] Update to 0.15
commit 7a3e83aa469f84f5a43158f462b9dfa572294bff
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Wed May 18 20:40:16 2011 +0200
Update to 0.15
.gitignore |1 +
perl-CGI-PSGI.spec | 15 ++-
sources|2 +-
3 files changed, 8 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index bafe00e..8b38570 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ CGI-PSGI-0.11.tar.gz
/CGI-PSGI-0.12.tar.gz
/CGI-PSGI-0.13.tar.gz
/CGI-PSGI-0.14.tar.gz
+/CGI-PSGI-0.15.tar.gz
diff --git a/perl-CGI-PSGI.spec b/perl-CGI-PSGI.spec
index 586b0a6..2efa4b8 100644
--- a/perl-CGI-PSGI.spec
+++ b/perl-CGI-PSGI.spec
@@ -1,12 +1,11 @@
Name: perl-CGI-PSGI
-Version:0.14
-Release:2%{?dist}
+Version:0.15
+Release:1%{?dist}
Summary:Enable your CGI.pm aware applications to adapt PSGI protocol
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-PSGI/
Source0:
http://www.cpan.org/authors/id/M/MI/MIYAGAWA/CGI-PSGI-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(CGI)
@@ -32,8 +31,6 @@ to STDOUT.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -44,16 +41,16 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Wed May 18 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.15-1
+- Update to 0.15
+- Spec clean-up
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.14-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index 4ecda0c..3cd9287 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-31d2bd2cd3b4d0ae196e93e11e7fd98f CGI-PSGI-0.14.tar.gz
+58a39711add2b48229710688c5f81cfd CGI-PSGI-0.15.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 701119] perl-Ouch-0.0401 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=701119 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-05-18 14:42:00 EDT --- Package perl-Ouch-0.0401-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Ouch-0.0401-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-Ouch-0.0401-1.fc15 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CGI-Application-Plugin-RateLimit/f14] Initial import (#701183).
commit e76050d7e4074a8eb59282bf92b8c01a1f2317a7
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Thu May 19 01:08:16 2011 +0200
Initial import (#701183).
.gitignore |1 +
perl-CGI-Application-Plugin-RateLimit.spec | 59
sources|1 +
3 files changed, 61 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..9d26531 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/CGI-Application-Plugin-RateLimit-1.0.tar.gz
diff --git a/perl-CGI-Application-Plugin-RateLimit.spec
b/perl-CGI-Application-Plugin-RateLimit.spec
new file mode 100644
index 000..71a54bc
--- /dev/null
+++ b/perl-CGI-Application-Plugin-RateLimit.spec
@@ -0,0 +1,59 @@
+Name: perl-CGI-Application-Plugin-RateLimit
+Version:1.0
+Release:2%{?dist}
+Summary:Limits runmode call rate per user
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/CGI-Application-Plugin-RateLimit/
+Source0:
http://www.cpan.org/authors/id/S/SA/SAMTREGAR/CGI-Application-Plugin-RateLimit-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(CGI)
+BuildRequires: perl(CGI::Application)
+BuildRequires: perl(Class::Accessor::Fast)
+BuildRequires: perl(DBD::SQLite)
+BuildRequires: perl(DBI)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Test::More)
+Requires: perl(CGI::Application)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+This module provides protection against a user calling a runmode too
+frequently. A typical use-case might be a contact form that sends email.
+You'd like to allow your users to send you messages, but thousands of
+messages from a single user would be a problem.
+
+%prep
+%setup -q -n CGI-Application-Plugin-RateLimit-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Sat May 14 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 1.0-2
+- Clean up spec as per package review (#701183)
+
+* Thu Nov 25 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.0-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..05ff7e7 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+1013c2f223e9a28ecc203c64f8995b0d CGI-Application-Plugin-RateLimit-1.0.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
File DBIx-Class-Cursor-Cached-1.001001.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-DBIx-Class-Cursor-Cached: 11f9b448244bace1fd79658d7909d9be DBIx-Class-Cursor-Cached-1.001001.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-DBIx-Class-Cursor-Cached] initial import (rhbz#684511)
commit 200054dc8ac9f8d1967ad19a9d215a1b389bf9dd
Author: Iain Arnell iarn...@gmail.com
Date: Thu May 19 04:55:29 2011 +0200
initial import (rhbz#684511)
.gitignore |1 +
perl-DBIx-Class-Cursor-Cached.spec | 67
sources|1 +
3 files changed, 69 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..76652fa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/DBIx-Class-Cursor-Cached-1.001001.tar.gz
diff --git a/perl-DBIx-Class-Cursor-Cached.spec
b/perl-DBIx-Class-Cursor-Cached.spec
new file mode 100644
index 000..11e6222
--- /dev/null
+++ b/perl-DBIx-Class-Cursor-Cached.spec
@@ -0,0 +1,67 @@
+Name: perl-DBIx-Class-Cursor-Cached
+Version:1.001001
+Release:1%{?dist}
+Summary:Cursor class with built-in caching support
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/DBIx-Class-Cursor-Cached/
+Source0:
http://www.cpan.org/authors/id/A/AR/ARCANEZ/DBIx-Class-Cursor-Cached-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl = 1:5.8.1
+BuildRequires: perl(Cache::FileCache)
+BuildRequires: perl(Carp::Clan) = 6.0
+BuildRequires: perl(DBD::SQLite) = 1.25
+BuildRequires: perl(DBIx::Class) = 0.08124
+BuildRequires: perl(DBIx::Class::Core)
+BuildRequires: perl(DBIx::Class::Schema)
+BuildRequires: perl(Digest::SHA1)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+Requires: perl(Carp::Clan) = 6.0
+Requires: perl(DBIx::Class) = 0.08124
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?filter_setup:
+%filter_from_requires /perl(Carp::Clan)$/d
+%{?perl_default_filter}
+}
+
+%description
+This module provides a DBIx cursor class with built-in caching support.
+
+%prep
+%setup -q -n DBIx-Class-Cursor-Cached-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor --skipdeps
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%defattr(-,root,root,-)
+%doc Changes
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Mar 31 2011 Iain Arnell iarn...@gmail.com 1.001001-1
+- update to latest upstream version
+
+* Wed Mar 16 2011 Iain Arnell iarn...@gmail.com 1.001000-3
+- use skipdeps for Module::AutoInstall
+
+* Mon Mar 14 2011 Iain Arnell iarn...@gmail.com 1.001000-2
+- R/BR perl(DBIx::Class) = 0.8124 to avoid test failures
+
+* Sun Mar 13 2011 Iain Arnell iarn...@gmail.com 1.001000-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..c02363f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+11f9b448244bace1fd79658d7909d9be DBIx-Class-Cursor-Cached-1.001001.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
File Parallel-Iterator-1.00.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Parallel-Iterator: 879051d329ea79f59eb4b03bb0bf7c87 Parallel-Iterator-1.00.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-Parallel-Iterator] initial import (rhbz#704705)
commit ef87bdab1737e5e49add83ebad3de39b2d17ab0c
Author: Iain Arnell iarn...@gmail.com
Date: Thu May 19 04:57:29 2011 +0200
initial import (rhbz#704705)
.gitignore |1 +
perl-Parallel-Iterator.spec | 60 +++
sources |1 +
3 files changed, 62 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..48b7f3c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Parallel-Iterator-1.00.tar.gz
diff --git a/perl-Parallel-Iterator.spec b/perl-Parallel-Iterator.spec
new file mode 100644
index 000..2d795a6
--- /dev/null
+++ b/perl-Parallel-Iterator.spec
@@ -0,0 +1,60 @@
+Name: perl-Parallel-Iterator
+Version:1.00
+Release:1%{?dist}
+Summary:Simple parallel execution
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Parallel-Iterator/
+Source0:
http://www.cpan.org/authors/id/A/AN/ANDYA/Parallel-Iterator-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Config)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IO::Select)
+BuildRequires: perl(lib)
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Storable)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+The map function applies a user supplied transformation function to
+each element in a list, returning a new list containing the
+transformed elements.
+
+This module provides a 'parallel map'. Multiple worker processes are forked so
+that many instances of the transformation function may be executed
+simultaneously.
+
+For time consuming operations, particularly operations that spend most of their
+time waiting for I/O, this is a big performance win. It also provides a simple
+idiom to make effective use of multi CPU systems.
+
+%prep
+%setup -q -n Parallel-Iterator-%{version}
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Sat May 14 2011 Iain Arnell iarn...@gmail.com 1.00-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..0a9f26b 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+879051d329ea79f59eb4b03bb0bf7c87 Parallel-Iterator-1.00.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-Parallel-Iterator/f15] initial import (rhbz#704705)
Summary of changes: ef87bda... initial import (rhbz#704705) (*) (*) 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-Parallel-Iterator/f14] initial import (rhbz#704705)
Summary of changes: ef87bda... initial import (rhbz#704705) (*) (*) 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-Parallel-Iterator/f13] initial import (rhbz#704705)
Summary of changes: ef87bda... initial import (rhbz#704705) (*) (*) 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 705966] New: perl-HTTP-Server-Simple-PSGI: the F13 and F14 RPMS fail to require perl(HTTP::Server::Simple::CGI)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-HTTP-Server-Simple-PSGI: the F13 and F14 RPMS fail to require perl(HTTP::Server::Simple::CGI) https://bugzilla.redhat.com/show_bug.cgi?id=705966 Summary: perl-HTTP-Server-Simple-PSGI: the F13 and F14 RPMS fail to require perl(HTTP::Server::Simple::CGI) Product: Fedora Version: 14 Platform: Unspecified OS/Version: Linux Status: NEW Severity: high Priority: unspecified Component: perl-HTTP-Server-Simple-PSGI AssignedTo: rc040...@freenet.de ReportedBy: j...@di.uminho.pt QAContact: extras...@fedoraproject.org CC: rc040...@freenet.de, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Description of problem: The Fedora 13 and Fedora 14 RPMS of perl-HTTP-Server-Simple-PSGI aren't requiring perl(HTTP::Server::Simple::CGI) as the Fedora 15 RPMS are. This breaks the module usage in F13 and F14 as one of its requirements fail to install. Version-Release number of selected component (if applicable): perl-HTTP-Server-Simple-PSGI-0.14-2.fc13 perl-HTTP-Server-Simple-PSGI-0.14-2.fc14.noarch.rpm How reproducible: Always Additional info: $ diff (rpm -qpR perl-HTTP-Server-Simple-PSGI-0.14-2.fc14.noarch.rpm) (rpm -qpR perl-HTTP-Server-Simple-PSGI-0.14-2.fc15.noarch.rpm) 2a3 perl(HTTP::Server::Simple::CGI) 9d9 rpmlib(VersionedDependencies) = 3.0.3-1 $ diff (rpm -qpR perl-HTTP-Server-Simple-PSGI-0.14-2.fc13.noarch.rpm) (rpm -qpR perl-HTTP-Server-Simple-PSGI-0.14-2.fc15.noarch.rpm) 2c2,3 perl(:MODULE_COMPAT_5.10.1) --- perl(:MODULE_COMPAT_5.12.3) perl(HTTP::Server::Simple::CGI) 9d9 rpmlib(VersionedDependencies) = 3.0.3-1 -- 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 705966] perl-HTTP-Server-Simple-PSGI: the F13 and F14 RPMS fail to require perl(HTTP::Server::Simple::CGI)
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=705966 --- Comment #1 from Jose Pedro Oliveira j...@di.uminho.pt 2011-05-18 23:15:00 EDT --- The module HTTP::Server::Simple::PSGI pulls HTTP::Server::Server::CGI with the following line * use base qw/HTTP::Server::Simple::CGI/; which only appears to be extracted correctly by rpm 4.9 (and not by rpm 4.8.x). Source: http://cpansearch.perl.org/src/MIYAGAWA/HTTP-Server-Simple-PSGI-0.14/lib/HTTP/Server/Simple/PSGI.pm -- 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
File Devel-Cover-0.78.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Devel-Cover: fd26cd6df23bc3f2c38324884c976718 Devel-Cover-0.78.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-DBIx-Class-Cursor-Cached/f15] initial import (rhbz#684511)
Summary of changes: 200054d... initial import (rhbz#684511) (*) (*) 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-Devel-Cover] update to 0.78
commit a1cbab94f8de06ffd48a35a96496da7ba7ce1812
Author: Iain Arnell iarn...@gmail.com
Date: Thu May 19 05:20:59 2011 +0200
update to 0.78
.gitignore|1 +
perl-Devel-Cover.spec | 23 +--
sources |2 +-
3 files changed, 15 insertions(+), 11 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7967f4f..6034d06 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Devel-Cover-0.66.tar.gz
+/Devel-Cover-0.78.tar.gz
diff --git a/perl-Devel-Cover.spec b/perl-Devel-Cover.spec
index 3402b10..4176ecb 100644
--- a/perl-Devel-Cover.spec
+++ b/perl-Devel-Cover.spec
@@ -1,19 +1,21 @@
Name: perl-Devel-Cover
-Version:0.66
-Release:3%{?dist}
+Version:0.78
+Release:1%{?dist}
Summary:Code coverage metrics for Perl
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Devel-Cover/
Source0:
http://www.cpan.org/authors/id/P/PJ/PJCJ/Devel-Cover-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRequires: perl(JSON::PP)
BuildRequires: perl(Template)
BuildRequires: perl(PPI::HTML) = 1.07
BuildRequires: perl(Perl::Tidy) = 20060719
BuildRequires: perl(Pod::Coverage)
BuildRequires: perl(Test::Differences)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Warn)
BuildRequires: perl(ExtUtils::MakeMaker)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Pod::Coverage)
@@ -22,6 +24,7 @@ Requires: perl(Test::Differences)
# Requires: perl(PPI::HTML) = 1.07
# Requires: perl(Perl::Tidy) = 20060719
+%{?perl_default_filter}
%description
This module provides code coverage metrics for Perl.
@@ -30,6 +33,7 @@ This module provides code coverage metrics for Perl.
%prep
%setup -q -n Devel-Cover-%{version}
+find lib -type f -print0 | xargs -0 chmod 0644
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
@@ -37,7 +41,6 @@ make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
@@ -49,13 +52,8 @@ chmod -R u+w $RPM_BUILD_ROOT/*
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%files
-%defattr(-,root,root,-)
-%doc BUGS CHANGES README TODO all_versions cpancover create_gold session.vim
+%doc CHANGES README docs/BUGS docs/TODO
%{_bindir}/*
%{perl_vendorarch}/Devel/
%{perl_vendorarch}/auto/Devel/
@@ -64,6 +62,11 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu May 19 2011 Iain Arnell iarn...@gmail.com 0.78-1
+- update to latest upstream version
+- clean up spec for modern rpmbuild
+- use perl_default_filter
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.66-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index 32ea7ab..8a4fde4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-db1a982fc82454c4f5a2d8edcc857cf3 Devel-Cover-0.66.tar.gz
+fd26cd6df23bc3f2c38324884c976718 Devel-Cover-0.78.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 703430] perlbrew-0.20 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=703430 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-05-19 00:58:11 EDT --- perlbrew-0.20-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[perl-HTTP-Server-Simple-PSGI/f14] R: perl(HTTP::Server::Simple::CGI) (BZ #705966).
commit 12acbda4c8099106ee786c6f2f40fb0ad737c316
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu May 19 07:40:16 2011 +0200
R: perl(HTTP::Server::Simple::CGI) (BZ #705966).
perl-HTTP-Server-Simple-PSGI.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTTP-Server-Simple-PSGI.spec
b/perl-HTTP-Server-Simple-PSGI.spec
index ee1192c..4324de0 100644
--- a/perl-HTTP-Server-Simple-PSGI.spec
+++ b/perl-HTTP-Server-Simple-PSGI.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Server-Simple-PSGI
Version:0.14
-Release:2%{?dist}
+Release:2%{?dist}.1
Summary:PSGI handler for HTTP::Server::Simple
License:GPL+ or Artistic
Group: Development/Libraries
@@ -11,6 +11,7 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTTP::Server::Simple) = 0.42
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(HTTP::Server::Simple::CGI)
%description
HTTP::Server::Simple::PSGI is a HTTP::Server::Simple based HTTP server that
@@ -43,6 +44,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu May 19 2011 Ralf Corsépius corse...@fedoraproject.org 0.14-2.1
+- R: perl(HTTP::Server::Simple::CGI) (BZ #705966).
+
* Mon Mar 14 2011 Ralf Corsépius corse...@fedoraproject.org 0.14-2
- Spec cleanup.
--
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-HTTP-Server-Simple-PSGI/f13] R: perl(HTTP::Server::Simple::CGI) (BZ #705966).
Summary of changes: 12acbda... R: perl(HTTP::Server::Simple::CGI) (BZ #705966). (*) (*) 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 703430] perlbrew-0.20 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=703430 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perlbrew-0.20-1.fc15 Resolution||ERRATA Last Closed||2011-05-19 00:58:15 -- 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 705966] perl-HTTP-Server-Simple-PSGI: the F13 and F14 RPMS fail to require perl(HTTP::Server::Simple::CGI)
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=705966 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2011-05-19 01:55:54 EDT --- perl-HTTP-Server-Simple-PSGI-0.14-2.fc13.1 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/perl-HTTP-Server-Simple-PSGI-0.14-2.fc13.1 -- 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
