Are their guidelines for packaging translated man pages?
I have a package that supplies translated man pages (only in Ukrainian
strangely enough). They are installed by the upstream under:
%{_mandir}/uk/man1/
%{_mandir}/uk/man3/
Maybe my Google-fu is failing me, but I can't find any guidelines on
how to package these for Fedora. Should I create a separate
subpackage (foo-man-pages-uk)? Is the installation directory above
correct?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 721337] perl-Fedora-Rebuild-0.5.0 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=721337 --- Comment #4 from Petr Pisar ppi...@redhat.com 2011-07-18 04:00:50 EDT --- *** Bug 722660 has been marked as a duplicate of this bug. *** -- 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 722660] perl-Fedora-Rebuild-0.5.1 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=722660 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||DUPLICATE Last Closed||2011-07-18 04:00:50 --- Comment #1 from Petr Pisar ppi...@redhat.com 2011-07-18 04:00:50 EDT --- *** This bug has been marked as a duplicate of bug 721337 *** -- 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: Are their guidelines for packaging translated man pages?
On Mon, 2011-07-18 at 08:57 +0100, Richard W.M. Jones wrote:
I have a package that supplies translated man pages (only in Ukrainian
strangely enough). They are installed by the upstream under:
%{_mandir}/uk/man1/
%{_mandir}/uk/man3/
I would use
%lang(uk) %{_mandir}/uk/man1/foo.1*
in this case.
- Andreas
--
BrandAss Andreas Bierfert, M.Sc. | phone: +49 6897 1721738 | GPG: C58CF1CB
andreas.bierf...@lowlatency.de | fax: +49 6897 1722828 | signed/encrypted
http://lowlatency.de | cell: +49 170 9665206 | mail preferred
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: Are their guidelines for packaging translated man pages?
On Mon, Jul 18, 2011 at 10:09:21AM +0200, Andreas Bierfert wrote:
On Mon, 2011-07-18 at 08:57 +0100, Richard W.M. Jones wrote:
I have a package that supplies translated man pages (only in Ukrainian
strangely enough). They are installed by the upstream under:
%{_mandir}/uk/man1/
%{_mandir}/uk/man3/
I would use
%lang(uk) %{_mandir}/uk/man1/foo.1*
in this case.
%lang marks certain files as only being of use with particular
languages according to [1]. Does RPM do anything else with these
annotations?
Rich.
[1]
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s05s04.html
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are their guidelines for packaging translated man pages?
On Mon, 18 Jul 2011 09:45:33 +0100, RWMJ (Richard) wrote:
On Mon, Jul 18, 2011 at 10:09:21AM +0200, Andreas Bierfert wrote:
On Mon, 2011-07-18 at 08:57 +0100, Richard W.M. Jones wrote:
I have a package that supplies translated man pages (only in Ukrainian
strangely enough). They are installed by the upstream under:
%{_mandir}/uk/man1/
%{_mandir}/uk/man3/
I would use
%lang(uk) %{_mandir}/uk/man1/foo.1*
in this case.
%lang marks certain files as only being of use with particular
languages according to [1]. Does RPM do anything else with these
annotations?
Rich.
[1]
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch09s05s04.html
One can define a system's %_install_langs variable appropriately and have RPM
install only files in specific languages. Not solely for saving space, but to
exclude documentation in languages the users don't understand anyway.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
update sg3_utils to 1.31
Hello, I have updated sg3_utils in rawhide to 1.31. The API/ABI of the libsgutils2 library is not considered stable and there is no soname change, so all consumers of the library need to be rebuild. Affected packages are podsleuth (FTBFS due missing hal-devel) libgpod lsvpd (will be built only in ppc koji) sdparm udisks libgpod, sdparm and udisks were successfully rebuilt in koji. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Making . not match special extensions
Do any of you use _. to match e.g. the h extension? Right now _[a-z] does not match the special h extension but does match someone explicitly dialling h. Would it make sense to extend this behaviour to the . and ! patterns, so they never match h? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Inclusion/Exclusion of BuildRoot tag and %defattr
Hi List Referring to sections of Packaging Guidelines: No longer necessary to explicitly include %defattr at the beginning of % files. and the fact that the BuildRoot tag, eve if defined, is ignored. After reviewing packages I have suggested %defattr is not strictly necessary. I have also removed %defattr(-,root,root,-) from my contributed spec file https://bugzilla.redhat.com/show_bug.cgi?id=644711 Is this correct, i.e. do the package review request authors need to be notified? i.e. https://bugzilla.redhat.com/show_bug.cgi?id=720085 (My current reviews state I am new to FP maintainers) Regards Damian L Brasher -- Interlinux Engineering Foundation http://www.interlinux.org.uk Central, non-trading, administration, governance and dissemination of foundation intellectual property and know-how. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110718 changes
Compose started at Mon Jul 18 08:15:54 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) 1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26 1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler.so.13()(64bit) apvlv-0.0.9.8-4.fc16.x86_64 requires libpoppler-glib.so.6()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.0-10.fc16.x86_64 requires libopal.so.3.8.3()(64bit) ekiga-3.3.0-10.fc16.x86_64 requires libpt.so.2.8.3()(64bit) ekiga-3.3.0-10.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) em8300-0.18.0-3.fc15.x86_64 requires /etc/security/console.perms.d evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-sharp-0.21.1-14.fc16.x86_64 requires libcamel-1.2.so.26()(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) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) freedink-engine-1.08.20101114-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) gambas2-gb-pdf-2.23.1-1.fc16.x86_64 requires libpoppler.so.13()(64bit) garden-1.0.8-3.fc15.x86_64 requires liballeg.so.4.2()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gdcm-2.0.17-3.fc16.i686 requires libpoppler.so.13 gdcm-2.0.17-3.fc16.x86_64 requires libpoppler.so.13()(64bit) gedit-valencia-0.3.0-6.20110701git808152718e3ab.fc16.x86_64 requires libvala-0.12.so.0()(64bit) ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSdirectory-1.1.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-time-1.0.0.6-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-locale-1.0.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSfilepath-1.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHScontainers-0.4.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSbase-4.3.1.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-locale-1.0.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSfilepath-1.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires ghc(base-4.3.1.0) = 0:c33a1741503ded8a0170884e8a2e4fa2 ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHScontainers-0.4.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSarray-0.3.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSunix-2.4.2.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSdirectory-1.1.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-devel-0.3.1-9.fc16.i686 requires ghc = 0:7.0.2
Agenda for today's FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #608 F16Feature: Trusted Boot - .fesco 608 #topic #563 suggested policy: all daemons must set RELRO and PIE flags .fesco 563 #topic #615 Strategy for services that do not have systemd native unit files .fesco 615 = New business = #topic #647 Consider 14 features in FeatureReadyForFesco despite the Submission Date passing. .fesco 647 #topic #634 F16Feature: EclipseIndigo .fesco 634 #topic #635 F16Feature: 1000 System Accounts .fesco 635 #topic #636 F16Feature: Chrony default NTP client - .fesco 636 #topic #637 F16Feature: Condor Cloud - .fesco 637 #topic #638 F16Feature: Unified Problem Reporting UI .fesco 638 #topic #639 F16Feature: GCC Python Plugins .fesco 639 #topic #640 F16Feature: Static Analysis of CPython Extensions .fesco 640 #topic #641 F16Feature: GNOME Input Integration .fesco 641 #topic #642 F16Feature: Sugar 0.94 .fesco 642 #topic #644 F16Feature: Spice 0.10 .fesco 644 #topic #645 F16Feature: New mkdumprd for for kdump .fesco 645 #topic #646 F16 Feature: Use Ext4 driver for Ext3 and Ext2 filesystems .fesco 646 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making . not match special extensions
On Mon, Jul 18, 2011 at 8:05 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Do any of you use _. to match e.g. the h extension? Right now _[a-z] does not match the special h extension but does match someone explicitly dialling h. Would it make sense to extend this behaviour to the . and ! patterns, so they never match h? I can only guess that you meant for this to go to one of the Asterisk mailing lists instead of the Fedora development mailing list. Since I still remember a bit about Asterisk from my former career, I'd say it's definitely something worth discussing on the Asterisk mailing lists though. -- Jared Smith Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making . not match special extensions
Benny Amorsen benny+use...@amorsen.dk writes: Do any of you use _. to match e.g. the h extension? Right now _[a-z] does not match the special h extension but does match someone explicitly dialling h. Would it make sense to extend this behaviour to the . and ! patterns, so they never match h? /Benny I am so sorry. I'll hand in my geek card. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inclusion/Exclusion of BuildRoot tag and %defattr
On Mon, Jul 18, 2011 at 01:20:30PM +0100, Damian L Brasher wrote: Hi List Referring to sections of Packaging Guidelines: No longer necessary to explicitly include %defattr at the beginning of % files. and the fact that the BuildRoot tag, eve if defined, is ignored. After reviewing packages I have suggested %defattr is not strictly necessary. I have also removed %defattr(-,root,root,-) from my contributed spec file https://bugzilla.redhat.com/show_bug.cgi?id=644711 Is this correct, i.e. do the package review request authors need to be notified? i.e. https://bugzilla.redhat.com/show_bug.cgi?id=720085 They are now optional but there's no need to force people to be rid of them. In particular, some people like to build a package for both Fedora and EPEL-5. In this case, a lot of the things that are optional in Fedora have to remain for the EPEL package. -Toshio pgpzNIRFAB2zd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Sat, Jul 16, 2011 at 06:27:50PM -0700, Travis Davies wrote: Hi Everyone, Fellow Linux enthusiast here. I am working on developing the netperf rpm package for Fedora. I use this software daily at work and thought why not be the package maintainer, right? Will of course need your feedback and a reviewer for the package. Looking forward to working with all of you. Grettings! Welcome to the fold. There was an attempt to package netperf many years ago: https://bugzilla.redhat.com/show_bug.cgi?id=529105 Could have some useful ideas. -Toshio pgpNtnFBni9uA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
2011/7/18 Denys Vlasenko dvlas...@redhat.com: On Thu, 2011-06-23 at 18:15 +0200, Miloslav Trmač wrote: The TPM allows verifying that this kernel (and only this kernel) is actually running. An attacker with access to the hard drive (evil maid) can modify the code to disable any signature check that would be done in software (e.t. inside grub); TPM cannot be bypassed this way. How is this possible? The kernel was somehow installed. TPM was informed about it (I don't know, sha hash was written into a flash which is physically in the processor?). I'm not quite sure how the installation procedure is supposed to work - however, in the end, a hash that represents the right system is stored in the TPM. Cryptographic keys that are stored in the TPM are then bound to this hash, and accessible only when the booting system matches this hash. Why attacker with physical access to the computer can't install his tampered kernel and save its hash? Once the cryptographic keys are bound to a specific hash, the attacker can not access them without booting system that matches this hash. An attacker can not boot a different system and then change the hash to which the key is bound. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
disper review request - On-the-fly display switch utility
Hi to all, anybody would review my new package disper? https://bugzilla.redhat.com/show_bug.cgi?id=712579 Thank you in advance! -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Agenda for today's FESCo meeting
=== #fedora-meeting: FESCO (2011-07-18) === Meeting started by mjg59 at 17:01:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-07-18/fesco.2011-07-18-17.01.log.html . Meeting summary --- * init process (mjg59, 17:02:52) * #608 F16Feature: Trusted Boot (mjg59, 17:03:53) * AGREED: , Trusted boot is approved as an optional F16 feature (mjg59, 17:13:20) * #563 suggested policy: all daemons must set RELRO and PIE flags (mjg59, 17:13:48) * AGREED: Work on tuning the criteria and revisit next week (mjg59, 17:25:49) * #615 Strategy for services that do not have systemd native unit files (mjg59, 17:25:57) * LINK: https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd (Viking-Ice, 17:28:09) * LINK: http://fpaste.org/ErRL/ (Viking-Ice, 17:28:32) * #647 Consider 14 features in FeatureReadyForFesco despite the Submission Date passing. (mjg59, 17:35:14) * AGREED: Fesco will consider these features (mjg59, 17:36:25) * #634 F16Feature: EclipseIndigo (mjg59, 17:36:35) * AGREED: Eclipse Indigo is approved as an F16 feature (mjg59, 17:37:32) * #635 F16Feature: 1000 System Accounts (mjg59, 17:37:37) * AGREED: 1000 System Accounts is approved as a Fedora feature (mjg59, 17:38:43) * #636 F16Feature: Chrony default NTP client (mjg59, 17:38:47) * AGREED: Chrony approved as the default NTP client (mjg59, 17:39:51) * #637 F16Feature: Condor Cloud (mjg59, 17:40:50) * AGREED: Condor Cloud is approved as an F16 feature (mjg59, 17:42:18) * #638 F16Feature: Unified Problem Reporting UI (mjg59, 17:42:31) * AGREED: Unified Problem Reporting UI is approved as an F16 feature (mjg59, 17:43:54) * #639 F16Feature: GCC Python Plugins (mjg59, 17:44:55) * AGREED: GCC Python Plugins are an approved F16 feature (mjg59, 17:45:58) * #639 F16Feature: GCC Python Plugins (mjg59, 17:46:08) * #640 F16Feature: Static Analysis of CPython Extensions (mjg59, 17:46:37) * AGREED: Static Analysis of CPython Extensions is an approved F16 features (mjg59, 17:47:19) * #641 F16Feature: GNOME Input Integration (mjg59, 17:47:32) * AGREED: Gnome Input Integration is an approved F16 feature (mjg59, 17:50:12) * #642 F16Feature: Sugar 0.94 (mjg59, 17:50:17) * AGREED: Sugar 0.94 is an approved F16 feature (mjg59, 17:51:30) * #644 F16Feature: Spice 0.10 (mjg59, 17:51:34) * AGREED: Spice 0.10 is an approved F16 feature (mjg59, 17:53:08) * #645 F16Feature: New mkdumprd for for kdump (mjg59, 17:53:16) * AGREED: New mkdumprd for kdump is an approved F16 feature (mjg59, 17:56:18) * #646 F16 Feature: Use Ext4 driver for Ext3 and Ext2 filesystems (mjg59, 17:56:24) * AGREED: Use Ext4 driver for Ext3 and Ext2 filesystems is an approved F16 feature (mjg59, 17:57:14) * Next week's chair (mjg59, 17:57:38) * AGREED: notting to chair next week's meeting (mjg59, 17:57:57) * Open Floor (mjg59, 18:01:38) * LINK: http://lists.fedoraproject.org/pipermail/devel/2011-July/154345.html , in case anyone didn't see it (adamw, 18:02:31) Meeting ended at 18:05:25 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * mjg59 (144) * nirik (59) * pjones (55) * ajax (38) * t8m (32) * notting (29) * zodbot (21) * Viking-Ice (13) * mmaslano (13) * abadger1999 (9) * adamw (4) * Slower (3) * rbergeron (3) * dvlasenk (3) * gholms (1) * sgallagh (0) * cwickert (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disper review request - On-the-fly display switch utility
The upstream website says that right now it's only tested and working with the binary nvidia drivers. Does this actually work with xrandr? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
on /etc/sysconfig
This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. Just my $2. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTTP-Server-Simple-Mason/el6] (9 commits) ...Merge branch 'master' into el6
Summary of changes: b90cd1d... - Upstream update. (*) c3a3b87... Fix typo that causes a failure to update the common directo (*) 75065f0... - rebuild against perl 5.10.1 (*) 03fa3db... - Mass rebuild with perl-5.12.0 (*) be75a3c... dist-git conversion (*) 03e5901... - Upstream update. (*) cf4ebcd... - 661697 rebuild for fixing problems with vendorach/lib (*) 2d1eb60... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) f308d83... Merge branch 'master' into el6 (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-Server-Simple-Mason/el6: 9/9] Merge branch 'master' into el6
commit f308d83740ca9e3274ed93882a452250463af647 Merge: 353f86d 2d1eb60 Author: Xavier Bachelot xav...@bachelot.org Date: Mon Jul 18 20:58:50 2011 +0200 Merge branch 'master' into el6 Conflicts: .gitignore perl-HTTP-Server-Simple-Mason.spec sources .gitignore |2 +- perl-HTTP-Server-Simple-Mason.spec | 19 +-- sources|2 +- 3 files changed, 19 insertions(+), 4 deletions(-) --- -- 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: FESCo: Feature process and release blocker process
On Sat, 2011-07-16 at 12:48 -0600, Kevin Fenzi wrote: On Thu, 14 Jul 2011 19:36:10 -0700 Adam Williamson awill...@redhat.com wrote: ...snip... We wanted to check that this was okay with FESCo and the feature wrangler and the project in general before going ahead, so here we are =) Please let us know if anyone is worried about this. Thanks! Speaking only for myself (I suspect we should have FESCo discuss at their next meeting), this sounds completely reasonable to me. Each of the groups involved in a release should have a say (and does at the go/no go meeting). QA should focus on their testing and QA efforts to decide if they are go or no-go. Other groups may have their own criteria. Thanks. For the record, we brought this up at today's FESCo meeting, everyone agreed it sounded reasonable, and so I have added the following paragraph to https://fedoraproject.org/wiki/Template:Release_criteria_definition : A Fedora feature being incomplete, in and of itself, does not constitute a blocker bug. The feature process is separate from this process. Features are required to meet certain standards at certain points of the release cycle, but this is part of the feature process and managed, tracked and enforced separately from this process. However, if a proposed feature being incomplete causes any of the above criteria to be met, then the bug is a release blocker. (various of those words are hyperlinks to other bits of the wiki, to make it easier to see what the 'feature process' is and so on). This template is transcluded in the release criteria pages for each phase: https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria I hope this is a clear and concise way to formalize the distinction between the release validation and feature processes. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On 07/18/2011 06:57 PM, Lennart Poettering wrote: On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Beckerndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Agreed... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inclusion/Exclusion of BuildRoot tag and %defattr
TK == Toshio Kuratomi a.bad...@gmail.com writes: TK They are now optional but there's no need to force people to be rid TK of them. In particular, some people like to build a package for both TK Fedora and EPEL-5. In this case, a lot of the things that are TK optional in Fedora have to remain for the EPEL package. Note that according to our guideline page only RPM releases older than 4.4 require %defattr, which would limit the requirement for it to specs which need to build unmodified on EL4. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18.07.11 15:13, Simo Sorce (s...@redhat.com) wrote: On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inclusion/Exclusion of BuildRoot tag and %defattr
On Mon, Jul 18, 2011 at 02:14:48PM -0500, Jason L Tibbitts III wrote: TK == Toshio Kuratomi a.bad...@gmail.com writes: TK They are now optional but there's no need to force people to be rid TK of them. In particular, some people like to build a package for both TK Fedora and EPEL-5. In this case, a lot of the things that are TK optional in Fedora have to remain for the EPEL package. Note that according to our guideline page only RPM releases older than 4.4 require %defattr, which would limit the requirement for it to specs which need to build unmodified on EL4. Ah... I always forget that -- %defattr is optional in EL-5 but not EL-4 ; buildroot is needed even in EL-5. https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines -Toshio pgpDPZ78Kb0ol.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 11:13 AM, Simo Sorce s...@redhat.com wrote: Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. If I were a betting man I'd wager that all the daemons we ship are easier to fix than the US deficit (in both the technical sense and in the sense of political will to make the necessary changes.) The necessary political will to obsolete /etc/sysconfig may not exist at this very moment but I think that the reasoning is sound enough that anticipating, identifying and mitigating potential problems the removal would cause seems a reasonable use of someones time to minimize the disruption such a removal will cause in the year or two leading up to it actually happening. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
Simo Sorce s...@redhat.com writes: On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: http://0pointer.de/blog/projects/on-etc-sysinit.html No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Well, if they didn't need fixed before, they'll certainly need fixed when you make them start keeping their configuration info someplace else than /etc/sysconfig. This proposal sounds more like wait, systemd has not yet broken everything in sight, how can we solve that problem? than like something that will actually improve matters for anyone. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 09:16:13PM +0200, Lennart Poettering wrote: SNIP Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. Lennart SNIP What about /etc/sysconfig/network and /etc/sysconfig/network-scripts/ ... where would be a more appropriate location for those? Not saying there isn't one, just wondering what the logical progression would be since that's not really a daemon so much a munge of scripts and config files that handle network bits... similar question for others like that which have service entries in /etc/init.d/ but aren't actually daemons. -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18.07.11 15:34, Tom Lane (t...@redhat.com) wrote: Simo Sorce s...@redhat.com writes: On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: http://0pointer.de/blog/projects/on-etc-sysinit.html No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Well, if they didn't need fixed before, they'll certainly need fixed when you make them start keeping their configuration info someplace else than /etc/sysconfig. This proposal sounds more like wait, systemd has not yet broken everything in sight, how can we solve that problem? than like something that will actually improve matters for anyone. What does systemd break in this regard? The blog article even explains what you need to do when you really want to continue using a sysconfig file. Also, what phasing out sysconfig gains you is explained in detail in the blog story, and that's all I have to say on this. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
Lennart Poettering mzerq...@0pointer.de writes: On Mon, 18.07.11 15:34, Tom Lane (t...@redhat.com) wrote: Well, if they didn't need fixed before, they'll certainly need fixed when you make them start keeping their configuration info someplace else than /etc/sysconfig. This proposal sounds more like wait, systemd has not yet broken everything in sight, how can we solve that problem? than like something that will actually improve matters for anyone. What does systemd break in this regard? There's a big difference between a daemon might not need /etc/sysconfig anymore once it's been fully integrated into the systemd world and let's deprecate /etc/sysconfig and force packages to stop using it. Maybe you meant the first, but it's coming across as the second. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 21:45, Adam Miller maxamill...@fedoraproject.org wrote: On Mon, Jul 18, 2011 at 09:16:13PM +0200, Lennart Poettering wrote: SNIP Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. Lennart SNIP What about /etc/sysconfig/network and /etc/sysconfig/network-scripts/ ... where would be a more appropriate location for those? Not saying there isn't one, just wondering what the logical progression would be since that's not really a daemon so much a munge of scripts and config files that handle network bits... similar question for others like that which have service entries in /etc/init.d/ but aren't actually daemons. There are no clear plans. If someone would come up with a unified network interface config format all distros could use, it would go into some new top-level dir in /etc and not in /etc/sysconfig. Until that happens we will surely continue to use it, but look at it as 'inherited' and not something to extend or base future work on. What we have today is /etc/NetworkManager/system-connections/, but that probably doesn't solve that problem. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 21:59, Tom Lane t...@redhat.com wrote: Lennart Poettering mzerq...@0pointer.de writes: On Mon, 18.07.11 15:34, Tom Lane (t...@redhat.com) wrote: Well, if they didn't need fixed before, they'll certainly need fixed when you make them start keeping their configuration info someplace else than /etc/sysconfig. This proposal sounds more like wait, systemd has not yet broken everything in sight, how can we solve that problem? than like something that will actually improve matters for anyone. What does systemd break in this regard? There's a big difference between a daemon might not need /etc/sysconfig anymore once it's been fully integrated into the systemd world and let's deprecate /etc/sysconfig and force packages to stop using it. Maybe you meant the first, but it's coming across as the second. The 'force' seems to be in your head only. :) We are just communicating that /etc/sysconfig should be phased out, and no new work should be based on it. It should be seen as legacy. Many basic configurations formerly in /etc/sysconfig we have already move to proper /etc config files, and we might continue to do so. /etc/sysconfig is a hack and a pretty bad idea in the first place. Stuff should get native configurations as much as possible, not distro-specific configs. Some day /etc/sysconfig should be almost empty, and then we will see what to do about it, but that might take a very long time, until then there is no need to rush anything. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boost 1.47.0
Hi there, in accordance with the announced Fedora feature[1][2], we (the Boost maintainers) plan to rebase Boost to 1.47.0 really soon now. Boost 1.47.0 has been released recently and Denis Arnaud kindly did the packaging, so it is ready for scratch builds, smoke testing, and related fun. I'll do that in the next few days and if all comes out green-ish, I'll push the package into Fedora 16 and write a follow-up to this e-mail with guidelines on overcoming the obstacles, if any. Further plans: originally, we hoped that 1.48.0 would be about out by now, and we would manage to get beta into Fedora 16, much like we did with 1.46.0 for Fedora 15. But the Boost schedule slipped, and made any such plans impossible to realize[2]. At the same time, the sentiment of Boost upstream seems to be to (gradually) get back to the original schedule, so we may end up with 1.50.0 in Fedora 17. Handling +3 bump might end up being more interesting than is desirable, so to alleviate this, we will most probably want to do at least one larger rebase mid-Rawhide, either to 1.48.0, or 1.49.0. I'll write more when I know more. Don't hesitate to ping me on irc (_petr) with any concerns that you have. [1] https://fedoraproject.org/wiki/Features/F16Boost147 [2] https://bugzilla.redhat.com/show_bug.cgi?id=711845 Thanks, Petr Machata -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disper review request - On-the-fly display switch utility
In data 18/7/2011 20:34:17, Matthew Garrett ha scritto: The upstream website says that right now it's only tested and working with the binary nvidia drivers. Does this actually work with xrandr? The developer tell me that disper use libxrandr, if some users had problems with the ctypes-based interface the developer tell me that there is a: workaround I reverted to calling the xrandr binary when the former would fail. I have got an nvidia card and for the next month I can't test it on other hardware, sorry. With this package I hope to help the project with other users feedback. -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 8:30 PM, Jeff Spaleta jspal...@gmail.com wrote: On Mon, Jul 18, 2011 at 11:13 AM, Simo Sorce s...@redhat.com wrote: Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. If I were a betting man I'd wager that all the daemons we ship are easier to fix than the US deficit (in both the technical sense and in the sense of political will to make the necessary changes.) The necessary political will to obsolete /etc/sysconfig may not exist at this very moment but I think that the reasoning is sound enough that anticipating, identifying and mitigating potential problems the removal would cause seems a reasonable use of someones time to minimize the disruption such a removal will cause in the year or two leading up to it actually happening. I guess the process can be started - but by the time it is ready for prime time then any daemons that need to work should have been tested to work without the need for any /etc/sysconfig/... files - just by the way what then out of interest is the replacement for a /etc/sysconfig/desktop file that defines which login manager should be the default (and which is not there by default)? Can KDM then be started when X starts and not GDM without the use of the above file? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are their guidelines for packaging translated man pages?
On 07/18/2011 11:09 AM, Andreas Bierfert wrote:
On Mon, 2011-07-18 at 08:57 +0100, Richard W.M. Jones wrote:
I have a package that supplies translated man pages (only in Ukrainian
strangely enough). They are installed by the upstream under:
%{_mandir}/uk/man1/
%{_mandir}/uk/man3/
I would use
%lang(uk) %{_mandir}/uk/man1/foo.1*
in this case.
%find_lang's --with-man argument can be used for this too.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 02:46:30PM -0400, Neal Becker wrote: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html I'm sympathetic to Lennart's arguments, but really this should be discussed and decided in the context of a real, open forum, drawing interested people from all of the Linux distros (possibly BSD etc too). Perhaps LSB? So I don't think changes like this, and /etc/machine-id, and /etc/os-release and others should come by fiat, although (again) I'm very sympathetic to why these things are being done. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 2011-07-18 at 21:16 +0200, Lennart Poettering wrote: On Mon, 18.07.11 15:13, Simo Sorce (s...@redhat.com) wrote: On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. Asking some upstream to add a whole configuration file reading subsystem to extremely simple daemons that accept a handful of command line options can be rightfully answered with a simple no. Command line options are nothing wrong and have been around for ages, there is nothing to fix in daemons that do not read a config file. But most of the changes in this area look gratuitous to me. They will cause significant changes in admin tools and configurations and therefore significant grief. Note that I am not necessarily against changing stuff in the long term, when I started there was no /etc/sysconfig, and I won't cry if it goes away and is replaced with a bunch of 'different' config files, big deal ... same stuff just in different places, what a revolution! But your attitude of defining 'broken' anything that doesn't conform to your view of the world, is frankly tiring and not constructive. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 11:00 PM, Simo Sorce s...@redhat.com wrote: On Mon, 2011-07-18 at 21:16 +0200, Lennart Poettering wrote: On Mon, 18.07.11 15:13, Simo Sorce (s...@redhat.com) wrote: On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. Asking some upstream to add a whole configuration file reading subsystem to extremely simple daemons that accept a handful of command line options can be rightfully answered with a simple no. Command line options are nothing wrong and have been around for ages, there is nothing to fix in daemons that do not read a config file. But most of the changes in this area look gratuitous to me. They will cause significant changes in admin tools and configurations and therefore significant grief. Note that I am not necessarily against changing stuff in the long term, when I started there was no /etc/sysconfig, and I won't cry if it goes away and is replaced with a bunch of 'different' config files, big deal ... same stuff just in different places, what a revolution! The revolution would be having the staff in the same location in every distro. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 12:42 PM, mike cloaked mike.cloa...@gmail.com wrote: I guess the process can be started - but by the time it is ready for prime time then any daemons that need to work should have been tested to work without the need for any /etc/sysconfig/... files - just by the way what then out of interest is the replacement for a /etc/sysconfig/desktop file that defines which login manager should be the default (and which is not there by default)? Can KDM then be started when X starts and not GDM without the use of the above file? I don't have a ready answer for that. But instead I'll ask you a related question. If I have a serviced service stack which depends on some httpd daemon to operate correctly, and the service dependencies are generated to make sure that one of the installed httpd daemon runs on start up. How do I go about making sure that one and only one of the following httpd servers of my choosing starts up? apache httpd or lighttpd or cherokee From a packaging standpoing our packages use the virtual provide : webserver. But how do we as administrators make sure that the non-default webserver we want used is used in our init stack? There's no sysconfig for this is there? There's no prefhttpd that fills the role of the prefdm logic. So what's the general solution for choice among equals among services at init? Is prefdm and /etc/sysconfig/desktop like constructions really what we want to replicate as the best practice way of dealing with this ? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18.07.11 21:57, Richard W.M. Jones (rjo...@redhat.com) wrote: On Mon, Jul 18, 2011 at 02:46:30PM -0400, Neal Becker wrote: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html I'm sympathetic to Lennart's arguments, but really this should be discussed and decided in the context of a real, open forum, drawing interested people from all of the Linux distros (possibly BSD etc too). Perhaps LSB? Whether to get rid of /etc/sysconfig is a decision for Fedora and only Fedora, since it's a Fedoraism. Other distros have similar dirs, but under different names and with different contents. LSB has no beef with this really, since the question is whether to get rid of it -- not whether to standardize it. So I don't think changes like this, and /etc/machine-id, and /etc/os-release and others should come by fiat, although (again) I'm very sympathetic to why these things are being done. These interfaces introduced by systemd are actually discussed in quite some detail on the systemd irc channel and mailing list. It's a very open forum, you are welcome to join. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
Hi, On Mon, Jul 18, 2011 at 4:42 PM, mike cloaked mike.cloa...@gmail.com wrote: what then out of interest is the replacement for a /etc/sysconfig/desktop file that defines which login manager should be the default (and which is not there by default)? Can KDM then be started when X starts and not GDM without the use of the above file? I recently brought up this question on systemd-devel as I was packaging a desktop environment with a display manager, and it sounded like there would be a push to move away from prefdm itself in favor of giving each display manager a service file. I implemented this in the package and switch between display managers with the following command (with newdm being the selected one). ln -fs /lib/systemd/system/newdm.service /etc/systemd/system/display-manager.service David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 11:14 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 18.07.11 21:57, Richard W.M. Jones (rjo...@redhat.com) wrote: On Mon, Jul 18, 2011 at 02:46:30PM -0400, Neal Becker wrote: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html I'm sympathetic to Lennart's arguments, but really this should be discussed and decided in the context of a real, open forum, drawing interested people from all of the Linux distros (possibly BSD etc too). Perhaps LSB? Whether to get rid of /etc/sysconfig is a decision for Fedora and only Fedora, since it's a Fedoraism. Other distros have similar dirs, but under different names and with different contents. LSB has no beef with this really, since the question is whether to get rid of it -- not whether to standardize it. So I don't think changes like this, and /etc/machine-id, and /etc/os-release and others should come by fiat, although (again) I'm very sympathetic to why these things are being done. These interfaces introduced by systemd are actually discussed in quite some detail on the systemd irc channel and mailing list. It's a very open forum, you are welcome to join. So Fedora is the right place to discuss removal of its existing configuration, but not the design of the new configuration? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
David Michael (fedora@gmail.com) said: what then out of interest is the replacement for a /etc/sysconfig/desktop file that defines which login manager should be the default (and which is not there by default)? Can KDM then be started when X starts and not GDM without the use of the above file? I recently brought up this question on systemd-devel as I was packaging a desktop environment with a display manager, and it sounded like there would be a push to move away from prefdm itself in favor of giving each display manager a service file. I implemented this in the package and switch between display managers with the following command (with newdm being the selected one). ln -fs /lib/systemd/system/newdm.service /etc/systemd/system/display-manager.service Right, but that then causes 'last one wins' behavior among multiple DMs. I suppose we could use alternatives for this, as much as I dislike it. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18 Jul 2011, Lennart Poettering wrote: On Mon, 18.07.11 15:13, Simo Sorce (s...@redhat.com) wrote: On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: On Mon, 18.07.11 20:54, Michał Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. I'd suggest we're shipping software that doesn't need to be modified, doesn't need to be fixed. Saying those daemons need to be fixed is like saying a pregnant woman need to go to the hospital to be cured. Pregnancy and /etc/sysconfig are perfectly natural and healthy. Pregnant women and /etc/sysconfig both have perfectly valid use cases and do not need to be fixed :) -Mike-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18.07.11 17:00, Simo Sorce (s...@redhat.com) wrote: Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. Asking some upstream to add a whole configuration file reading subsystem to extremely simple daemons that accept a handful of command line options can be rightfully answered with a simple no. Example please? Command line options are nothing wrong and have been around for ages, there is nothing to fix in daemons that do not read a config file. Command line options are not wrong, they are completely fine. What I am saying that faking configuration files, by having wrapper scripts which build command lines from env var config files is not ideal. But this was already discussed on this very ML, so I see no reason to warm this up again. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18.07.11 23:17, Miloslav Trmač (m...@volny.cz) wrote: These interfaces introduced by systemd are actually discussed in quite some detail on the systemd irc channel and mailing list. It's a very open forum, you are welcome to join. So Fedora is the right place to discuss removal of its existing configuration, but not the design of the new configuration? If this new configuration is something that shall be shared with other distributions, then yes, fedora-devel is probably not the right place to discuss its initial design. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 10:57 PM, Richard W.M. Jones rjo...@redhat.com wrote:
I'm sympathetic to Lennart's arguments, but really this should be
discussed and decided in the context of a real, open forum, drawing
interested people from all of the Linux distros (possibly BSD etc
too). Perhaps LSB?
/etc/sysconfig is not a file format standard.
/etc/sysconfig is not a place where configuration files of the same
format or purpose are stored.
/etc/sysconfig is not a place used to store configuration shared by
independent software packages.
/etc/sysconfig is not a software package.
I can't see a reason to discuss /etc/sysconfig as a single unit, nor
to argue for removal of /etc/sysconfig a single unit, nor to try to
form a definite consensus about /etc/sysconfig.
/etc/sysconfig is a conventional place where various
distribution-specific software stores its configuration.
Note the two primary attributes:
* _various_ software: Each file needs to be discussed separately, in
the context of the software that uses it.
/etc/sysconfig/{crond,iptables,nspluginwrapper} have nothing in
common, and need to be considered separately together with the
software that uses these files.
* _distribution-specific_: There's no point in defining a common
standard for software that is not commonly used. Replacing
distribution-specific software by distribution-shared software may be
beneficial, and it may make the distribution-specific config file
obsolete, but writing the common software common needs to come
_first_. Only then can we think about making the configuration common
- and often we may find that breaking backward compatibility with
configuration in /etc/sysconfig doesn't buy anything.
This discussion really seems to be not about /etc/sysconfig, but about
configuration of the distribution-specific software in /etc/init.d
that is scheduled to go away by F16 - but having a plan (and, mostly,
manpower) for removing the code in F16 without having corresponding
plans (_and_ manpower) for agreeing upon, implementing, and
integrating, corresponding software into the various upstreams, is
putting the cart before the horse.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
Hi, On Mon, Jul 18, 2011 at 5:16 PM, Bill Nottingham nott...@redhat.com wrote: Right, but that then causes 'last one wins' behavior among multiple DMs. I suppose we could use alternatives for this, as much as I dislike it. I meant creating that symlink was the replacement for /etc/sysconfig/desktop, the end-user configuration. As for what packages do about their DM service files, I would agree with letting alternatives manage a default /lib/systemd/system/display-manager.service symlink, but leave the one in /etc for the users to specify. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 23:20, Mike McGrath mmcgr...@redhat.com wrote: On Mon, 18 Jul 2011, Lennart Poettering wrote: Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. I'd suggest we're shipping software that doesn't need to be modified, doesn't need to be fixed. Saying those daemons need to be fixed is like saying a pregnant woman need to go to the hospital to be cured. Pregnancy and /etc/sysconfig are perfectly natural and healthy. Pregnant women and /etc/sysconfig both have perfectly valid use cases and do not need to be fixed :) Most pregnancies last ~40 weeks. If that takes much longer it needs to be fixed. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 23:27, David Michael fedora@gmail.com wrote: On Mon, Jul 18, 2011 at 5:16 PM, Bill Nottingham nott...@redhat.com wrote: Right, but that then causes 'last one wins' behavior among multiple DMs. I suppose we could use alternatives for this, as much as I dislike it. I meant creating that symlink was the replacement for /etc/sysconfig/desktop, the end-user configuration. Yes, this link will replace the config file. As for what packages do about their DM service files, I would agree with letting alternatives manage a default /lib/systemd/system/display-manager.service symlink, We should not let packages create config files in lib, lib is more for static content from rpms, not really for configuration. For the same reason, 'systemctl enable/disable' acts on /etc only. but leave the one in /etc for the users to specify. The link in etc would need to be managed by alternatives, but I'm not sure, if it's really necessary. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18.07.11 23:26, Miloslav Trmač (m...@volny.cz) wrote:
On Mon, Jul 18, 2011 at 10:57 PM, Richard W.M. Jones rjo...@redhat.com
wrote:
I'm sympathetic to Lennart's arguments, but really this should be
discussed and decided in the context of a real, open forum, drawing
interested people from all of the Linux distros (possibly BSD etc
too). Perhaps LSB?
/etc/sysconfig is not a file format standard.
/etc/sysconfig is not a place where configuration files of the same
format or purpose are stored.
/etc/sysconfig is not a place used to store configuration shared by
independent software packages.
/etc/sysconfig is not a software package.
I can't see a reason to discuss /etc/sysconfig as a single unit, nor
to argue for removal of /etc/sysconfig a single unit, nor to try to
form a definite consensus about /etc/sysconfig.
Oh, it definitely can be discussed as single unit. Check the Fedora
packaging guidelines:
http://fedoraproject.org/wiki/Packaging:SysVInitScript
Although init files live in /etc, they are scripts to be executed, not
configured. Any configuration should be made available through
/etc/sysconfig/service rather than in the init script itself. A valid
exception to this rule would be existing packages where configuration is
still done via the init file. In this case, the init file could be
marked as %config following the rules from the Configuration files
section to preserve a users configuration upon upgrade, hopefully so
that the user can migrate said configuration to a new
/etc/sysconfig/service config file.
Now, this is very terse, and leaves the file format of this file
undefined, but given that sysv init scripts are shell scripts, and given
the usual contents of the dir I think it is reasonably safe to assume
that these files are generally shell fragments.
Of course, this is not the only use of /etc/sysconfig right now. There's
a lot of other stuff in it, but I would still say that the primary use
of the dir and most files placed in it have been placed there following
the rules of the guidelines. (If that was not the case we had a major
problem with namespacing issues.)
/etc/sysconfig is a conventional place where various
distribution-specific software stores its configuration.
Note the two primary attributes:
* _various_ software: Each file needs to be discussed separately, in
the context of the software that uses it.
/etc/sysconfig/{crond,iptables,nspluginwrapper} have nothing in
common, and need to be considered separately together with the
software that uses these files.
Nah, not true. The packaging guidelines say explicitly what you should
place in that directory. When we discuss getting rid of the dir we are
also talking about updating the guidelines.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 2011-07-18 at 15:59 -0400, Tom Lane wrote: Lennart Poettering mzerq...@0pointer.de writes: On Mon, 18.07.11 15:34, Tom Lane (t...@redhat.com) wrote: Well, if they didn't need fixed before, they'll certainly need fixed when you make them start keeping their configuration info someplace else than /etc/sysconfig. This proposal sounds more like wait, systemd has not yet broken everything in sight, how can we solve that problem? than like something that will actually improve matters for anyone. What does systemd break in this regard? There's a big difference between a daemon might not need /etc/sysconfig anymore once it's been fully integrated into the systemd world and let's deprecate /etc/sysconfig and force packages to stop using it. Maybe you meant the first, but it's coming across as the second. Observation suggests that you often need to assert the latter in order to achieve the former, when it comes to herding cats^H^H^H^Hopen source developers... -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Posting not allowed?
Hi, I'm using the gmane gateway to read the list and I'm getting Posting not allowed errors across all the lists I've tried. Is it just me or are others seeing this? --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 2011-07-18 at 23:14 +0200, Lennart Poettering wrote: On Mon, 18.07.11 21:57, Richard W.M. Jones (rjo...@redhat.com) wrote: On Mon, Jul 18, 2011 at 02:46:30PM -0400, Neal Becker wrote: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html I'm sympathetic to Lennart's arguments, but really this should be discussed and decided in the context of a real, open forum, drawing interested people from all of the Linux distros (possibly BSD etc too). Perhaps LSB? Whether to get rid of /etc/sysconfig is a decision for Fedora and only Fedora, since it's a Fedoraism. Other distros have similar dirs, but under different names and with different contents. Mandriva uses the same directory. Mainly as an inheritance from Red Hat, to be sure. -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Posting not allowed?
On 07/19/2011 12:38 AM, Ben Boeckel wrote: Hi, I'm using the gmane gateway to read the list and I'm getting Posting not allowed errors across all the lists I've tried. Is it just me or are others seeing this? --Ben If you're reading this, posting through the gmane newsgroup works. -- Veeti Paananen - gmane user -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
Hi, On Mon, Jul 18, 2011 at 5:32 PM, Kay Sievers kay.siev...@vrfy.org wrote: We should not let packages create config files in lib, lib is more for static content from rpms, not really for configuration. For the same reason, 'systemctl enable/disable' acts on /etc only. I had imagined using alternatives would allow the symlink /lib/systemd/system/display-manager.service to be provided by systemd-units (as it is now), just pointed at /etc/alternatives instead of prefdm.service. The link in etc would need to be managed by alternatives, but I'm not sure, if it's really necessary. In order to do that, wouldn't an RPM have to own the service link in /etc? I was under the impression that packages weren't supposed to own anything under /etc/systemd/system. Regardless, I think I'm off-topic from the rest of the thread, so I will leave these details alone for the time being. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Posting not allowed?
On Mon, Jul 18, 2011 at 17:38:30 -0400, Ben Boeckel wrote: I'm using the gmane gateway to read the list and I'm getting Posting not allowed errors across all the lists I've tried. Is it just me or are others seeing this? Hrm...seems tin isn't getting a FQDN when starting up and then refusing to post...probably my ISP being weird. :( --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, 18 Jul 2011, Lennart Poettering wrote: On Mon, 18.07.11 15:13, Simo Sorce (s...@redhat.com) wrote: On Mon, 2011-07-18 at 20:57 +0200, Lennart Poettering wrote: On Mon, 18.07.11 20:54, MichaÅ Piotrowski (mkkp...@gmail.com) wrote: Hi, 2011/7/18 Neal Becker ndbeck...@gmail.com: This article recommends ending /etc/sysconfig http://0pointer.de/blog/projects/on-etc-sysinit.html Generally speaking I like the idea of dropping /etc/sysconfig. I think the right way it keeping minimal, standardized configuration in /etc/services.conf/ or something like that. No. There is no need for a directory that replaces /etc/sysconfig. It's borked. If a daemon has not configuration file but should have one, then fix the daemon, don't fake a configuration file. Some daemons cannot be fixed, get over with this mantra that daemons need be fixed Lennart. Hmm? Which ones in fedora can't? Are you suggesting we are shipping software that cannot be modified? If so, please explain which one that is, since we need to remove it from the distro then. Fedora only includess Free Software, and software that cannot be modified would not qualify as that. I'd suggest we're shipping software that doesn't need to be modified, doesn't need to be fixed. Saying those daemons need to be fixed is like saying a pregnant woman need to go to the hospital to be cured. Pregnancy and /etc/sysconfig are perfectly natural and healthy. Pregnant women and /etc/sysconfig both have perfectly valid use cases and do not need to be fixed :) Yes, but pregnancy is of finite duration. Thank $_DEITY. I think the point is that some sort of gentle sunset for /etc/sysconfig is desirable. I agree with that. Forced migration? Madness. -J -Mike-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: on /etc/sysconfig
On Mon, Jul 18, 2011 at 3:34 PM, Tom Lane t...@redhat.com wrote: Well, if they didn't need fixed before, they'll certainly need fixed when you make them start keeping their configuration info someplace else Yeah -- daemons that can be configured with commandline options or envvars are Just Fine. If those options can be tweak without getting into conflict with the rpm-maintained init script / service file, that is actually _a seriously good feature_. My sysadmin self wants to have a way to override any vars defined in the service file, preferrably in a directory similar to sysconfig. Lennert's review of what we have currently in /etc/sysconfig is correct -- a horrid mess. A cleanup is needed. But we can't do away with the ability to override the shipped configuration. For example - I often use those overrides to point a daemon to a different config file or dir, so as to make config changes without concern of what installed pkgs may do. This insulates the setup from configfiles that aren't marked as config, or new files dropped into a conf.d directory. I have used the same technique in cases where I'd run several instances of the same daemon in different ports or intefaces, and the init script was too scary to copy and edit (and maintain going forward). With service files being simpler, this use case goes away - cp the service file and editing it becomes a lot more doable. than /etc/sysconfig. This proposal sounds more like wait, systemd has not yet broken everything in sight, how can we solve that problem? Heh -- I do like systemd replacing init and streamlining some things. But there's a limit to everyone's comfort on the speed of change... folks could take the world domination track /a little bit slower/. There's also a lot to learn from completing one stage before taking the next 5 :-) m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Inline-Files] Perl mass rebuild
commit 4cf01501b7dc0622faff1a7c16df3ec42e0d5b2c
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:20:16 2011 +0200
Perl mass rebuild
perl-Inline-Files.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Inline-Files.spec b/perl-Inline-Files.spec
index 0196ed3..42e17b2 100644
--- a/perl-Inline-Files.spec
+++ b/perl-Inline-Files.spec
@@ -1,6 +1,6 @@
Name: perl-Inline-Files
Version:0.67
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Allows for multiple inline files in a single perl file
Group: Development/Libraries
License:GPL+ or Artistic
@@ -47,6 +47,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 0.67-2
+- Perl mass rebuild
+
* Mon Jul 11 2011 Petr Sabata con...@redhat.com - 0.67-1
- 0.67 bump
--
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-List-MoreUtils] Perl mass rebuild
commit fcef96e8f8750107f97c50085b2d8ea0b22df34a
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:20:18 2011 +0200
Perl mass rebuild
perl-List-MoreUtils.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-List-MoreUtils.spec b/perl-List-MoreUtils.spec
index b823562..9b11c0d 100644
--- a/perl-List-MoreUtils.spec
+++ b/perl-List-MoreUtils.spec
@@ -1,6 +1,6 @@
Name: perl-List-MoreUtils
Version:0.32
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Provide the stuff missing in List::Util
Group: Development/Libraries
@@ -47,6 +47,9 @@ make test
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 0.32-3
+- Perl mass rebuild
+
* Tue Jul 12 2011 Tom Callaway s...@fedoraproject.org 0.32-2
- rebuild to fix broken rawhide deps
--
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-Test-Inter] Perl mass rebuild
commit 2572ae068bf5075989671594b4f6872d38deeb33
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:20:35 2011 +0200
Perl mass rebuild
perl-Test-Inter.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Inter.spec b/perl-Test-Inter.spec
index 6cd9218..a00da8f 100644
--- a/perl-Test-Inter.spec
+++ b/perl-Test-Inter.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Inter
Version:1.03
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Framework for more readable interactive test scripts
License:GPL+ or Artistic
Group: Development/Libraries
@@ -42,6 +42,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 1.03-2
+- Perl mass rebuild
+
* Thu Jul 07 2011 Petr Pisar ppi...@redhat.com - 1.03-1
- 1.03 bump
--
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-Test-Refcount] Perl mass rebuild
commit de42297e9810f07ad9bf244c15d3a30266f6d757
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:25:57 2011 +0200
Perl mass rebuild
perl-Test-Refcount.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Refcount.spec b/perl-Test-Refcount.spec
index 41f3f73..fe94371 100644
--- a/perl-Test-Refcount.spec
+++ b/perl-Test-Refcount.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Refcount
Version:0.07
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Assert reference counts on objects
Group: Development/Libraries
@@ -53,6 +53,9 @@ make test
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 0.07-2
+- Perl mass rebuild
+
* Tue Jun 21 2011 Marcela Mašláňová mmasl...@redhat.com - 0.07-1
- update to 0.07
--
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-Pod-Eventual] Perl mass rebuild
commit 32807ff5efccf44304eae873220f41f1b1c5fe95
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:26:39 2011 +0200
Perl mass rebuild
perl-Pod-Eventual.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Pod-Eventual.spec b/perl-Pod-Eventual.spec
index c86c7dc..ddae291 100644
--- a/perl-Pod-Eventual.spec
+++ b/perl-Pod-Eventual.spec
@@ -1,6 +1,6 @@
Name: perl-Pod-Eventual
Version:0.093330
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Read a POD document as a series of trivial events
License:GPL+ or Artistic
Group: Development/Libraries
@@ -67,6 +67,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 0.093330-7
+- Perl mass rebuild
+
* Wed Jul 13 2011 Iain Arnell iarn...@gmail.com 0.093330-6
- drop circular Pod::Coverage::TrustPod buildreq
- don't run release tests
--
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-Time-modules] Perl mass rebuild
commit 8df02f0e8c4086cbb52e77e96a2613681f1d8b7c
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:30:39 2011 +0200
Perl mass rebuild
perl-Time-modules.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Time-modules.spec b/perl-Time-modules.spec
index 45c36ae..ec656bb 100644
--- a/perl-Time-modules.spec
+++ b/perl-Time-modules.spec
@@ -1,6 +1,6 @@
Name: perl-Time-modules
Version:2011.0517
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl modules for parsing dates and times
Group: Development/Libraries
License:Copyright only and Public Domain
@@ -41,6 +41,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 2011.0517-2
+- Perl mass rebuild
+
* Thu Jul 07 2011 Petr Pisar ppi...@redhat.com - 2011.0517-1
- 2011.0517 bump
- Clean up spec file
--
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] Perl mass rebuild
commit fcf3b98e166e51e1df3274f6673b1ac62fc91666
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:32:44 2011 +0200
Perl mass rebuild
perl-HTTP-Server-Simple.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTTP-Server-Simple.spec b/perl-HTTP-Server-Simple.spec
index bdf5660..aaa5922 100644
--- a/perl-HTTP-Server-Simple.spec
+++ b/perl-HTTP-Server-Simple.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Server-Simple
Version:0.44
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Very simple standalone HTTP daemon
Group: Development/Libraries
@@ -52,6 +52,9 @@ make test
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 0.44-2
+- Perl mass rebuild
+
* Tue Jul 5 2011 Tom Callaway s...@fedoraproject.org - 0.44-1
- update to 0.44
- add explicit Requires for perl(CGI), since it is not autodetected (bz719048)
--
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-Config-Properties] Perl mass rebuild
commit c598892c55daf03a780170b04c014b90a0500013
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:31:17 2011 +0200
Perl mass rebuild
perl-Config-Properties.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Config-Properties.spec b/perl-Config-Properties.spec
index 5089361..3524eba 100644
--- a/perl-Config-Properties.spec
+++ b/perl-Config-Properties.spec
@@ -1,6 +1,6 @@
Name: perl-Config-Properties
Version:1.72
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Read and write property files
License:GPL+ or Artistic
Group: Development/Libraries
@@ -58,6 +58,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 1.72-2
+- Perl mass rebuild
+
* Sat Jul 16 2011 Xavier Bachelot xav...@bachelot.org 1.72-1
- Update to 1.72.
--
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-SDL] Perl mass rebuild
commit 09530da674af3c1ed683878e40c0dc7c6356d2bf
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:36:52 2011 +0200
Perl mass rebuild
perl-SDL.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-SDL.spec b/perl-SDL.spec
index 3b3a226..fb5b50c 100644
--- a/perl-SDL.spec
+++ b/perl-SDL.spec
@@ -1,6 +1,6 @@
Name: perl-SDL
Version:2.2.6
-Release:3%{?dist}
+Release:4%{?dist}
Summary:SDL bindings for the Perl language
Group: Development/Libraries
License:LGPLv2+
@@ -54,6 +54,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 2.2.6-4
+- Perl mass rebuild
+
* Fri Jul 15 2011 Hans de Goede hdego...@redhat.com - 2.2.6-3
- Rebuild for new SDL_gfx
--
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-File-Remove] Perl mass rebuild
commit 3069f454861e5e106433773e4580d6e7eac4a502
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:37:05 2011 +0200
Perl mass rebuild
perl-File-Remove.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-Remove.spec b/perl-File-Remove.spec
index fd1c9e4..57999a7 100644
--- a/perl-File-Remove.spec
+++ b/perl-File-Remove.spec
@@ -1,6 +1,6 @@
Name: perl-File-Remove
Version: 1.50
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Convenience module for removing files and directories
License: GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 1.50-2
+- Perl mass rebuild
+
* Sun Jul 17 2011 Ralf Corsépius corse...@fedoraproject.org - 1.50-1
- Upstream update.
- Add File-Remove-1.50.diff/Remove File-Remove-1.49.diff.
--
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-HTML-Template] Perl mass rebuild
commit 34c721f78e58c9649fe43ba81920dfe92fe7d532
Author: Petr Sabata con...@redhat.com
Date: Mon Jul 18 13:38:42 2011 +0200
Perl mass rebuild
perl-HTML-Template.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-Template.spec b/perl-HTML-Template.spec
index 940da8e..84442c4 100644
--- a/perl-HTML-Template.spec
+++ b/perl-HTML-Template.spec
@@ -1,6 +1,6 @@
Name: perl-HTML-Template
Version:2.10
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl module to use HTML Templates
Group: Development/Libraries
@@ -57,6 +57,9 @@ TEST_SHARED_MEMORY=1 make test
%changelog
+* Mon Jul 18 2011 Petr Sabata con...@redhat.com - 2.10-2
+- Perl mass rebuild
+
* Thu Jul 14 2011 Tom Callaway s...@fedoraproject.org - 2.10-1
- update to 2.10
--
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 Fedora-Rebuild-v0.7.0.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Fedora-Rebuild: 892a7940f43286f279d076c59dae11d8 Fedora-Rebuild-v0.7.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
[perl-Fedora-Rebuild] 0.7.0 bump
commit e4526ff362f8041e93053afd3621a14263b4696e
Author: Petr Písař ppi...@redhat.com
Date: Mon Jul 18 16:36:54 2011 +0200
0.7.0 bump
.gitignore |1 +
perl-Fedora-Rebuild.spec |6 +-
sources |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index cafafd0..d7091bb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
/Fedora-Rebuild-v0.4.1.tar.gz
/Fedora-Rebuild-v0.5.0.tar.gz
/Fedora-Rebuild-v0.5.1.tar.gz
+/Fedora-Rebuild-v0.7.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index c1c4ec2..86cecca 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,6 +1,6 @@
# This file is lincensed under the terms of GPLv2+.
Name: perl-Fedora-Rebuild
-Version:0.5.1
+Version:0.7.0
Release:1%{?dist}
Summary:Rebuilds Fedora packages from scratch
License:GPLv3+
@@ -27,6 +27,7 @@ BuildRequires: perl(RPM2)
BuildRequires: perl(RPM::VersionCompare)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Storable)
+BuildRequires: perl(Term::ProgressBar)
BuildRequires: perl(Test::Simple)
BuildRequires: perl(Thread::Semaphore)
BuildRequires: perl(threads)
@@ -69,6 +70,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jul 18 2011 Petr Pisar ppi...@redhat.com - 0.7.0-1
+- 0.7.0 bump
+
* Fri Jul 15 2011 Petr Pisar ppi...@redhat.com - 0.5.1-1
- 0.5.1 version
diff --git a/sources b/sources
index 0c21098..cd971eb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-962f8094ddf8580910b5eadbc1c7db98 Fedora-Rebuild-v0.5.1.tar.gz
+892a7940f43286f279d076c59dae11d8 Fedora-Rebuild-v0.7.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
[perl-Fedora-Rebuild/f15] 0.7.0 bump
Summary of changes: e4526ff... 0.7.0 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
[perl-Fedora-Rebuild/f14] 0.7.0 bump
Summary of changes: e4526ff... 0.7.0 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 721337] perl-Fedora-Rebuild-0.5.0 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=721337 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2011-07-18 11:04:41 EDT --- perl-Fedora-Rebuild-0.7.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-Fedora-Rebuild-0.7.0-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 721337] perl-Fedora-Rebuild-0.5.0 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=721337 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-07-18 11:04:01 EDT --- perl-Fedora-Rebuild-0.7.0-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-Fedora-Rebuild-0.7.0-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 715240] perl-Fedora-Rebuild-0.3.0 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=715240 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-07-18 11:04:12 EDT --- perl-Fedora-Rebuild-0.7.0-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-Fedora-Rebuild-0.7.0-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 716407] perl-Fedora-Rebuild-0.4.1 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=716407 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-07-18 11:04:17 EDT --- perl-Fedora-Rebuild-0.7.0-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-Fedora-Rebuild-0.7.0-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 716407] perl-Fedora-Rebuild-0.4.1 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=716407 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2011-07-18 11:04:56 EDT --- perl-Fedora-Rebuild-0.7.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-Fedora-Rebuild-0.7.0-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 722604] please upgrade to HTML-Format-2.09
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=722604 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2011-07-18 18:29:58 EDT --- Package perl-HTML-Format-2.09-1.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-HTML-Format-2.09-1.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-HTML-Format-2.09-1.fc14 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
[rt3/el6] BR: perl(Digest::SHA)
commit fa045894e2470cbb279a89ca877287d433c16c1d
Author: Xavier Bachelot xav...@bachelot.org
Date: Tue May 3 01:21:17 2011 +0200
BR: perl(Digest::SHA)
rt3.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/rt3.spec b/rt3.spec
index 2714374..00bfeb8 100644
--- a/rt3.spec
+++ b/rt3.spec
@@ -40,7 +40,7 @@
Name: rt3
Version: 3.8.10
-Release: 2%{?dist}
+Release: 2%{?dist}.1
Summary: Request tracker 3
Group: Applications/Internet
@@ -77,6 +77,7 @@ BuildRequires: perl(DBIx::SearchBuilder) = 1.54
BuildRequires: perl(Devel::StackTrace) = 1.19
BuildRequires: perl(Digest::base)
BuildRequires: perl(Digest::MD5) = 2.27
+BuildRequires: perl(Digest::SHA)
BuildRequires: perl(Email::Address)
BuildRequires: perl(Encode) = 2.13
BuildRequires: perl(Errno)
@@ -447,6 +448,9 @@ fi
%endif
%changelog
+* Tue May 03 2011 Xavier Bachelot xav...@bachelot.org - 3.8.10-2.1
+- Add BR: perl(Digest::SHA).
+
* Sat Apr 16 2011 Ralf Corsépius corse...@fedoraproject.org - 3.8.10-2
- Work-around rpm's depgenerator defect:
Filter Requires: perl(DBIx::SearchBuilder::Handle::).
--
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-Object-InsideOut] fix filtering; clean up requires
commit 3b0b77697fc2245288f03470871af2fa9f80d540
Author: Iain Arnell iarn...@gmail.com
Date: Tue Jul 19 06:28:10 2011 +0200
fix filtering; clean up requires
perl-Object-InsideOut.spec | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
---
diff --git a/perl-Object-InsideOut.spec b/perl-Object-InsideOut.spec
index be4ed95..31b073f 100644
--- a/perl-Object-InsideOut.spec
+++ b/perl-Object-InsideOut.spec
@@ -1,6 +1,6 @@
Name: perl-Object-InsideOut
Version:3.81
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Comprehensive inside-out object support module
Group: Development/Libraries
@@ -13,7 +13,7 @@ BuildRequires: perl(Exception::Class) = 1.29
BuildRequires: perl(Want) = 0.12
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
-%if !%{defined perl_bootstrap}
+%if !0%{?perl_bootstrap}
BuildRequires: perl(Math::Random::MT::Auto)
%endif
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -27,11 +27,13 @@ BuildRequires: perl(Test::More) = 0.5
BuildRequires: perl(B)
### auto-added reqs!
-Requires: perl(B)
-Requires: perl(Config)
Requires: perl(Data::Dumper)
-Requires: perl(Exception::Class) = 1.29
-Requires: perl(Scalar::Util) = 1.23
+
+%{?perl_default_filter}
+%global __provides_exclude
%{?__provides_exclude:%__provides_exclude|}perl\\(Object::InsideOut\\)$
+%if 0%{?perl_bootstrap}
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}perl\\(Math::Random::MT::Auto\\)
+%endif
%description
This module provides comprehensive support for implementing classes using the
@@ -44,10 +46,6 @@ set as readonly to prevent accidental modifications to the
ID. Object data
(i.e., fields) are stored within the class's package in either arrays indexed
by the object's ID, or hashes keyed to the object's ID.
-%{?perl_default_filter}
-%global __provides_exclude %{?__provides_exclude}|perl\\(Object::InsideOut\\)
-%global __requires_exclude
%{?__requires_exclude}|perl\\(t::Imp|perl\\(Math::Random::MT::Auto\\)
-
%prep
%setup -q -n Object-InsideOut-%{version}
@@ -75,6 +73,11 @@ make test
%changelog
+* Tue Jul 19 2011 Iain Arnell iarn...@gmail.com 3.81-2
+- fix provides filter
+- on filter requires when bootstrapping
+- remove unnecessary explicit requires
+
* Sat Jul 02 2011 Iain Arnell iarn...@gmail.com 3.81-1
- minimize the impact of perl_bootstrap on testing; it's only
perl-Math-Random-MT-Auto which causes circular deps and is
--
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
