Re: Revelation password manager issue
On Sun, Jun 24, 2012 at 09:59:55PM -0800, Jef Spaleta wrote:
On Sun, Jun 24, 2012 at 9:50 PM, Pierre-Yves Chibon pin...@pingoured.fr
wrote:
I had a number of problem with guake and its gconf schema, so after
discussion here I added this to the spec file:
%posttrans
killall -HUP gconfd-2 /dev/null || :
That pretty much forces gconf to reload.
Uhm has this been vetted as not a bad thing {tm} by the packaging
thinktank?
The killall was in (very? it's all relative :-) old versions of the
packaging guidelines. At some point it was tested to be unnecessary
anymore. If the scriptlets don't work without it, it's probably a bug in
the GConf2 package. Using the killall in scriptlets would be an okay
workaround (but might have some rpm-update-performance ramifications).
-Toshio
pgpIwSyROddSa.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service restart question
On Mon, 25.06.12 15:40, Tom Lane (t...@redhat.com) wrote: (1) systemd is not able to distinguish a crash that should be restarted from, say, failure due to misconfiguration in /etc/my.cnf. (It's not clear whether restart settings other than always would help here, but in general it seems obvious that there are likely to be service- specific reasons for restarting after some failures and not others.) Hmm, it can actually do that. For example if you set Restart=on-abort we'll restart mysql only if it crashes abnormally, via a signal -- but it wouldn't be if mysql exits with exit(x) regardless what that x is. Also, if you use Restart=always and a service terminates during its initialization phase then we don't try restarts either (well, at least in theory, there might be a bug in this, too). We'd only restart it if it terminates during the normal runtime. Anyway, I will spend some time today to make sure this all works properly, as intended. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Grouping service units for bulk stop/start ?
On Mon, 25.06.12 15:27, Daniel P. Berrange (berra...@redhat.com) wrote: With OpenStack there are quite a large number of daemons per host, each of which has their own .service unit file. openstack-glance-api.service openstack-glance-registry.service openstack-keystone.service openstack-nova-api.service openstack-nova-cert.service openstack-nova-compute.service openstack-nova-network.service openstack-nova-objectstore.service openstack-nova-scheduler.service openstack-nova-volume.service openstack-swift-account.service openstack-swift-container.service openstack-swift-object.service openstack-swift-proxy.service Currently our OpenStack instructions have such fun commands as: # for svc in api registry; do sudo systemctl start openstack-glance-$svc.service; done # for svc in api objectstore compute network volume scheduler cert; do sudo systemctl start openstack-nova-$svc.service; done What I'd like to be able todo is setup some kind of grouping, so that you can just start/stop/check status of everything in simple commands like: # sudo systemctl start openstack-nova.target # sudo systemctl status openstack-nova.target # sudo systemctl stop openstack-nova.target My naive attempt to make this work was todo - Create a openstack-nova.target containining [Unit] Description=OpenStack Nova WantedBy=multi-user.target Wantedby is not supported in [Unit], it belongs in [Install] - Edit each of openstack-nova-XXX.service to change WantedBy=multi-user.target to WantedBy=openstack-nova.target I'd recommend simply dropping symlinks into /usr/lib/systemd/system/openstack-nova.target.wants/ for the services that shall be components of your target. But after doing this, stopping/starting the target has no effect on the running state of units I associated with it. Also I'd like starting/stopping XXX.target to take account of the enablement state of the individual XXX-YYY.service files. eg so I can disable say, openstack-nova-network.service on a host, but still use openstack-nova.target to bulk stop/start all the other services that are enabled. You'd need a BindTo=openstack-nova.target in all your service units to make sure that if the target goes away the services do to. Either I'm missing some config change, or what I'm attempting is just not the kind of functionality that .target files are intended to offer ? So far they have't actually. They tend to have slightly different semantics that what you are looking for here. Anyway, to summarize what I am suggesting: Create your target openstack-nova.target like this: [Unit] Description=OpenStack Nova Stick that in /usr/lib/systemd/system/openstack-nova.target. Then, add symlinks from /usr/lib/systemd/system/openstack-nova.target.wants/ to your individual services. This bit will make sure that when the target is activated the service units are pulled in too. And then, to make sure that if the target goes away your services do to, you need to add BindTo=openstack-nova.target lines to the [Unit] sections of all your services. With this all in place starting the target will start the services, and stopping the target will stop the services. However, this isn't perfect yet, because if an individual service is started the target is also pulled in and hence all other services, too. And that is most likely not what you want. This is a new usecase, but a valid one. We'll add a new dependency type to work this nicely, so that if the target is started all services go up, if the target goes down all services go down, but if individual services are started/stopped they don't influence the target nor any other services. In the meantime, please use what I suggested above, it comes pretty close to the desired behaviour I guess, and very similar to what we'll add for you. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 06/26/2012 03:56 AM, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: On Mon, Jun 25, 2012 at 08:47:16PM -0500, Chris Adams wrote: Trying to do this in profile scripts assumes that you only run local terminals that come from Fedora and that have been tested. For example, if you SSH to a Fedora box from an old xterm that doesn't do 256 colors, what happens if profile automagically turns xterm into xterm-256color? The proposal actually handles that by parsing the output of the who command, but I'm not sure I'm morally in favour of that. That wasn't there when I checked before my email, so I didn't know that. It sounds like adding one hack on top of another; trying to parse the output of a command not documented to have a fixed specific format is an even worse idea IMHO. Fair enough. The main caveat with per terminal settings is that it might be desired to provide config options per terminal. Though I suppose users can always override TERM in their startup files in the unlikely case they need to change back to 'xterm' for example. Note the feature is not completed at all. The presented /etc/profile.d/256colors.sh was only a 2 minute hack that I thought was worth presenting as it allows one to easily check the feature and it does actually work in the vast majority of cases. I'm also always looking to avoid having more programs automatically run at the start of a login. If you've ever had to deal with logging into an overloaded system, the last thing you want is a profile script doing who and grep just to try to override the TERM variable to make it prettier. I'd like to see less of that, not more. Agreed. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
2012/6/26 Chris Adams cmad...@hiwaay.net: The newer terminal programs have configuration menus for various things; do any of them set it there? If they don't, I would think it would be relatively easy to add (and hopefully upstreams would accept such patches). Tried with XFCE's Terminal, which has a $TERM option in its configuration dialog (under advanced options), but it simply doesn't work. I set it to xterm-256color, but within the shell, TERM is still xterm. Not sure whether that is an XFCE (or vte) bug, or whether some system-wide profile script overrides it. Afaict, none of my user profile scripts overrides it. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pylibacl-0.4 - a license change from GPLv2+ to LGPLv2+
Hi, Starting from the version 0.4 pylibacl Python extension changed its license from GPLv2+ to LGPLv2+. As the new license is less restrictive I don't see any negative implications. Regards Marcin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 06/26/2012 02:37 PM, Thomas Moschny wrote: 2012/6/26 Chris Adams cmad...@hiwaay.net: The newer terminal programs have configuration menus for various things; do any of them set it there? If they don't, I would think it would be relatively easy to add (and hopefully upstreams would accept such patches). Tried with XFCE's Terminal, which has a $TERM option in its configuration dialog (under advanced options), but it simply doesn't work. I set it to xterm-256color, but within the shell, TERM is still xterm. Not sure whether that is an XFCE (or vte) bug, or whether some system-wide profile script overrides it. Afaict, none of my user profile scripts overrides it. See bottom comment here: https://bugs.archlinux.org/task/21007#comment94595 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 06/26/2012 08:50 AM, Chris Adams wrote: Once upon a time, Pádraig Brady p...@draigbrady.com said: The main caveat with per terminal settings is that it might be desired to provide config options per terminal. Though I suppose users can always override TERM in their startup files in the unlikely case they need to change back to 'xterm' for example. I still use plain old xterm (the terminal program), and it allows you to override the TERM variable in a couple of ways. There's a command-line option, and there's the old X resource termName. The newer terminal programs have configuration menus for various things; do any of them set it there? If they don't, I would think it would be relatively easy to add (and hopefully upstreams would accept such patches). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 06/26/2012 06:54 AM, Pádraig Brady wrote: . The main caveat with per terminal settings is that it might be desired to provide config options per terminal. Though I suppose users can always override TERM in their startup files in the unlikely case they need to change back to 'xterm' for example. Unlikely Pffft!!What else do you resort to every time gnome-terminal won't start because dbus has crashed? John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On Tue, Jun 26, 2012 at 10:20:56AM -0400, John Ellson wrote: On 06/26/2012 06:54 AM, Pádraig Brady wrote: . The main caveat with per terminal settings is that it might be desired to provide config options per terminal. Though I suppose users can always override TERM in their startup files in the unlikely case they need to change back to 'xterm' for example. Unlikely Pffft!!What else do you resort to every time gnome-terminal won't start because dbus has crashed? Unclear what that has to do with the contents of your TERM variable. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
KDE-SIG meeting report (26/2012)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. = Weekly KDE Summary = Week: 26/2012 Time: 2012-06-26 15:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-06-16 Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-26/kde-sig.2012-06-26-15.02.html Log: http://meetbot.fedoraproject.org/fedora-meeting/2012-06-26/kde-sig.2012-06-26-15.02.log.html = Participants = * rdieter * rnovacek * Kevin_Kofler * than * ltinkl = Agenda = * topics to discuss: ** kde-4.8.4 ** akonadi-mysql proposal, see *** [http://lists.fedoraproject.org/pipermail/kde/2012-June/011626.html http://lists.fedoraproject.org/pipermail/kde/2012-June/011626.html] *** [http://lists.fedoraproject.org/pipermail/kde/2012-June/011627.html http://lists.fedoraproject.org/pipermail/kde/2012-June/011627.html] = Summary = * kde-4.8.4 status update ** HELP: test/karma kde-4.8.4 updates ** 4.9 RC going to be tagged soon (yay) * akonadi-mysql proposal ** AGREED: akonadi-mysql proposal accepted (+4/-1) = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-07-03 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On Tue, 2012-06-26 at 10:20 -0400, John Ellson wrote: On 06/26/2012 06:54 AM, Pádraig Brady wrote: The main caveat with per terminal settings is that it might be desired to provide config options per terminal. Though I suppose users can always override TERM in their startup files in the unlikely case they need to change back to 'xterm' for example. Unlikely Pffft!!What else do you resort to every time gnome-terminal won't start because dbus has crashed? One never hits that scenario, because: a) gnome-terminal runs just fine without dbus (unset DBUS_SESSION_BUS_ADDRESS and run with --disable-factory to verify) b) when dbus crashes, so does gnome-session, so there's really no question of launching another terminal - ajax 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: Couldn't we enable 256 colors by default on TERM?
On Tue, Jun 26, 2012 at 3:24 AM, Matthew Garrett mj...@srcf.ucam.org wrote: We discussed this in fesco today and had a couple of concerns. Another one is that connecting to systems that don't support xterm-256 is not quite easy. In particular, there appears to be no way to configure ~/.ssh/config so that ssh oldhost (and ssh oldhost arbitrarycommand) transparently changes the TERM value - one would have to set up shell functions or something similar. An extension of the ssh would be very nice - and failing that, an explicit recipe how to override TERM correctly would be welcome as well. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
Miloslav Trmač wrote: Another one is that connecting to systems that don't support xterm-256 is not quite easy. In particular, there appears to be no way to configure ~/.ssh/config so that ssh oldhost (and ssh oldhost arbitrarycommand) transparently changes the TERM value - one would have to set up shell functions or something similar. An extension of the ssh would be very nice - and failing that, an explicit recipe how to override TERM correctly would be welcome as well. And I strongly suspect that a correct solution would have to translate xterm-256color to xterm, screen-256color to screen et cetera. Simply setting TERM=xterm in all SSH sessions is probably not sufficient. Björn Persson 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: Couldn't we enable 256 colors by default on TERM?
Once upon a time, Miloslav Trmač m...@volny.cz said: Another one is that connecting to systems that don't support xterm-256 is not quite easy. In particular, there appears to be no way to configure ~/.ssh/config so that ssh oldhost (and ssh oldhost arbitrarycommand) transparently changes the TERM value - one would have to set up shell functions or something similar. An extension of the ssh would be very nice - and failing that, an explicit recipe how to override TERM correctly would be welcome as well. The OpenSSH devs might be open to such. I'd be willing to take it up with them and write a patch (if they'll accept it). Any suggestions on how it should work? Ideally, some way to say drop the -256color suffix from TERM if preset would be best. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On Sat, Jun 23, 2012 at 01:15:14AM +0200, Kevin Kofler wrote: Michael Cronenworth wrote: Kevin Kofler wrote: How would you suggest we implement this? rm -rf the stuff in %post? (Yuck!!!) As I understand it, the symbols will be bloating the main packages and not be in subpackages. (Debuginfo subpackages are what we have now.) It would be nice if the minidebuginfo data was stored similar to debuginfo data. That way spins could easily rm -rf the minidebuginfo folder to keep images smaller. You apparently didn't get it: running rm -rf on files owned by a package on the spin is NOT a serious option! Among other things, it will break DeltaRPMs and rpm -Va, it does not persist on package updates and thus creates inconsistencies when (inevitably) some packages are updated and others are not, and it's just wrong. A pie in the sky option might be to have minidebuginfo/debuginfo reside in the same package as the binaries it belongs to but in separate files which are marked in the rpm filelist. Then rpm could have a --nodebuginfo similar to how it has --nodoc now. Not sure if that's either (1) something the rpm team would go for or (2) something that could be available in a time frame that the minidebuginfo authors would find acceptable. -Toshio pgpBEUsswYAeI.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
incompatible upgrade of apache traffic server
I would like to upgrade Apache Traffic Server (ATS) from v3.0.x to new stable branch v3.2.x. The 3.2 branch has lots of improvements for IPv6 and SSL that are important to me, and also fixes a crash I've been hitting in v3.0. But, unfortunately there are a couple of incompatible config file changes, ref: https://cwiki.apache.org/confluence/display/TS/Upgrading+to+3.2 Only the SSL certificate configuration and HTTP Quick filtering configuration needs to be handled by the user (if they are used). The hostdb and stats-changes can be handled automatically during upgrade. So, IMHO the incompatibilities are very small, and I believe the userbase is also quite small. Hopefully I should be able to reach most users trough the trafficserver-devel and users mailinglist. Looking trough the exceptions lists on http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases: Things that would make it more likely to grant a request: * The package is a leaf node. Nothing depends on it or requires it. [Applies] * The update fixes a security issue that would affect a large number of users. [No] * The update doesn't change ABI/API and nothing needs to be rebuilt against the new version [Applies] * The update fixes serious bugs that many fedora users are encountering [Applies, fixes segfault] Things that would make it less likely to grant a request: * The update converts databases or resources one way to a new format. [internal cache files only] * The update requires admin intervention for the service to keep working (config file format changes, etc). [Maybe -- if the two relevant features are in use] * The update causes behavior changes (something that was denied is allowed, etc) [No] * The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line) [No] * The update fixes bugs that no fedora user has reported nor would affect many fedora users (ie, fixes for other platforms or configurations). [No, I've personally hit crashes on EPEL and expect the same crash should happen on Fedora] Will it be OK to do this upgrade in F15/F16/F17, or are we stuck on v3.0 ? Highlights of this release includes: * Over 800 commits, and 300 Jira tickets closed since v3.0. * Several SSL improvements, including SNI (Server Name Indication) and NPN (Next Protocol Negotiation). Overall SSL stability is also improved. * Full IPv6 support, v3.0 only had client side IPv6. All IP related plugin APIs are now also IPv6 aware. * New, flexible configurations for managing inbound and outgoing IP addresses and ports. You can now bind any number, and combinations, of addresses and ports for both HTTP and HTTPS. * Range request for large objects in cache are now much (much) faster. * Several new, and improved, plugin APIs are now available. * Performance and stability improvements in the Cluster Cache feature. * Much better performance when proxying to a Keep-Alive HTTP backend server connection. Overall cache performance is also significantly better. * Several stable plugins are now included with the core distributions. * Supports all gcc versions 4.1.2 and higher, Clang / LLVM 3, and the Intel compiler suite. Builds and runs on Linux, FreeBSD, Solaris and OSX. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/26/2012 02:50 PM, Toshio Kuratomi wrote: A pie in the sky option might be to have minidebuginfo/debuginfo reside in the same package as the binaries it belongs to but in separate files which are marked in the rpm filelist. Then rpm could have a --nodebuginfo similar to how it has --nodoc now. Not sure if that's either (1) something the rpm team would go for or (2) something that could be available in a time frame that the minidebuginfo authors would find acceptable. Please, please no. --nodoc is a travesty. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Support for legacy init script actions for systemd services
THE PROBLEM
We have assorted init scripts that have historically defined custom actions.
Given that this is an unbounded set, it is impossible to handle them
natively in systemd. However, they're usually part of administrators muscle
memory.
Better late than never (and thanks to Michal Schmidt), I've added support to
/sbin/service for running legacy actions if specified.
HOW TO IMPLEMENT IN YOUR PACKAGE
For each legacy option (such as xyzzy) supported by your init script (such
as frobozz), package an executable script named:
/usr/libexec/initscripts/legacy-actions/frobozz/xyzzy
If this file exists and is executable, then when an administrator runs:
/sbin/service frobozz xyzzy
this file will be executed, to do whatever. This file can be a symlink
somewhere else, or even a compiled executable if you really desire.
BEST PRACTICES
1) A legacy action of this sort should print to stderr the preferred way to
accomplish the task, if one is supported.
2) Don't package a legacy action for new scripts or actions that were not
supported by the prior init script; this is intended for compatibility with
existing scripts and/or administrator brains.
3) Don't package
/usr/libexec/initscripts/legacy-actions/frobozz/{start,stop,restart...},
or we will hurt you. (And /sbin/service will likely be changed to ignore
these actions if this becomes a problem.)
WHEN THIS WILL LAND
It's in initscripts git now, will package shortly for F18/F17/F16.
Questions? Comments?
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
Toshio Kuratomi wrote: A pie in the sky option might be to have minidebuginfo/debuginfo reside in the same package as the binaries it belongs to but in separate files which are marked in the rpm filelist. Then rpm could have a --nodebuginfo similar to how it has --nodoc now. Not sure if that's either (1) something the rpm team would go for or (2) something that could be available in a time frame that the minidebuginfo authors would find acceptable. 1. it'd have to be available at the kickstart level too to be useful for us and 2. I don't think it's that great a solution, either. (It'd still cause trouble for DeltaRPMs, plus it's not that great to have RPM just not install some files, we stopped using that RPM feature for translations long ago because of the problems it caused, I don't think going back to doing things that way would be a great idea.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On Tue, Jun 26, 2012 at 16:11:19 -0400, Bill Nottingham nott...@redhat.com wrote: Questions? Comments? Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-06-25)
On Mon, Jun 25, 2012 at 8:01 PM, Miloslav Trmač m...@volny.cz wrote: (prepared manually, MeetBot-generated version to hopefully follow later) http://meetbot.fedoraproject.org/fedora-meeting/2012-06-25/fesco.2012-06-25-17.00.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On Tue, Jun 26, 2012 at 04:11:19PM -0400, Bill Nottingham wrote: BEST PRACTICES 1) A legacy action of this sort should print to stderr the preferred way to accomplish the task, if one is supported. 2) Don't package a legacy action for new scripts or actions that were not supported by the prior init script; this is intended for compatibility with existing scripts and/or administrator brains. It would be nice to have a good plan about how to implement the preferred new way to accomplish such tasks to avoid that every package does this differently. Regards Till pgpc0j74AAVh9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On Tue, Jun 26, 2012 at 10:45 PM, Till Maas opensou...@till.name wrote: 2) Don't package a legacy action for new scripts or actions that were not supported by the prior init script; this is intended for compatibility with existing scripts and/or administrator brains. It would be nice to have a good plan about how to implement the preferred new way to accomplish such tasks to avoid that every package does this differently. The preferred new way is that upstream implements the action in a way that is same across all distributions. Which, in some sense, does not answer your question. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On 06/26/2012 07:35 PM, Chris Adams wrote: Once upon a time, Miloslav Trmač m...@volny.cz said: Another one is that connecting to systems that don't support xterm-256 is not quite easy. In particular, there appears to be no way to configure ~/.ssh/config so that ssh oldhost (and ssh oldhost arbitrarycommand) transparently changes the TERM value - one would have to set up shell functions or something similar. An extension of the ssh would be very nice - and failing that, an explicit recipe how to override TERM correctly would be welcome as well. The OpenSSH devs might be open to such. I'd be willing to take it up with them and write a patch (if they'll accept it). Any suggestions on how it should work? Ideally, some way to say drop the -256color suffix from TERM if preset would be best. Well this is a general issue. For example with urxvt we have: $ echo $TERM $COLORTERM rxvt-unicode rxvt-xpm So sshing from urxvt already needs resetting of $TERM on various systems. I guess this issue might be some of the reason for the reluctance to address: https://bugzilla.redhat.com/show_bug.cgi?id=230682 The usual way to set/adjust TERM appropriate for the remote system is just to use the startup files there. This is what I add to ~/.profile on a solaris system for example: [ $SSH_CONNECTION ] export TERM=xterm I'm not sure adding such functionality to .ssh/config would be of much benefit TBH. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On 06/26/2012 08:11 PM, Bill Nottingham wrote: Questions? Comments? You do realize what you have effectively just done by this dont you? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
Bill Nottingham nott...@redhat.com writes: Better late than never (and thanks to Michal Schmidt), I've added support to /sbin/service for running legacy actions if specified. I'm confused. Only 2 months ago I was told that this was firmly against policy and I should get rid of code that assumed it worked (which, btw, it already did): http://lists.fedoraproject.org/pipermail/packaging/2012-April/008314.html Did that packaging guideline get reverted already? For each legacy option (such as xyzzy) supported by your init script (such as frobozz), package an executable script named: /usr/libexec/initscripts/legacy-actions/frobozz/xyzzy What do we need to Require: for this? Is there still a requirement to hide it in a foo-sysvinit subpackage? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On 06/26/2012 08:49 PM, Miloslav Trmač wrote: The preferred new way is that upstream implements the action in a way that is same across all distributions. Which, in some sense, does not answer your question. First and foremost how big of a problem do you guys believe this? Secondly cant we add the rule that packager are required to request permission from fesco to follow what is suggested before they implement it so it can be ensured that it's actually required/necessary for them to do this and at the same time a list gets created and populated with the relevant packages? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com writes: On 06/26/2012 08:49 PM, Miloslav TrmaÄ wrote: The preferred new way is that upstream implements the action in a way that is same across all distributions. Which, in some sense, does not answer your question. First and foremost how big of a problem do you guys believe this? Secondly cant we add the rule that packager are required to request permission from fesco to follow what is suggested before they implement it so it can be ensured that it's actually required/necessary for them to do this and at the same time a list gets created and populated with the relevant packages? The idea seems to be that you'd only implement actions that exist in non-systemd initscripts. As long as people adhere to that, I don't see that we need controls or per-package permissions. And I don't really see why people wouldn't. There are two possibilities here: a given action is commonly performed via service special-verb on non-systemd platforms, or it's done some other way. If it's done some other way elsewhere there is no very good reason not to do it the same way in systemd-land. On the other hand, if people are used to service special-verb, the only likely result of taking that away is that they will think systemd sucks and try to avoid platforms that use it. Personally, having gotten beat up repeatedly over the disappearance of service postgresql initdb in systemd-land, I think this is a great idea. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
Once upon a time, Pádraig Brady p...@draigbrady.com said: The usual way to set/adjust TERM appropriate for the remote system is just to use the startup files there. This is what I add to ~/.profile on a solaris system for example: Well, that works when the other end is a system that has a shell and runs login scripts. I also SSH to routers, switches, firewalls, etc., and I need a recognized TERM there as well. At least some of the routers I use recognize xterm-256color, but they don't recognize screen-256color (although I don't know if this proposal adresses screen, it would be good to have a general solution). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On Tue, Jun 26, 2012 at 11:48 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 06/26/2012 08:49 PM, Miloslav Trmač wrote: The preferred new way is that upstream implements the action in a way that is same across all distributions. Which, in some sense, does not answer your question. First and foremost how big of a problem do you guys believe this? What is this? Breaking service foo action reason was just an unnecessary regression that shouldn't have happened in the first place. But given the history and the length of time that has passed, I'd say that whether to restore this functionality now is up to individual package maintainers. Asking upstreams to adopt things that used to be done in distributions (and therefore were consistent within a distribution) without suggesting a good convention to follow (suggesting a high probability that they will not be consistent, and distributions will not be allowed to make them consistent) sounds like a change for the worse from the original state (it is, after all, one of the primary roles of a distribution to collect various differing upstreams and make a consistent OS from them) - but, well, the result will not be different from any other inter-project inconsistencies, so I don't view this as a problem. To the extent that systemd initiated this change, perhaps the convention should be suggested somewhere within the systemd project, ideally with input from distributions? Secondly cant we add the rule that packager are required to request permission from fesco to follow what is suggested before they implement it so it can be ensured that it's actually required/necessary for them to do this Is there any reason to forbid any implementation that follows the best practices above? And a reason to require special dispensation instead of relying on the regular review process? and at the same time a list gets created and populated with the relevant packages? What would be the purpose of such a list? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On Wed, Jun 27, 2012 at 12:04 AM, Tom Lane t...@redhat.com wrote: The idea seems to be that you'd only implement actions that exist in non-systemd initscripts. As long as people adhere to that, I don't see that we need controls or per-package permissions. And I don't really see why people wouldn't. Well, there is the case of upstream refusing to care about distribution specifics (or caring only about some obscure distribution), making the it impossible to move the script upstream. It's not very likely that all distributions would agree on a single script before starting to package that software - every distribution would tend to use its own mechanism. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
TL == Tom Lane t...@redhat.com writes: TL Did that packaging guideline get reverted already? No, it didn't, but of course you know the packaging committee cannot prevent an upstream from implementing whatever functionality they like. We can of course revisit the prohibition if someone cares to file a ticket. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On Tue, Jun 26, 2012 at 05:50:57PM -0400, Tom Lane wrote: Bill Nottingham nott...@redhat.com writes: Better late than never (and thanks to Michal Schmidt), I've added support to /sbin/service for running legacy actions if specified. I'm confused. Only 2 months ago I was told that this was firmly against policy and I should get rid of code that assumed it worked (which, btw, it already did): http://lists.fedoraproject.org/pipermail/packaging/2012-April/008314.html Did that packaging guideline get reverted already? For each legacy option (such as xyzzy) supported by your init script (such as frobozz), package an executable script named: /usr/libexec/initscripts/legacy-actions/frobozz/xyzzy What do we need to Require: for this? Is there still a requirement to hide it in a foo-sysvinit subpackage? If I'm reading this right, Bill's approach does not use a sysvinit script. Instead, /usr/sbin/service has been patched to look for any nonstandard commands in subdirectories of /usr/libexec/initscripts/legacy-actions/ The FPC hasn't been asked about this yet but I don't think it violates the our objections to having legacy commands in init scripts as there is no init script present. It's clear that systemd commands are being handled by systemd and these legacy commands are only available via the /usr/sbin/service command. I don't think we'd have an objection to using this method if it works as I described it and someone asked us to officially bless its usage. -Toshio pgpUBnlylj4Rz.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On 06/26/2012 10:12 PM, Miloslav Trmač wrote: What is this? Sorry meant to say this is There are maybe a handful of services that need this hence the precaution clause so packagers/maintainers simply don't choose to do exactly what Bill was referring to in 3) Breaking service foo action reason was just an unnecessary regression that shouldn't have happened in the first place. But given the history and the length of time that has passed, I'd say that whether to restore this functionality now is up to individual package maintainers. Agreed and honestly this sudden turnaround now smells a bit like RHEL 7 was a big contributing factor to that decision since this has been a know problem from the start.. Asking upstreams to adopt things that used to be done in distributions (and therefore were consistent within a distribution) without suggesting a good convention to follow (suggesting a high probability that they will not be consistent, and distributions will not be allowed to make them consistent) sounds like a change for the worse from the original state (it is, after all, one of the primary roles of a distribution to collect various differing upstreams and make a consistent OS from them) - but, well, the result will not be different from any other inter-project inconsistencies, so I don't view this as a problem. To the extent that systemd initiated this change, perhaps the convention should be suggested somewhere within the systemd project, ideally with input from distributions? I would rather argue that various upstreams should reach agreement on how things should properly be done and moved forward and distribution downstream to the relevant upstream should adopt that rather then the other way around since the likely hood of that input you refer they should do will actually never make it out of the distribution due to distribution politics . The /etc/sysconfig/foo and /etc/default/bar file problem which is explained in a bit more detail here [1] is perfect example on how distributions will never manage to agree amongst themselves to propose or provide input *together* because more often then not each distribution has a tendency to think that their way is the *right* way. I should mentioned in relevance to the above example that I have yet to find an upstream maintainer that disagrees with the elimination of that difference between distributions and that elimination will never come to be until we stop exercise that administrators muscle memory Bill was referring to. I'm pretty sure that this administrators muscle memory which has been referred to no longer exist amongst the administrators in the Fedora project since we have had the initial release that systemd got accepted in gone EOL and just for the Lennart haters that exist out there I should mention that *every* bug got addressed and fixed by the systemd team during F15 lifecycle. Secondly cant we add the rule that packager are required to request permission from fesco to follow what is suggested before they implement it so it can be ensured that it's actually required/necessary for them to do this Is there any reason to forbid any implementation that follows the best practices above? And a reason to require special dispensation instead of relying on the regular review process? My concern are exactly the same as Bill mentions in item three on his list. and at the same time a list gets created and populated with the relevant packages? What would be the purpose of such a list? Informative JBG 1. http://0pointer.de/blog/projects/on-etc-sysinit.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com writes: On 06/26/2012 10:12 PM, Miloslav TrmaÄ wrote: Breaking service foo action reason was just an unnecessary regression that shouldn't have happened in the first place. Agreed and honestly this sudden turnaround now smells a bit like RHEL 7 was a big contributing factor to that decision since this has been a know problem from the start.. I think you're right, and the reason why that's an issue is that people who were previously on RHEL6 are being exposed to systemd for the first time. And they don't like it. Asking upstreams to adopt things that used to be done in distributions (and therefore were consistent within a distribution) without suggesting a good convention to follow (suggesting a high probability that they will not be consistent, and distributions will not be allowed to make them consistent) sounds like a change for the worse from the original state (it is, after all, one of the primary roles of a distribution to collect various differing upstreams and make a consistent OS from them) - but, well, the result will not be different from any other inter-project inconsistencies, so I don't view this as a problem. I would rather argue that various upstreams should reach agreement on how things should properly be done and moved forward I don't presume to speak for all upstreams, but I can tell you that postgresql in particular is not likely to want to get involved here. They have other things to worry about, and have always thought that things like initscripts are mainly a packager's province anyway. But the big picture from our point of view is that service postgresql initdb has been the way to initialize a postgresql database for quite a few years, on many platforms besides Red-Hat-based ones. *We* are the ones who are out of step, and only somebody blinded by the Systemd Is The One True Way faith would fail to recognize that. I'm pretty sure that this administrators muscle memory which has been referred to no longer exist amongst the administrators in the Fedora project I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll be implementing this for postgresql tomorrow, because I'm tired of hearing complaints about it. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On 06/26/2012 11:54 PM, Tom Lane wrote: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= johan...@gmail.com writes: On 06/26/2012 10:12 PM, Miloslav Trma� wrote: Breaking service foo action reason was just an unnecessary regression that shouldn't have happened in the first place. Agreed and honestly this sudden turnaround now smells a bit like RHEL 7 was a big contributing factor to that decision since this has been a know problem from the start.. I think you're right, and the reason why that's an issue is that people who were previously on RHEL6 are being exposed to systemd for the first time. And they don't like it. What's more alarming to me is that this is being handled in Fedora but not in RHEL where it should be from my pov since in the RHEL Users != Fedora Users RHEL could just continue to use sysv/upstart for all If they wanted to if it's so important to their customer base... Asking upstreams to adopt things that used to be done in distributions (and therefore were consistent within a distribution) without suggesting a good convention to follow (suggesting a high probability that they will not be consistent, and distributions will not be allowed to make them consistent) sounds like a change for the worse from the original state (it is, after all, one of the primary roles of a distribution to collect various differing upstreams and make a consistent OS from them) - but, well, the result will not be different from any other inter-project inconsistencies, so I don't view this as a problem. I would rather argue that various upstreams should reach agreement on how things should properly be done and moved forward I don't presume to speak for all upstreams, but I can tell you that postgresql in particular is not likely to want to get involved here. They have other things to worry about, and have always thought that things like initscripts are mainly a packager's province anyway. But the big picture from our point of view is that service postgresql initdb has been the way to initialize a postgresql database for quite a few years, on many platforms besides Red-Hat-based ones. *We* are the ones who are out of step, and only somebody blinded by the Systemd Is The One True Way faith would fail to recognize that. I was speaking genericly on distributions vs upstreams but since you are referring here specifically to postgresql why was it decided to do be done in the init script in the first place instead of standalone script? I'm pretty sure that this administrators muscle memory which has been referred to no longer exist amongst the administrators in the Fedora project I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll be implementing this for postgresql tomorrow, because I'm tired of hearing complaints about it. Which in turn will confusion every administrator that has been custom to do it the *new* way so you probably wind up having to workaround that as well one way or another yup a fracking mess to deal with... If administrators have not gone accustom to systemd after what ca 2 years now they never will... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On 06/26/2012 06:54 PM, Tom Lane wrote: I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll be implementing this for postgresql tomorrow, because I'm tired of hearing complaints about it. I must be the only one that prefers your separate postgresql-setup script over the call to service. IMHO service is dead. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
On Tue, 2012-06-26 at 21:51 -0500, Michael Cronenworth wrote: On 06/26/2012 06:54 PM, Tom Lane wrote: I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll be implementing this for postgresql tomorrow, because I'm tired of hearing complaints about it. I must be the only one that prefers your separate postgresql-setup script over the call to service. You're not. Especially since it handles multiple postgresql instances with an optional parameter. Tom, can you try to make sure the script in /usr/libexec/initscripts/legacy-actions allows the same? Ideally, it would be possible for the admin to do something minimal like the following: # ln -s /usr/libexec/initscripts/legacy-actions/myinstance \ /usr/libexec/initscripts/legacy-actions/postgresql And the script would automatically know (based on the path) what service it's supposed to handle (i.e get the right PGPORT and PGDATA) Looking at postgresql-setup this shouldn't be too hard, instead of getting: SERVICE_NAME=$2 it could be something like: SERVICE_NAME=$(basename $(dirname $0)) IMHO service is dead. Well, I guess we'll still be able to run the /usr/libexec/initscripts/legacy-actions/foo/bar scripts manually? :) -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
Michael Cronenworth m...@cchtml.com writes: On 06/26/2012 06:54 PM, Tom Lane wrote: I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll be implementing this for postgresql tomorrow, because I'm tired of hearing complaints about it. I must be the only one that prefers your separate postgresql-setup script over the call to service. IMHO service is dead. Well, I wouldn't remove postgresql-setup, since it's now been there long enough to have possibly acquired some fans. But it's the non-fans who are complaining... regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for legacy init script actions for systemd services
Mathieu Bridon boche...@fedoraproject.org writes: Especially since it handles multiple postgresql instances with an optional parameter. Tom, can you try to make sure the script in /usr/libexec/initscripts/legacy-actions allows the same? Unless Bill hacked /sbin/service to pass additional parameters through to the legacy script, I don't see how. Anyway this seems a bit outside the charter of the legacy-script feature, which IIUC is to let you do exactly what you did before. If you now prefer postgresql-setup, by all means keep using that. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl] Fix a typo in file names
commit 5a0d2c4f2c48131be674d97712702acd880d1383
Author: Petr Písař ppi...@redhat.com
Date: Tue Jun 26 09:21:59 2012 +0200
Fix a typo in file names
perl.spec |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/perl.spec b/perl.spec
index be9faec..9aeef78 100644
--- a/perl.spec
+++ b/perl.spec
@@ -1941,7 +1941,7 @@ sed \
%exclude %{_mandir}/man3/Pod::Checker.*
%exclude %{_mandir}/man3/Pod::Find.*
%exclude %{_mandir}/man3/Pod::InputObjects.*
-%exclude %{_mandir}/man3/Pod::ParseUtil.*
+%exclude %{_mandir}/man3/Pod::ParseUtils.*
%exclude %{_mandir}/man3/Pod::Parser.*
%exclude %{_mandir}/man3/Pod::PlainText.*
%exclude %{_mandir}/man3/Pod::Select.*
@@ -2426,7 +2426,7 @@ sed \
%{_mandir}/man3/Pod::Checker.*
%{_mandir}/man3/Pod::Find.*
%{_mandir}/man3/Pod::InputObjects.*
-%{_mandir}/man3/Pod::ParseUtil.*
+%{_mandir}/man3/Pod::ParseUtils.*
%{_mandir}/man3/Pod::Parser.*
%{_mandir}/man3/Pod::PlainText.*
%{_mandir}/man3/Pod::Select.*
--
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-WWW-Google-Contacts] Specify all dependencies
commit c06bcd93bfdf935d01ff25132cfecd0e7bec481b
Author: Petr Písař ppi...@redhat.com
Date: Tue Jun 26 09:47:16 2012 +0200
Specify all dependencies
perl-WWW-Google-Contacts.spec | 20
1 files changed, 16 insertions(+), 4 deletions(-)
---
diff --git a/perl-WWW-Google-Contacts.spec b/perl-WWW-Google-Contacts.spec
index 7ce0c75..9eb3cf1 100644
--- a/perl-WWW-Google-Contacts.spec
+++ b/perl-WWW-Google-Contacts.spec
@@ -8,20 +8,31 @@ URL:
http://search.cpan.org/dist/WWW-Google-Contacts/
Source0:
http://www.cpan.org/authors/id/M/ME/MERIXZON/WWW-Google-Contacts-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl(Class::MOP) = 1.09
-BuildRequires: perl(Crypt::SSLeay)
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.31
+# Run-time
+BuildRequires: perl(Carp)
+BuildRequires: perl(constant)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Encode)
BuildRequires: perl(File::Slurp)
BuildRequires: perl(LWP::UserAgent)
BuildRequires: perl(Moose)
+BuildRequires: perl(Moose::Role)
BuildRequires: perl(MooseX::Role::Parameterized)
-BuildRequires: perl(MooseX::Singleton) = 0.25
BuildRequires: perl(MooseX::Types)
+BuildRequires: perl(MooseX::Types::Moose)
BuildRequires: perl(Net::Google::AuthSub)
BuildRequires: perl(Perl6::Junction)
+BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Try::Tiny)
+BuildRequires: perl(URI::Escape)
BuildRequires: perl(XML::Simple)
+# Tests
BuildRequires: perl(Test::More)
+# Not needed but checked by Makefile.PL, stray specification probably
+BuildRequires: perl(Class::MOP) = 1.09
+BuildRequires: perl(Crypt::SSLeay)
+BuildRequires: perl(MooseX::Singleton) = 0.25
# The Requires that are commented are duplicates between cpanspec and
# automatic rpmbuild detection.
@@ -75,6 +86,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Mon Jun 25 2012 Petr Pisar ppi...@redhat.com - 0.33-4
- Perl 5.16 rebuild
+- Specify all dependencies
* Wed Mar 21 2012 Avi Alkalay a...@unix.sh 0.33-3
- Removed duplicate Requires
--
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 835452] New: perl-5.16.0: Broken printing decimal numbers in locales with comma decimal sign
https://bugzilla.redhat.com/show_bug.cgi?id=835452 Bug ID: 835452 QA Contact: extras...@fedoraproject.org Severity: unspecified URL: https://rt.perl.org/rt3/Public/Bug/Display.html?id=109 318 Version: rawhide Priority: unspecified CC: cw...@alumni.drew.edu, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rc040...@freenet.de, tcall...@redhat.com Assignee: mmasl...@redhat.com Summary: perl-5.16.0: Broken printing decimal numbers in locales with comma decimal sign Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: ppi...@redhat.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: ASSIGNED Component: perl Product: Fedora use strict; use warnings; use POSIX; use locale; setlocale(LC_NUMERIC,sv_SE); printf(%g\n,3.14e+9); # prints 3,14e+09\n printf(%g\n,3,14e+9); # prints 3,14e+09\n printf(%g\n,3.14e-9); # prints 3,14e-09\n printf(%g\n,3,14e-9); # prints 3\n *** WRONG! *** Fixed in upstream commit: commit 78787052b6a68c0f54cfa983a69c44276de9daa4 Author: Jesse Luehrs d...@tozt.net Date: Tue Jun 26 00:13:54 2012 -0500 use a less broken test for locale radix in atof [perl #109318] -- 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 832644] abi-compliance-checker-1.98.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=832644 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|abi-compliance-checker-1.98 |abi-compliance-checker-1.98 |.1 is available |.2 is available -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Mojibake-0.4.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Mojibake: 2bbae74363c4a10f0f62efd171fcfd00 Test-Mojibake-0.4.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-Test-Mojibake] Update to 0.4
commit 1b387eacd2080dc9ef5c7711d58a7438b66f2a78
Author: Paul Howarth p...@city-fan.org
Date: Tue Jun 26 13:41:38 2012 +0100
Update to 0.4
- New upstream release 0.4
- _detect_utf8: PP version now handles overlong UTF-8 sequences
- Tests update (96% coverage)
- Dist::Zilla update
- BR: perl(Perl::Critic::Policy::Modules::ProhibitModuleShebang),
perl(Test::EOL) and perl(Test::Version)
- BR: perl(Test::Kwalitee), perl(Test::MinimumVersion),
perl(Test::Perl::Critic) and perl(Test::Synopsis) unconditionally
- Drop support for building for EPEL-4
- Drop patch for building with ExtUtils::MakeMaker 6.30
- Update patch for building with Test::More 0.88
- Add patch to support building without Test::Version
- Add workaround for the old version of PPI in EPEL-5 not being able to
handle the unicode byte order mark in t/bom.pl, which breaks
t/release-minimum-version.t
- Don't need to remove empty directories from the buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
Test-Mojibake-0.3-old-Test::More.patch | 51
Test-Mojibake-0.3-old-eu::mm.patch | 30
Test-Mojibake-0.4-no-Test::Version.patch | 20
Test-Mojibake-0.4-old-Test::More.patch | 74 ++
perl-Test-Mojibake.spec | 68
sources |2 +-
6 files changed, 144 insertions(+), 101 deletions(-)
---
diff --git a/Test-Mojibake-0.4-no-Test::Version.patch
b/Test-Mojibake-0.4-no-Test::Version.patch
new file mode 100644
index 000..44b2752
--- /dev/null
+++ b/Test-Mojibake-0.4-no-Test::Version.patch
@@ -0,0 +1,20 @@
+--- t/release-test-version.t
t/release-test-version.t
+@@ -10,8 +10,8 @@
+ use warnings;
+ use Test::More;
+
+-# generated by Dist::Zilla::Plugin::Test::Version 0.002004
+-BEGIN { eval use Test::Version; 1; or die $@; }
++eval 'use Test::Version';
++plan skip_all = 'Test::Version required' if $@;
+
+ my @imports = ( 'version_all_ok' );
+
+@@ -26,5 +26,5 @@
+
+ Test::Version-import(@imports);
+
+-version_all_ok;
++version_all_ok();
+ done_testing;
diff --git a/Test-Mojibake-0.4-old-Test::More.patch
b/Test-Mojibake-0.4-old-Test::More.patch
new file mode 100644
index 000..9408fd9
--- /dev/null
+++ b/Test-Mojibake-0.4-old-Test::More.patch
@@ -0,0 +1,74 @@
+diff -up Test-Mojibake-0.4/t/06-pp-vs-xs.t.orig
Test-Mojibake-0.4/t/06-pp-vs-xs.t
+--- Test-Mojibake-0.4/t/06-pp-vs-xs.t.orig 2012-06-25 20:36:58.0
+0100
Test-Mojibake-0.4/t/06-pp-vs-xs.t 2012-06-26 13:01:09.341933492 +0100
+@@ -1,7 +1,7 @@
+ #!perl -T
+ use strict;
+
+-use Test::More;
++use Test::More 'no_plan';
+
+ BEGIN {
+ use_ok('Benchmark', 'countit');
+@@ -10,7 +10,6 @@ BEGIN {
+
+ unless ($Test::Mojibake::use_xs) {
+ diag('No XS module detected, will fallback to PP implementation!');
+-done_testing(2);
+ exit;
+ }
+
+@@ -33,8 +32,6 @@ ok($t0-iters $t1-iters, 'XS faster t
+
+ diag(sprintf('XS/PP speed ratio is %0.2f', $t0-iters / $t1-iters));
+
+-done_testing(7);
+-
+ sub run {
+ my $i = 0;
+ for (@buf) {
+diff -up Test-Mojibake-0.4/t/07-broken-utf8.t.orig
Test-Mojibake-0.4/t/07-broken-utf8.t
+--- Test-Mojibake-0.4/t/07-broken-utf8.t.orig 2012-06-25 20:36:58.0
+0100
Test-Mojibake-0.4/t/07-broken-utf8.t 2012-06-26 13:01:09.356933495
+0100
+@@ -24,7 +24,7 @@ my @tests = (
+ [11-overlong-5= 0 = \\xfc\x80\x80\x80\x80\xaf],
+ );
+
++plan tests = scalar @tests;
++
+ ok(Test::Mojibake::_detect_utf8($_-[2]) == $_-[1], $_-[0])
+ for @tests;
+-
+-done_testing(scalar @tests);
+diff -up Test-Mojibake-0.4/t/release-cpan-changes.t.orig
Test-Mojibake-0.4/t/release-cpan-changes.t
+--- Test-Mojibake-0.4/t/release-cpan-changes.t.orig2012-06-25
20:36:58.0 +0100
Test-Mojibake-0.4/t/release-cpan-changes.t 2012-06-26 13:01:09.356933495
+0100
+@@ -1,15 +1,11 @@
+ #!perl
+
++use Test::More;
++
+ BEGIN {
+- unless ($ENV{RELEASE_TESTING}) {
+-require Test::More;
+-Test::More::plan(skip_all = 'these tests are for release candidate
testing');
+- }
++ plan skip_all = 'these tests are for release candidate testing' unless
($ENV{RELEASE_TESTING});
++ eval 'use Test::CPAN::Changes';
++ plan skip_all = 'Test::CPAN::Changes required for this test' if $@;
+ }
+
+-
+-use Test::More;
+-eval 'use Test::CPAN::Changes';
+-plan skip_all = 'Test::CPAN::Changes required for this test' if $@;
+ changes_ok();
+-done_testing();
+diff -up Test-Mojibake-0.4/t/release-test-version.t.orig
Test-Mojibake-0.4/t/release-test-version.t
+--- Test-Mojibake-0.4/t/release-test-version.t.orig2012-06-26
13:01:09.0 +0100
Test-Mojibake-0.4/t/release-test-version.t 2012-06-26 13:01:53.073948449
+0100
+@@ -27,4 +27,3 @@ push @imports, $params
+ Test::Version-import(@imports);
+
+ version_all_ok();
+-done_testing;
diff --git
[perl-Class-Load] Conditionalize Pod::Coverage::Moose.
commit 221ab3b9792c9f0ff3508ef92a02a75204a0aac9
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Jun 26 14:50:04 2012 +0200
Conditionalize Pod::Coverage::Moose.
perl-Class-Load.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index 25d5af8..57e4e2b 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -1,6 +1,6 @@
Name: perl-Class-Load
Version: 0.19
-Release: 4%{?dist}
+Release: 5%{?dist}
Summary: A working (require Class::Name) and more
Group: Development/Libraries
License: GPL+ or Artistic
@@ -39,7 +39,7 @@ BuildRequires:perl(version)
# Author/Release test requirements
# ===
# Pod::Coverage::Moose - Moose - Class::Load
-%if 0%{!?perl_bootstrap:1}
+%if 0%{!?perl_bootstrap:1} || 0%{?rhel} 7
BuildRequires: perl(Pod::Coverage::Moose)
%endif
BuildRequires: perl(Test::CPAN::Changes)
@@ -95,6 +95,9 @@ make test %{!?perl_bootstrap:RELEASE_TESTING=1}
%{_mandir}/man3/Class::Load.3pm*
%changelog
+* Tue June 26 2012 Marcela Mašláňová mmasl...@redhat.com - 0.19-5
+- conditionalize Pod::Coverage::Moose
+
* Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 0.19-4
- Perl 5.16 rebuild
--
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-Mojibake] Created tag perl-Test-Mojibake-0.4-1.fc18
The lightweight tag 'perl-Test-Mojibake-0.4-1.fc18' was created pointing to: 1b387ea... Update to 0.4 -- 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 Test-NoTabs-1.3.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-NoTabs: 4b0800b977abf2576e873812046248fb Test-NoTabs-1.3.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-Test-NoTabs] Update to 1.3
commit 0a6b41e46d3604c0e3896fa2738d699734a5cc70
Author: Paul Howarth p...@city-fan.org
Date: Tue Jun 26 14:01:05 2012 +0100
Update to 1.3
- New upstream release 1.3:
- Fix regex to ignore '.svn', but not 'Xsvn' - unescaped
perl-Test-NoTabs.spec |6 +-
sources |2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Test-NoTabs.spec b/perl-Test-NoTabs.spec
index efa0f1b..eeda125 100644
--- a/perl-Test-NoTabs.spec
+++ b/perl-Test-NoTabs.spec
@@ -1,5 +1,5 @@
Name: perl-Test-NoTabs
-Version: 1.2
+Version: 1.3
Release: 1%{?dist}
Summary: Check the presence of tabs in your project
Group: Development/Libraries
@@ -47,6 +47,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::NoTabs.3pm*
%changelog
+* Tue Jun 26 2012 Paul Howarth p...@city-fan.org - 1.3-1
+- Update to 1.3
+ - Fix regex to ignore '.svn', but not 'Xsvn' - unescaped
+
* Sun Jun 17 2012 Paul Howarth p...@city-fan.org - 1.2-1
- Update to 1.2
- Fix to ignore inc/ for Module::Install
diff --git a/sources b/sources
index a30d725..2cbbe3b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-00128394b3817803a8e003cbc89ee51a Test-NoTabs-1.2.tar.gz
+4b0800b977abf2576e873812046248fb Test-NoTabs-1.3.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-Test-NoTabs] Created tag perl-Test-NoTabs-1.3-1.fc18
The lightweight tag 'perl-Test-NoTabs-1.3-1.fc18' was created pointing to: 0a6b41e... Update to 1.3 -- 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-Class-Load] Conditionalize again in the correct way.
commit d65aa10e6095a894343debac2992a406dd4492c1
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Jun 26 15:58:16 2012 +0200
Conditionalize again in the correct way.
perl-Class-Load.spec |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index 57e4e2b..1688691 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -39,7 +39,7 @@ BuildRequires:perl(version)
# Author/Release test requirements
# ===
# Pod::Coverage::Moose - Moose - Class::Load
-%if 0%{!?perl_bootstrap:1} || 0%{?rhel} 7
+%if 0%{!?perl_bootstrap:1} 0%{?rhel} 7
BuildRequires: perl(Pod::Coverage::Moose)
%endif
BuildRequires: perl(Test::CPAN::Changes)
@@ -95,7 +95,7 @@ make test %{!?perl_bootstrap:RELEASE_TESTING=1}
%{_mandir}/man3/Class::Load.3pm*
%changelog
-* Tue June 26 2012 Marcela Mašláňová mmasl...@redhat.com - 0.19-5
+* Tue Jun 26 2012 Marcela Mašláňová mmasl...@redhat.com - 0.19-5
- conditionalize Pod::Coverage::Moose
* Tue Jun 19 2012 Petr Pisar ppi...@redhat.com - 0.19-4
--
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-Class-Load] Conditionalize even tests.
commit 402fcfcf593e882fcb79e1c997e23bead8968088
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Jun 26 16:07:31 2012 +0200
Conditionalize even tests.
perl-Class-Load.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index 1688691..b7a1352 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -87,7 +87,11 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
%{_fixperms} %{buildroot}
%check
-make test %{!?perl_bootstrap:RELEASE_TESTING=1}
+%if 0%{!?perl_bootstrap:1} 0%{?rhel} 7
+make test RELEASE_TESTING=1
+%else
+make test
+%endif
%files
%doc Changes LICENSE README
--
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-POE-Component-Server-SimpleHTTP] Perl 5.16 rebuild
commit de01d9aaebce079684fe3d512044698bd7089243
Author: Petr Písař ppi...@redhat.com
Date: Tue Jun 26 17:17:17 2012 +0200
Perl 5.16 rebuild
perl-POE-Component-Server-SimpleHTTP.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Component-Server-SimpleHTTP.spec
b/perl-POE-Component-Server-SimpleHTTP.spec
index 858ff74..40f3fe7 100644
--- a/perl-POE-Component-Server-SimpleHTTP.spec
+++ b/perl-POE-Component-Server-SimpleHTTP.spec
@@ -1,7 +1,7 @@
Name: perl-POE-Component-Server-SimpleHTTP
# Use two digit pricision since 2.04 version
Version:2.14
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Serve HTTP requests in POE
License:GPL+ or Artistic
Group: Development/Libraries
@@ -73,6 +73,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 26 2012 Petr Pisar ppi...@redhat.com - 2.14-2
+- Perl 5.16 rebuild
+
* Tue Jan 17 2012 Petr Šabata con...@redhat.com - 2.14-1
- 2.14 bump
- Spec cleanup
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Reversing Module::Build version
On Wed, 30 May 2012 18:26:03 +0200 Petr Pisar ppi...@redhat.com wrote: Hello, Current F18 delivers `perl(Module::Build) = 0.3800' and following packages build-require versioned Module::Build: EekBoek-0:2.00.04-1.fc18.src perl-BackPAN-Index-0:0.40-4.fc17.src perl-DBD-AnyData-0:0.110-4.fc17.src perl-Data-FormValidator-0:4.70-2.fc17.src perl-Data-Types-0:0.09-2.fc17.src perl-Date-Manip-0:6.31-1.fc18.src perl-File-ChangeNotify-0:0.22-1.fc18.src perl-JavaScript-Beautifier-0:0.17-6.fc17.src perl-Module-ExtractUse-0:0.27-1.fc18.src perl-Module-Install-0:1.04-1.fc17.src perl-MooseX-ClassAttribute-0:0.26-4.fc17.src perl-POE-Component-SSLify-0:1.008-2.fc17.src perl-Padre-0:0.90-2.fc17.src perl-Params-Validate-0:1.06-1.fc18.src perl-Perl-Critic-Dynamic-0:0.05-1.fc18.src perl-RPM2-0:1.0-3.fc18.src perl-STD-0:32116-5.fc17.src perl-Task-Perl-Critic-0:1.008-1.fc18.src perl-Test-Aggregate-0:0.364-3.fc17.src perl-Test-Exception-0:0.31-5.fc17.src perl-Test-Perl-Critic-0:1.02-7.fc18.src perl-Test-Pod-0:1.45-3.fc17.src perl-Test-Trap-0:0.2.1-3.fc17.src perl-Text-ASCIITable-0:0.20-1.fc17.src perl-URI-Find-0:2003-1.fc17.src perl-local-lib-0:1.008004-4.fc18.src However Perl 5.16.0 delivers `perl(Module::Build) = 0.39' ($VERSION=0.39_01 more precisly): $ rpm -q --provides -p RPMS/perl-Module-Build-0.3901-218.fc18.noarch.rpm |sort perl(inc::latest::private) = 0.39 perl(inc::latest) = 0.39 perl(Module::Build::Base) = 0.39 perl(Module::Build::Compat) = 0.39 perl(Module::Build::ConfigData) perl(Module::Build::Config) = 0.39 perl(Module::Build::Cookbook) = 0.39 perl(Module::Build::Dumper) = 0.39 perl(Module::Build::ModuleInfo) = 0.39 perl(Module::Build::Notes) = 0.39 perl(Module::Build::Platform::aix) = 0.39 perl(Module::Build::Platform::Amiga) = 0.39 perl(Module::Build::Platform::cygwin) = 0.39 perl(Module::Build::Platform::darwin) = 0.39 perl(Module::Build::Platform::Default) = 0.39 perl(Module::Build::Platform::EBCDIC) = 0.39 perl(Module::Build::Platform::MacOS) = 0.39 perl(Module::Build::Platform::MPEiX) = 0.39 perl(Module::Build::Platform::os2) = 0.39 perl(Module::Build::Platform::RiscOS) = 0.39 perl(Module::Build::Platform::Unix) = 0.39 perl(Module::Build::Platform::VMS) = 0.39 perl(Module::Build::Platform::VOS) = 0.39 perl(Module::Build::Platform::Windows) = 0.39 perl(Module::Build::PodParser) = 0.39 perl(Module::Build::PPMMaker) = 0.39 perl(Module::Build::Version) = 0.87 perl(Module::Build::YAML) = 1.41 perl(Module::Build) = 0.39 perl-Module-Build = 1:0.3901-218.fc18 Also CPAN upstream returned to two-digit versions: Module-Build-0.40 Module-Build-0.39_02 Module-Build-0.39_01 Module-Build-0.3800 [...] Which is the reason why Fedora upstream monitoring has not noticed new Module::Build version. My question is what to do? We can (1) prolong the provides to 0.3901 which will require a lot of code with __exclude_provides and injection of artitifical Provides. (2) contrack version to 0.39 and increase epoch (both package and Provides). That means adding epoch to provides which again requires painful Provides editing as in (1). (3) keep short 0.39, increase package epoch only and remove the version constrain from build-requires of above listed packages. Ho hum. Upstream has just released 0.4001. RPM version 0.40.01? Paul. -- 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 827944] abi-compliance-checker-1.97.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=827944 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2012-06-26 17:27:48 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- abi-compliance-checker-1.97.8-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. -- 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 827944] abi-compliance-checker-1.97.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=827944 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- abi-compliance-checker-1.97.8-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. -- 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
