Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler kevin.kof...@chello.at wrote: Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an optimization, I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). So? Should we drop all features that aren't bug free after feature freeze? You complain as if we are going to release GA tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 10:47 AM, Reindl Harald wrote:
Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson:
On 02/14/2012 10:23 AM, Alfredo Ferrari wrote:
Do the systemd maintainers ever read bug reports BTW?
Why do you think otherwise?
Not only read them but fix them as well.
To give you some stats
There are currently 96 Open bugs against systemd and 536 that have been closed
at the time of this writing...
In F15 which should be the most buggied release since it was the initial
release into the distribution only has 11
bugs
will systemctl restart ever has working autocompletion for RUNNING services?
it is a littl ebit odd the it does show STOPPED services because
restart makes ususally more sense for running ones...
You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do
this for you.
Replace the $( __get_all_units | grep ...)) with $( __get_active_units ) )
.
.
.
elif __contains_word $verb ${VERBS[RESTARTABLE_UNITS]}; then
comps=$( __filter_units_by_property CanStart yes \
$( __get_all_units | grep -Ev
'\.(device|snapshot|socket|timer)$' ))
.
.
.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 15.02.2012 10:53, schrieb Brendan Jones: On 02/15/2012 10:47 AM, Reindl Harald wrote: Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do this for you. i could setup also linux from scratch that is not the point the question is: do systemd-developers never use TAB and type all their stuff completly like on a windows box that they do not recognize this at the first place? this is a category of bug where i always expect that no report is needed since every developer using his software is expected to take notice of this signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On 02/15/2012 10:37 AM, drago01 wrote: On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at wrote: Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an optimization, I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 11:18 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/15/2012 10:37 AM, drago01 wrote: On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at wrote: Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an optimization, I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. elementary bugs ? You got to be either kidding or trolling. What do you expect Fedora users to think of this? We are at pre alpha / alpha ... users should not have to care about that right now. It communicates a nice impression of the quality of your works. I am not involved in this so it is not my works ... Better stop this non-sense now! The only nonsense I see here is people ranting for the sake of ranting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 11:25, schrieb drago01: So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. elementary bugs ? You got to be either kidding or trolling. What do you expect Fedora users to think of this? We are at pre alpha / alpha ... users should not have to care about that right now. It communicates a nice impression of the quality of your works. I am not involved in this so it is not my works ... Better stop this non-sense now! The only nonsense I see here is people ranting for the sake of ranting. people are ranting because the experience how buggy are features in the GA-releases if they are in such a not conesquently thought state at alpha the last releases it was always fact that they was not ready until GA and if they can't be fixed then common bugs are listed in the release notes the problem is here that first the work/change/feature is started as happend often in the past and in the middle of the work more and more people coming with things nobody cared in tghe planning phase what let many of us feel like there is nothing planned, there were people starting and forcing without any thoughts and the hope that all will get sorted until GA signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: F17 Alpha RC1 arriving ahead of schedule
TC3: https://fedorahosted.org/rel-eng/ticket/5083 this is two days ahead of schedule, but it's good to get going early! The compose should arrive some time today, Andre will no doubt announce it as usual. Thanks all. Ugh, we really want this one: https://admin.fedoraproject.org/updates/beefy-miracle-kde-theme-16.91.0.1-1.fc17,kde-settings-4.8-5.fc17 in! :-( Without it, Plasma has a blank (all black) background. What KDE isn't perfect in the distro at Alpha, we should revert it to the one from F16? sorry I can't resist joining in the fedora-devel meme of the week. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 11:55 AM, Reindl Harald wrote: Am 15.02.2012 10:53, schrieb Brendan Jones: On 02/15/2012 10:47 AM, Reindl Harald wrote: Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do this for you. i could setup also linux from scratch that is not the point the question is: do systemd-developers never use TAB and type all their stuff completly like on a windows box that they do not recognize this at the first place? this is a category of bug where i always expect that no report is needed since every developer using his software is expected to take notice of this As you obviously haven't lost your ability to type, and your keyboard appears to have all the necessary non-tab keys still in place: file a bug on it if it bothers you so much. It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de: Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now rofl... nothing else is broken and my PATH is non-optimal, stop the usrmove, because I don't want it. this is so ridicoulus... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On 15/02/12 10:18, Ralf Corsepius wrote: So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now! I'm a user, don't have a problem. -- Regards FRank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 12:05, schrieb Harald Hoyer: Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de: Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now rofl... nothing else is broken and my PATH is non-optimal, stop the usrmove, because I don't want it. the nothing else we will see later fact is that the feauture is included and now people are coming did we think about this and this and this... there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure this feels like you guys has no other things to do and sitting there hmm let us search for solutions press into a release and let us search for constructed problems the solution may solve to have any valid reason to do it now signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Mon, 2012-02-13 at 09:28 -0800, Adam Williamson wrote: On Mon, 2012-02-13 at 14:47 +0100, Nils Philippsen wrote: On Fri, 2012-02-10 at 11:08 -0800, Adam Williamson wrote: Let me put it this way, then: Fedora is released on a six month cycle, which is far faster than is usually considered desirable for server usage. It has a 13 month lifetime, which is far shorter than is usually considered desirable for server usage. Its key values and goals are assuredly not compatible with typical server usage - e.g. First - We believe in the power of innovation and showing off new work in our releases. Since we release twice a year, you never have to wait long to see the latest and greatest software, while there are other Linux products derived from Fedora you can use for long-term stability. We always keep Fedora moving forward so that you can see the future first. There are numerous practical policies derived from these values which are clearly not optimal for server usage, such as the short freeze times, relatively low barrier of entry to disruptive features, and QA focus on installation and basic desktop use (we do virtually no QA on any kind of server usage). Finally, there are *several* Linux distributions available which have none of the above 'shortcomings' (so far as server usage is concerned). I'd say the same 'shortcomings' also hurt the end user case. The non-technical people I deal with loathe how we often introduce new features and break stuff (or just their way of doing things) in the process, even in updates -- I've stopped counting the Oh, updates. I wonder what you guys have broken now.-style comments by my wife. To me, Fedora is much better suited to be run on servers than by end users -- admins usually can help themselves in these situations. Don't take this as being against the slew of features Fedora introduces: personally I'm much in favor of systemd, the /usr move, pulseaudio and all that stuff -- there's no point in just treading water and being on the forefront of things is where Fedora is supposed to be. But let's not kid ourselves into thinking that with a life-cycle of only 13 months and the amount of change we introduce in each new release (especially on the desktop) we're somehow catering to end users who don't have a technically skilled spouse, relative or friend in the background to help if things don't work as expected. That also, at least arguably, isn't Fedora's aim (if it was, we'd be doing a terrible job of it, I agree). To cite the Board again: https://fedoraproject.org/wiki/User_base Voluntary Linux consumer Computer-friendly Likely collaborator General productivity user Those four - especially 'computer-friendly' and 'likely collaborator' - don't scream 'end user' to me. My personal take has always been that Fedora is not the friendly desktop operating system of today, but a *prototype* of the friendly desktop operating system of tomorrow. A constantly moving prototype - so it never sits still and becomes the friendly desktop operating system of today. :) Of course :-). In the light of that however, I don't really understand the Fedora is not for servers arguments brought forth every so often... Fedora is not well-suited if what you want is longevity, full stop. Disregarding that point, Fedora on a server is quite hassle-free :-). Nils -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure Well, I need usrmove, because I have a strong need for clean system. Here, your point is invalid. Harald, you are generating copius amounts of stop-energy. You really should participate in Fedora process as it designed - during feature proposals, discussions, implementation. Right now you are ranting post factum. The amount of time you waste on this mail list is huge, and it is a sad waste. It would be better spent on filling bugs on real issues. Because bugs, you know, get fixed. I even remember one bug that you have filled about some deamon not shipping a systemd unit. I saw this bug, I've created and attached unit file, it got shipped by maintainer. Case closed. This is the best way of participation. Your baseless, repetitive rants finally made me blacklist you. It's very sad for me, as I believe in open participation and meritocracy. Good bye, -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. pgpsRQfuuDJox.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 05:49 AM, Panu Matilainen wrote: On 02/15/2012 11:55 AM, Reindl Harald wrote: Am 15.02.2012 10:53, schrieb Brendan Jones: On 02/15/2012 10:47 AM, Reindl Harald wrote: Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do this for you. i could setup also linux from scratch that is not the point the question is: do systemd-developers never use TAB and type all their stuff completly like on a windows box that they do not recognize this at the first place? this is a category of bug where i always expect that no report is needed since every developer using his software is expected to take notice of this As you obviously haven't lost your ability to type, and your keyboard appears to have all the necessary non-tab keys still in place: file a bug on it if it bothers you so much. It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 789975] perl-Hash-MultiValue-0.12 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=789975 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Hash-MultiValue-0.11 |perl-Hash-MultiValue-0.12 |is available|is available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2012-02-15 06:38:35 EST --- Latest upstream release: 0.12 Current version in Fedora Rawhide: 0.10 URL: http://search.cpan.org/dist/Hash-MultiValue/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: /usrmove and path ordering
Am 15.02.2012 12:24, schrieb Tomasz Torcz: On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure Well, I need usrmove, because I have a strong need for clean system. Here, your point is invalid. you mean all existing linux-installations are unclean? you need a clean system but accept that half of the distribution is a mix of systemd/sysv/lsb - you would get a clean system if the work of one feature would be COMPLETLY done before the next is started, but seems that most people have no intention nor the make nor any idea what is a clean system signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into the next release with pressure
You are wrong. The /usr move has a very clear impact in being able to
snapshot your OS install partition. Add btrfs, yum hooks and the
already-implemented stateless configuration and you have a really major
feature: a fully upgrade/test/rollback setup for Fedora.
For OLPC for example, this could be a major win, hence my interest. I
definitely want it for my laptop. I'm sure many running rawhide will want
it :-) -- upgrade/test/file bugs if it breaks/rollback if it's real bad.
cheers,
m
{ Martin Langhoff - one laptop per child }
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 13:43, schrieb Martin Langhoff: On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. only one out of a million installations have /usr seperated from / and the default is NOT do this - so no there is no impact on any normal setup signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
service iptables save, systemctl, and unhelpful error messages
Currently, on Fedora 16, service iptables save prints the following: # service iptables save Redirecting to /bin/systemctl save iptables.service Unknown operation save The service iptables save command is documented in a number of places and has been recommended to users for years. See, for example, the security guide: http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-Using_IPTables-Saving_and_Restoring_IPTables_Rules.html This breaking with the systemctl move is expected, but the unhelpful error message is a usability bug. Executing services iptables save should print This is no longer supported. Please execute /usr/libexec/iptables.init save (See: https://bugzilla.redhat.com/show_bug.cgi?id=748134 ) From a technical perspective, that would mean the /sbin/service wrapper would need to be rewritten check a file for the command that is being asked to do, and print different error messages depending on the situation. Of course that makes the currently simple wrapper script more complex, but if we want to keep moving forward as fast as Fedora is, we should make the extra effort to stay friendly to our users too. Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff martin.langh...@gmail.com wrote: You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. I haven't seen this work and I don't think such snaphots can be relied upon: /boot, /etc and /var are affected by installs as well (especially in the cases where you would want to roll back); I don't think anybody wants exactly the separation provided by the crude /usr vs. rest that is provided by the /usr move. And snapshots that can not be relied upon may be even worse than no snapshots if they motivate users to skip creating proper backups. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 14:25, schrieb Miloslav Trmač: On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff martin.langh...@gmail.com wrote: You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. I haven't seen this work and I don't think such snaphots can be relied upon: /boot, /etc and /var are affected by installs as well (especially in the cases where you would want to roll back); I don't think anybody wants exactly the separation provided by the crude /usr vs. rest that is provided by the /usr move. this is a additional reason why the /usrmove is completly useless because it suggests users they are save using any FS-snapshot have many fun after a big upgrade to revert the snapshot if you really have /usr on a seperated FS and your /etc and /var/lib/rpm will stay in the state after the upgrade and your FS is bombed back so for users having a default setup there is no difference because / as /etc and /usr is the same FS and for ones have seperated /usr it does not bring any benefit in real life with other words: the whole work which is done here is useless and low brained with constrcuted arguments not working in the real life and they were only coonstructed to push this feature because some developers are bored and fear this maybe happen also to users if they do not change permanently things which are working fine yes i know, now i get a reply about politness - but face the truth! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/15/2012 01:15 PM, Emanuel Rietveld wrote: Currently, on Fedora 16, service iptables save prints the following: # service iptables save Redirecting to /bin/systemctl save iptables.service Unknown operation save The service iptables save command is documented in a number of places and has been recommended to users for years. See, for example, the security guide: http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-Using_IPTables-Saving_and_Restoring_IPTables_Rules.html This breaking with the systemctl move is expected, but the unhelpful error message is a usability bug. Executing services iptables save should print This is no longer supported. Please execute /usr/libexec/iptables.init save (See: https://bugzilla.redhat.com/show_bug.cgi?id=748134 ) From a technical perspective, that would mean the /sbin/service wrapper would need to be rewritten check a file for the command that is being asked to do, and print different error messages depending on the situation. Of course that makes the currently simple wrapper script more complex, but if we want to keep moving forward as fast as Fedora is, we should make the extra effort to stay friendly to our users too. Thomas Woerner has been working on a more user friendly firewall solution for Fedora so firewall solution is in a bit of state of flux in Fedora at this point in time and explains why things are as they are. He was going to push this in at the same time as systemd as in Fedora F15 but due to various reasons he backed out of it at that time. ( but it is one of F17 features ) Experienced admins dont use service iptables blah anyway ( they use iptables commands directly ) so it hardly matters to them documentation should however be updated for those that actually use service iptables blah to point this out so you should file a DOC bug for it. Somehow I doubt that any bugs will be fixed for this in either systemd ( since this is not systemd bug ) or iptables ( since Thomas is working on the new stuff and this does probably not climb high enough in his priority list anyway he probably would not fix this until all the bits for that are in place). So if you or others want this fixed I'm pretty sure either side ( most notably iptables ) would gladly review and accept patches should they be submitted. JBG 1. http://fedoraproject.org/wiki/Features/firewalld-default 2.http://fedoraproject.org/wiki/FirewallD/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
Am 15.02.2012 15:45, schrieb Jóhann B. Guðmundsson:
Experienced admins dont use service iptables blah anyway ( they use iptables
commands directly ) so it hardly
matters to them documentation should however be updated for those that
actually use service iptables blah to point
this out so you should file a DOC bug for it.
they do because they found out how to built their complete rules
years ago with a script and how to save the rules to apply them
at tnext reboot by
[root@testserver:~]$ service iptables help
Verwendung: iptables {start|stop|restart|condrestart|status|panic|save}
__
# Skript-Konfiguration
export IPTABLES=/sbin/iptables
IPTABLES_SAVE=/sbin/service iptables save
LOUNGE_WAN=91.118.73.0/24
RHSOFT_LOCAL=84.113.45.179
RHSOFT_ARRAKIS=84.113.45.132
RHSOFT_TESTSERVER=84.113.45.81
HOST=192.168.196.1
echo Setze Regeln zurueck
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -F
$IPTABLES -X
CHAINS=`cat /proc/net/ip_tables_names 2/dev/null`
for i in $CHAINS; do $IPTABLES -t $i -F; done echo Flush OK || echo Flush
FAILED
for i in $CHAINS; do $IPTABLES -t $i -X; done echo Clear OK || echo Clear
FAILED
for i in $CHAINS; do $IPTABLES -t $i -Z; done
echo
echo Blockiere Traffic zu Beginn
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
echo
echo OS-Fingerprinting/Invalide Pakete blockieren
$IPTABLES -A INPUT ! -i lo -m state --state INVALID -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp -m state --state NEW --dport 0 -j DROP
$IPTABLES -A INPUT ! -i lo -p udp -m state --state NEW --dport 0 -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL FIN -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL ALL -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ALL NONE -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ACK,FIN FIN -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ACK,PSH PSH -j DROP
$IPTABLES -A INPUT ! -i lo -p tcp --tcp-flags ACK,URG URG -j DROP
echo Neue Verbindungen ohne SYN-Flag verwefen
$IPTABLES -A INPUT ! -i lo -p tcp ! --syn -m state --state NEW -j DROP
echo Eingehende Fragmente verwerfen
$IPTABLES -A INPUT ! -i lo -f -j DROP
echo IP-Spoofing des Loopback-Device verhindern
$IPTABLES -A INPUT ! -i lo -s 127.0.0.0/8 -j DROP
echo
echo Loopback erlauben
$IPTABLES -A INPUT -i lo -j ACCEPT
echo
echo Ausgehende Pakete erlauben
$IPTABLES -P OUTPUT ACCEPT
echo
echo Antwortpakete erlauben
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
echo SSH aus allen Netzen erlauben, Rate-Control
echo 10022
$IPTABLES -A INPUT -p tcp --sport 1024:65535 -m state --syn --state NEW --dport
10022 -m limit --limit 15/minute
--limit-burst 15 -j ACCEPT
$IPTABLES -A INPUT -p tcp -m state --syn --state NEW --dport 10022 -j REJECT
--reject-with icmp-host-unreachable
echo
echo HTTP-Ports aus rhsoft/thelounge-Netzwerken erlauben
echo TCP 80,443
$IPTABLES -A INPUT -p tcp -s $LOUNGE_WAN -m multiport --destination-port 80,443
-m state --state NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp -s $RHSOFT_LOCAL -m multiport --destination-port
80,443 -m state --state NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp -s $RHSOFT_ARRAKIS -m multiport --destination-port
80,443 -m state --state NEW --syn -j
ACCEPT
$IPTABLES -A INPUT -p tcp -s $RHSOFT_TESTSERVER -m multiport --destination-port
80,443 -m state --state NEW --syn
-j ACCEPT
echo
echo Mail-Ports aus rhsoft/thelounge-Netzwerken erlauben
echo TCP 25,587,465,143,993,2000
$IPTABLES -A INPUT -p tcp -s $LOUNGE_WAN -m multiport --destination-port
25,587,465,143,993,2000 -m state --state
NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp -s $RHSOFT_LOCAL -m multiport --destination-port
25,587,465,143,993,2000 -m state --state
NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp -s $RHSOFT_ARRAKIS -m multiport --destination-port
25,587,465,143,993,2000 -m state
--state NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp -s $RHSOFT_TESTSERVER -m multiport --destination-port
25,587,465,143,993,2000 -m state
--state NEW --syn -j ACCEPT
echo
echo AFP aus rhsoft/thelounge-Netzwerken erlauben
echo TCP 548
$IPTABLES -A INPUT -p tcp --sport 1024:65535 -s $LOUNGE_WAN --dport 548 -m
state --state NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 1024:65535 -s $RHSOFT_LOCAL --dport 548 -m
state --state NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 1024:65535 -s $RHSOFT_ARRAKIS --dport 548 -m
state --state NEW --syn -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 1024:65535 -s $RHSOFT_TESTSERVER --dport 548
-m state --state NEW --syn -j ACCEPT
echo
echo Ping aus bekannten
Re: [fedora-java] Improvements Eclipse Installation
I am going to hold off on this as I have run into an issue where bundles installed using and update site don't work with bundles installed using rpm if there is a bundle conflict between the two. I am investigating. After looking into this I realized that we cannot move forward with the reconciler solution. The issue here is not the old issue of plugins not being installed properly using eclipse's installation system p2, but having plugins installed in two different locations each with it's own metadata. The first location being system directories used by rpm such as /usr/share/eclipse/ and the location used by the eclipse installation system ~/.eclipse. When there is a conflict between the two location eclipse simply picks the system installation resulting in the downloaded plugin and all downloaded plugins to be dropped. We are working on a better solution for this problem. Thanks, Sami -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review ticket #111 - ability to control behavior of modifyTimestamp/modifiersNa
Revised fix based on Rich's comments https://fedorahosted.org/389/ticket/111 https://fedorahosted.org/389/attachment/ticket/111/0001-Ticket-111-ability-to-control-behavior-of-modifyTime.patch Thanks, Mark -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: /usrmove? - about the future
Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 8:30 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.02.2012 14:25, schrieb Miloslav Trmač: I haven't seen this work and I don't think such snaphots can be relied upon: /boot, /etc and /var are affected by installs as well Miroslav -- you haven't seen this work because the tasks are not all yet in. But the stateless feature handles a lot of it already. this is a additional reason why the /usrmove is completly Harald, it is one step in a process. I am very happy and thankful that Fedora is working in this direction. Now, it's time for me to step aside from this thread. 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
Re: /usrmove? - about the future
Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. -- 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
[Bug 789784] Provide native systemd service
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=789784 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2012-02-15 12:23:25 --- Comment #8 from Jon Ciesla limburg...@gmail.com 2012-02-15 12:23:25 EST --- Done, had to patch for gcc47. Thanks, all! -- 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. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: /usrmove? - about the future
On 02/15/2012 10:40 PM, Reindl Harald wrote: it is used by all professional users using mostly a terminal it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! Have you filed a bug report yet? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 bootloader error
When trying to do test install against F17Alpha TC2, during partition layout, I get error below... you have not created a bootloader stage1 target device I have F16 installed on here, and even reformatted the disks to GPT before I installed F16. So using same partitions as installed like I always do should just work. So hoping this a install issue and not a me issue LOL. Below are links to the error and my partition layout (the top harddrive is Win 7) Error... http://miketc.net/bootloader.jpg Partition Layout... http://miketc.net/partitions.jpg -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 10:48 PM, Chris Adams wrote: Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. Ah. didn't notice that. I haven't done a fresh installation since Fedora 11 or so. Regardless of that, the point remains that it is easier to file a bug report when you find a bug rather than assume the developers have noticed the problem already. I routinely remove bash-completion or disable it in the past because of slowdown in some cases and I suspect I am not the only one. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 11:19:18PM +0530, Rahul Sundaram wrote: On 02/15/2012 10:48 PM, Chris Adams wrote: Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. Ah. didn't notice that. I haven't done a fresh installation since Fedora 11 or so. Regardless of that, the point remains that it is easier to file a bug report when you find a bug rather than assume the developers have noticed the problem already. I routinely remove bash-completion or disable it in the past because of slowdown in some cases and I suspect I am not the only one. And people use different shells (zsh seems to be popular), so they won't nottice bugs in something bash-specific. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-17 Branched report: 20120212 changes
On Sun, Feb 12, 2012 at 11:14:29 -0700, Kevin Fenzi ke...@scrye.com wrote: the rawhide and branched composes logs can be found at: http://kojipkgs.fedoraproject.org/mash/rawhide/ and http://kojipkgs.fedoraproject.org/mash/branched/ Note those are really the locations for the last successful builds. If you want to find logs for particular builds, you want to start one level higher: http://kojipkgs.fedoraproject.org/mash/ Out of curiosity I used that to look and see what happened to today's build. I don't fully understand it, but it looks related to deltas and signing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 15.02.2012 18:40, schrieb Rahul Sundaram: On 02/15/2012 10:40 PM, Reindl Harald wrote: it is used by all professional users using mostly a terminal it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! Have you filed a bug report yet? i SURELY have made a notice in one of many bug-reports belonging to systemd last year signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 15.02.2012 18:53, schrieb Tomasz Torcz: On Wed, Feb 15, 2012 at 11:19:18PM +0530, Rahul Sundaram wrote: On 02/15/2012 10:48 PM, Chris Adams wrote: Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. Ah. didn't notice that. I haven't done a fresh installation since Fedora 11 or so. Regardless of that, the point remains that it is easier to file a bug report when you find a bug rather than assume the developers have noticed the problem already. I routinely remove bash-completion or disable it in the past because of slowdown in some cases and I suspect I am not the only one. And people use different shells (zsh seems to be popular), so they won't nottice bugs in something bash-specific. does not matter because bash is the default shell and transitions have to be targeted for defaults and any developer of core-components has to use system defaults for his testings signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 07:10 PM, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal No it is not. Many perhaps, but many does not equal all. it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! For all this talk about professionals, the professional thing to do is to go file the bug already. Crying out OMG they broke my tab! Those bastards! in a mailing list thread about /usrmove is not particularly likely to get noticed by the people who might actually care and fix the damn apparently rather trivial thing. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/16/2012 12:13 AM, Reindl Harald wrote: i SURELY have made a notice in one of many bug-reports belonging to systemd last year I don't recall seeing it and I am cc'ed in all systemd bug reports and also, individual bugs require individual bug reports. Not merely a note in another bug report which makes it harder to keep track of bugs and mark them as fixed. Do file seperate bug reports from now on. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/15/2012 09:45 AM, Jóhann B. Guðmundsson wrote: Experienced admins dont use service iptables blah anyway ( they use iptables commands directly ) so it hardly matters to them documentation should however be updated for those that actually use service iptables blah to point this out so you should file a DOC bug for it. Actually, many experienced users directly create and put their rules file wherever the iptables service reads it from (historically it is /etc/sysconfig/iptables). Not sure if that has changed - if not JBG is essentially right For those still using iptables command instead, to install the rules in the kernel one at a time, they can then use the iptables-save command to create rules file from already running firewall. But, note that installing rules into the kernel via iptables command one rule at a time is 2-3 orders of magnitude slower than creating the rules file and installing all the rules in one shot. Either way, all you need to do is put them where the iptables service expects to read them from when its started - I would think - all it does it invoke iptables-restore on the rules file - or at least thats the way it used to work :-) gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Params-Coerce] Spec clean-up
commit 0de31b14fc7cb86fd0c48b9b4a0faa7e89aae4c5
Author: Paul Howarth p...@city-fan.org
Date: Wed Feb 15 19:15:38 2012 +
Spec clean-up
- Drop redundant perl and perl(ExtUtils::AutoInstall) buildreqs
- BR: perl(Carp), perl(Scalar::Util) ≥ 1.11, perl(Test::More)
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Set AUTOMATED_TESTING=1 to enable Pod test
- Use search.cpan.org source URL
- Fix typo in %description
- Make %files list more explicit
- Don't use macros for commands
- Use tabs
.gitignore |2 +-
perl-Params-Coerce.spec | 85 +-
2 files changed, 47 insertions(+), 40 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index dc55301..787584d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Params-Coerce-0.14.tar.gz
+/Params-Coerce-[0-9.]*.tar.gz
diff --git a/perl-Params-Coerce.spec b/perl-Params-Coerce.spec
index 4277958..08da327 100644
--- a/perl-Params-Coerce.spec
+++ b/perl-Params-Coerce.spec
@@ -1,47 +1,42 @@
-Name: perl-Params-Coerce
-Version:0.14
-Release:10%{?dist}
-Summary:Allows your classes to do coercion of parameters
-License:GPL+ or Artistic
-Group: Development/Libraries
-URL:http://search.cpan.org/dist/Params-Coerce/
-Source0:
http://www.cpan.org/authors/id/A/AD/ADAMK/Params-Coerce-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildArch: noarch
-
-BuildRequires: perl = 0:5.005
-BuildRequires: perl(Params::Util) = 0.05
-BuildRequires: perl(ExtUtils::AutoInstall) = 0.49, perl(Test::Pod) = 1.00
-
-# cpanspec autogenerated requires...
-#Requires: perl(Params::Util) = 0.05
-
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Name: perl-Params-Coerce
+Version: 0.14
+Release: 11%{?dist}
+Summary: Allows your classes to do coercion of parameters
+License: GPL+ or Artistic
+Group: Development/Libraries
+URL: http://search.cpan.org/dist/Params-Coerce/
+Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/Params-Coerce-%{version}.tar.gz
+BuildArch: noarch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Params::Util) = 0.05
+BuildRequires: perl(Scalar::Util) = 1.11
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod) = 1.00
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
A big part of good API design is that we should be able to be flexible in
the ways that we take parameters. Params::Coerce attempts to encourage this,
by making it easier to take a variety of different arguments, while adding
-negligable additional complexity to your code.
+negligible additional complexity to your code.
%prep
%setup -q -n Params-Coerce-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
-
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} %{buildroot}/*
+find %{buildroot} -depth -type d -exec rmdir {} \; 2/dev/null
+%{_fixperms} %{buildroot}
%check
-make test
+make test AUTOMATED_TESTING=1
%clean
rm -rf %{buildroot}
@@ -49,10 +44,22 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes LICENSE README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Params/
+%{_mandir}/man3/Params::Coerce.3pm*
%changelog
+* Wed Feb 15 2012 Paul Howarth p...@city-fan.org - 0.14-11
+- Spec clean-up:
+ - Drop redundant perl and perl(ExtUtils::AutoInstall) buildreqs
+ - BR: perl(Carp), perl(Scalar::Util) ≥ 1.11, perl(Test::More)
+ - Use DESTDIR rather than PERL_INSTALL_ROOT
+ - Set AUTOMATED_TESTING=1 to enable Pod test
+ - Use search.cpan.org source URL
+ - Fix typo in %%description
+ - Make %%files list more explicit
+ - Don't use macros for commands
+ - Use tabs
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.14-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
@@ -63,13 +70,13 @@ rm -rf %{buildroot}
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Tue Dec 21 2010 Marcela Maslanova mmasl...@redhat.com - 0.14-7
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 0.14-6
- Mass rebuild with perl-5.12.0
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.14-5
-- rebuild against perl 5.10.1
+- Rebuild against perl 5.10.1
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.14-4
- Rebuilt
[perl-Params-Coerce/f17] Spec clean-up
Summary of changes: 0de31b1... Spec clean-up (*) (*) 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
Re: service iptables save, systemctl, and unhelpful error messages
Am 15.02.2012 20:01, schrieb Genes MailLists: On 02/15/2012 09:45 AM, Jóhann B. Guðmundsson wrote: Experienced admins dont use service iptables blah anyway ( they use iptables commands directly ) so it hardly matters to them documentation should however be updated for those that actually use service iptables blah to point this out so you should file a DOC bug for it. Actually, many experienced users directly create and put their rules file wherever the iptables service reads it from (historically it is /etc/sysconfig/iptables). Not sure if that has changed - if not JBG is essentially right For those still using iptables command instead, to install the rules in the kernel one at a time, they can then use the iptables-save command to create rules file from already running firewall. But, note that installing rules into the kernel via iptables command one rule at a time is 2-3 orders of magnitude slower than creating the rules file and installing all the rules in one shot. thats right, but if you have any error in your rules you get a problem because in the worst no firewall at all is active dooing it with a shell-script results only in failing one rule with a error-message and apply the other ones, timing is usually not the problem if you don't have thousands of rules signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 07:45:41PM +0100, Reindl Harald wrote: does not matter because bash is the default shell and transitions have to be targeted for defaults and any developer of core-components has to use system defaults for his testings I'm sorry, it's clear at this point that you have expectations of our workflow that aren't terribly well aligned with those of the developers. I'd suggest that you'll spend much less of your time angry if you migrate to a distribution that's more receptive to your preferences. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Params-Coerce] Created tag perl-Params-Coerce-0.14-11.fc17
The lightweight tag 'perl-Params-Coerce-0.14-11.fc17' was created pointing to: 0de31b1... Spec clean-up -- 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-Params-Coerce/el4] (13 commits) ...Merge branch 'master' into el4
Summary of changes: b51bfac... new perl (*) b7986ca... - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass (*) 56159d5... - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass (*) 15de7d0... Fix typo that causes a failure to update the common directo (*) 6e27e84... - rebuild against perl 5.10.1 (*) cd858ef... - Mass rebuild with perl-5.12.0 (*) 0a87052... dist-git conversion (*) 87a219c... - 661697 rebuild for fixing problems with vendorach/lib (*) c5333ad... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) afeae2d... Perl mass rebuild (*) 55b9b50... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 0de31b1... Spec clean-up (*) e2bb3f3... Merge branch 'master' into el4 (*) 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-Params-Coerce/el4: 13/13] Merge branch 'master' into el4
commit e2bb3f3f8018617291016c8493d6007b8cc5efa2 Merge: 0818571 0de31b1 Author: Paul Howarth p...@city-fan.org Date: Wed Feb 15 19:36:21 2012 + Merge branch 'master' into el4 Conflicts: .gitignore .gitignore |2 +- perl-Params-Coerce.spec | 104 +++ 2 files changed, 70 insertions(+), 36 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
[Test-Announce] Fedora 17 Alpha RC1 is not released. Definitely, absolutely not.
Some of you who are just too darn nosy for your own business may have noticed a directory called 17-Alpha.RC1/ here: http://dl.fedoraproject.org/pub/alt/stage/ Now, if you're some kind of trouble-making, commie, tin foil hatted conspiracist, you might even think that this might be Fedora 17 Alpha RC1. This is both laughably naive and treasonous! Purge such thoughts from your mind immediately. Now. I'm warning you. My friends at Google will let me know if you haven't. Any images you may find if you were to take the extremely inadvisable, and indeed criminally indictable, step of entering the above directory are certainly not some kind of Alpha RC1 images which turn out to contain a serious bug[1] that was discovered part-way through the compose process, but are otherwise mostly installable and testable. No. They're full of lead, mercury, plutonium and other highly toxic substances. Don't touch them - you'll die in agony right after we arrest you. Really. It's for your own good. In a move that is *entirely* coincidental to all of the above, it just so happens that the release engineering team will soon be composing some builds that will be named Fedora 17 Alpha RC2. For entirely legitimate reasons which are certainly not at all to do with anything mentioned above, but which I can't tell you about for reasons of security. Ahem. These images will likely show up in a directory called http://dl.fedoraproject.org/pub/alt/stage/17-Alpha.RC2/ when they're done, but if you know what's good for you, you won't go sticking your grubby little fingers in it until we tell you to. [1] http://bugzilla.redhat.com/show_bug.cgi?id=790639 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ceph in Rawhide and F17 broken?
In F17 and Rawhide, I'm getting this error in root.log: DEBUG util.py:257: Error: Package: ceph-0.37-2.fc17.x86_64 (build) DEBUG util.py:257: Requires: libtcmalloc.so.0()(64bit) 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
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 8:30 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. I use bash completion all the time every single day - I guess I have become a corner case! -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Martin Langhoff wrote: Miroslav -- you haven't seen this work because the tasks are not all yet in. But the stateless feature handles a lot of it already. If you revert /usr to a snapshot without touching the rpmdb (in /var/lib/rpm), your system will be in a very inconsistent state. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 17 Alpha Release Candidate 2 (RC2) Available Now!
**IMPORTANT**: 17 Alpha RC1 was never officially announced - see https://lists.fedoraproject.org/pipermail/test-announce/2012-February/000371.html . I will post delta ISOs for both RC1-RC2 and TC2-RC2. As per the Fedora 17 schedule [1], Fedora 17 Alpha Release Candidate 2 (RC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5083 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 17 Alpha release candidate (RC) - live and traditional https://fedorahosted.org/rel-eng/ticket/5083 F17 Alpha Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752648 F17 Alpha Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=752653 [1] http://rbergero.fedorapeople.org/schedules/f-17/f-17-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Hi all, still require a few takers required for swaps. Ports from CCRMA and latest additions to the new LV2 audio stack. All very small packages CCRMA 788718 clalsadrv - An ALSA driver C++ library (most of the following depend on this one) 789255 ebumeter - Loudness measurement according to EBU-R128 789249 jkmeter - Horizontal or vertical bar-graph audio levels meter 789240 freqtweak - Realtime audio frequency spectral manipulation 789059 jaaa - JACK and ALSA Audio Analyzer 789055 japa - JACK and ALSA Perceptual Analyser 789385 ambdec- an ambiosonics decoder 789390 aeolus- aeolus organ synthesizer LV2 788717 lv2-ir- An LV2 impulse response reverb plugin 784605 lv2-instance-access - An LV2 audio plug-in extension (part of the spec) 783825 suil - A lightweight C library for loading and wrapping LV2 plugin UIs 789386 lilv - An LV2 Resource Description Framework Library My packages awaiting review can be found here [1] cheers Brendan [1] https://bugzilla.redhat.com/buglist.cgi?query_format=advancedclassification=Fedoraproduct=Fedoracomponent=Package%20Reviewbug_status=NEWemailreporter1=1emailtype1=substringemail1=brendan.jones.it%40gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/15/2012 03:45 PM, Jóhann B. Guðmundsson wrote: snip The service iptables save command is documented in a number of places and has been recommended to users for years. See, for example, the security guide: http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-Using_IPTables-Saving_and_Restoring_IPTables_Rules.html This breaking with the systemctl move is expected, but the unhelpful error message is a usability bug. Executing services iptables save should print This is no longer supported. Please execute /usr/libexec/iptables.init save (See: https://bugzilla.redhat.com/show_bug.cgi?id=748134 ) snip Somehow I doubt that any bugs will be fixed for this in either systemd ( since this is not systemd bug ) or iptables ( since Thomas is working on the new stuff and this does probably not climb high enough in his priority list anyway he probably would not fix this until all the bits for that are in place). So if you or others want this fixed I'm pretty sure either side ( most notably iptables ) would gladly review and accept patches should they be submitted. JBG I propose the following script in /etc/init.d/iptables #!/bin/sh # Please use systemctl to manage the iptables service # The old initscript is in /usr/libexec/iptables.init case $1 in panic|save) [ -c /dev/stderr ] \ echo This is no longer supported with systemd. \ Please use /usr/libexec/iptables.init $1 /dev/stderr exit 2 ;; *) [ -c /dev/stderr ] echo $Redirecting to \ /bin/systemctl $@ iptables.service /dev/stderr exec /bin/systemctl $@ iptables.service ;; esac The behavior of this script is the exactly the same as the current situation, except that the error message is much more userfriendly. The packaging guidelines say this If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins at http://fedoraproject.org/wiki/Packaging:Systemd Can wrapper scripts such as the above be made into an exception for this rule? I am happy Fedora can move forward as fast as it does, but the users have to move forward with us. Providing helpful error messages for deprecated behavior, that point in the right direction, could be a big help to make the transitions as easy as possible for our users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
this will not work since if a systemd-unit is present systemd no longer is interested in anything from /etc/init.d/ so there is no solution except patch systemd if iptables.service is called which will not happen because it would be unmaintainable ober the long and doing it for iptables would bring a lot of of other people complaining but why not XXX whateverservice too Am 16.02.2012 00:09, schrieb Emanuel Rietveld: On 02/15/2012 03:45 PM, Jóhann B. Guðmundsson wrote: snip The service iptables save command is documented in a number of places and has been recommended to users for years. See, for example, the security guide: http://docs.fedoraproject.org/en-US/Fedora/16/html/Security_Guide/sect-Security_Guide-Using_IPTables-Saving_and_Restoring_IPTables_Rules.html This breaking with the systemctl move is expected, but the unhelpful error message is a usability bug. Executing services iptables save should print This is no longer supported. Please execute /usr/libexec/iptables.init save (See: https://bugzilla.redhat.com/show_bug.cgi?id=748134 ) snip Somehow I doubt that any bugs will be fixed for this in either systemd ( since this is not systemd bug ) or iptables ( since Thomas is working on the new stuff and this does probably not climb high enough in his priority list anyway he probably would not fix this until all the bits for that are in place). So if you or others want this fixed I'm pretty sure either side ( most notably iptables ) would gladly review and accept patches should they be submitted. JBG I propose the following script in /etc/init.d/iptables #!/bin/sh # Please use systemctl to manage the iptables service # The old initscript is in /usr/libexec/iptables.init case $1 in panic|save) [ -c /dev/stderr ] \ echo This is no longer supported with systemd. \ Please use /usr/libexec/iptables.init $1 /dev/stderr exit 2 ;; *) [ -c /dev/stderr ] echo $Redirecting to \ /bin/systemctl $@ iptables.service /dev/stderr exec /bin/systemctl $@ iptables.service ;; esac The behavior of this script is the exactly the same as the current situation, except that the error message is much more userfriendly. The packaging guidelines say this If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins at http://fedoraproject.org/wiki/Packaging:Systemd Can wrapper scripts such as the above be made into an exception for this rule? I am happy Fedora can move forward as fast as it does, but the users have to move forward with us. Providing helpful error messages for deprecated behavior, that point in the right direction, could be a big help to make the transitions as easy as possible for our users. -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On Wednesday, February 15, 2012, 6:12:44 PM, Reindl wrote: this will not work since if a systemd-unit is present systemd no longer is interested in anything from /etc/init.d/ so there is no solution except patch systemd if iptables.service is called which will not happen because it would be unmaintainable ober the long and doing it for iptables would bring a lot of of other people complaining but why not XXX whateverservice too Johann has spent some significant time contributing to the last two Fedora releases, specifically a great deal of the actual conversion to systemd init. I'm sure that he and others can get something functioning rather quickly by working _with_ the systemd developers. Even better, my experience is that both Johann and Lennart are fully capable of coming up these answers without filling everyone's days with bile and crass negativity. Why not let them have a chance, instead of insisting on using every opportunity to attempt to advance your own twisted viewpoint? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 bootloader error
On Wed, 2012-02-15 at 11:41 -0600, Mike Chambers wrote: When trying to do test install against F17Alpha TC2, during partition layout, I get error below... you have not created a bootloader stage1 target device I have F16 installed on here, and even reformatted the disks to GPT before I installed F16. So using same partitions as installed like I always do should just work. So hoping this a install issue and not a me issue LOL. If you are using a GPT disklabel on a BIOS/non-EFI system with grub2 you will need a BIOS Boot partition of 1MB, preferably as the first partition on the disk. This error message sucks -- I know. It will hopefully be a bit clearer in time for beta. Dave Below are links to the error and my partition layout (the top harddrive is Win 7) Error... http://miketc.net/bootloader.jpg Partition Layout... http://miketc.net/partitions.jpg -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
Am 16.02.2012 00:48, schrieb Al Dunsmuir: On Wednesday, February 15, 2012, 6:12:44 PM, Reindl wrote: this will not work since if a systemd-unit is present systemd no longer is interested in anything from /etc/init.d/ so there is no solution except patch systemd if iptables.service is called which will not happen because it would be unmaintainable ober the long and doing it for iptables would bring a lot of of other people complaining but why not XXX whateverservice too Johann has spent some significant time contributing to the last two Fedora releases, specifically a great deal of the actual conversion to systemd init. I'm sure that he and others can get something functioning rather quickly by working _with_ the systemd developers. Even better, my experience is that both Johann and Lennart are fully capable of coming up these answers without filling everyone's days with bile and crass negativity. Why not let them have a chance, instead of insisting on using every opportunity to attempt to advance your own twisted viewpoint? what is your exactly problem here? well, wait their replies that they will not include all sorts of exceptions for random services in systemd because their target is holding systemd clean and compact to prvent the need of the next init-system switch in few years signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Apple will use LLVM
Apple move step by step to LLVM and stop to use gcc. The latest apple IDE (Xcode) will not ship gcc but llvm. https://developer.apple.com/technologies/tools/whats-new.html It will be great to know if llvm is ready to do same for several important linux package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 05:19 PM, mike cloaked wrote: On Wed, Feb 15, 2012 at 8:30 PM, Adam Williamsonawill...@redhat.com wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 bootloader error(s)
On Feb 15, 2012, at 10:41 AM, Mike Chambers wrote: When trying to do test install against F17Alpha TC2, during partition layout, I get error below... you have not created a bootloader stage1 target device anaconda-17.8-1.fc17.src.rpm pyanaconda/storage/__init__.py line 1250 errors.append(_(you have not created a bootloader stage1 target device)) If this only occurs on GPT disks, which I'm pretty sure is true, then a more elucidative message would be: errors.append(_(You have not specified a BIOS Boot partition.)) The current message is obscure, and consistently results in questions on forums. For consistency, I suggest the following lines be changed: line 1165 You have not defined a root partition (/), to You have not specified a root partition (/), line 1259 You have not created a bootable partition. to You have not specified a bootable partition. The four you have not partition related errors in this script would then read: You have not specified a swap partition. You have not specified a root partition (/), You have not specified a BIOS boot partition You have not specified a bootable partition. Not sure where the You have not specified an EFI System partition. is located... Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ceph in Rawhide and F17 broken?
Richard W.M. Jones rjones at redhat.com writes: In F17 and Rawhide, I'm getting this error in root.log: DEBUG util.py:257: Error: Package: ceph-0.37-2.fc17.x86_64 (build) DEBUG util.py:257: Requires: libtcmalloc.so.0()(64bit) This causes 17 Alpha RC2 to fail repoclosure, so it won't be Alpha Gold. https://bugzilla.redhat.com/show_bug.cgi?id=791032 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On Wednesday, February 15, 2012, 7:15:13 PM, Reindl wrote: Am 16.02.2012 00:48, schrieb Al Dunsmuir: On Wednesday, February 15, 2012, 6:12:44 PM, Reindl wrote: this will not work since if a systemd-unit is present systemd no longer is interested in anything from /etc/init.d/ so there is no solution except patch systemd if iptables.service is called which will not happen because it would be unmaintainable ober the long and doing it for iptables would bring a lot of of other people complaining but why not XXX whateverservice too Johann has spent some significant time contributing to the last two Fedora releases, specifically a great deal of the actual conversion to systemd init. I'm sure that he and others can get something functioning rather quickly by working _with_ the systemd developers. Even better, my experience is that both Johann and Lennart are fully capable of coming up these answers without filling everyone's days with bile and crass negativity. Why not let them have a chance, instead of insisting on using every opportunity to attempt to advance your own twisted viewpoint? what is your exactly problem here? well, wait their replies that they will not include all sorts of exceptions for random services in systemd because their target is holding systemd clean and compact to prvent the need of the next init-system switch in few years Q.E.D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 bootloader error(s)
On Wed, 2012-02-15 at 17:24 -0700, Chris Murphy wrote: On Feb 15, 2012, at 10:41 AM, Mike Chambers wrote: When trying to do test install against F17Alpha TC2, during partition layout, I get error below... you have not created a bootloader stage1 target device anaconda-17.8-1.fc17.src.rpm pyanaconda/storage/__init__.py line 1250 errors.append(_(you have not created a bootloader stage1 target device)) If this only occurs on GPT disks, which I'm pretty sure is true, then a more elucidative message would be: I don't think that's necessarily the case. It is possible to wind up without something anaconda considers a stage1 target device in other ways, I believe. But IMBW. In general - please send anaconda requests / bugs to Bugzilla or to the anaconda-devel mailing list, please - thanks! https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ceph in Rawhide and F17 broken?
On Wed, 2012-02-15 at 16:44 -0800, Adam Williamson wrote: On Wed, 2012-02-15 at 21:59 +, Richard W.M. Jones wrote: In F17 and Rawhide, I'm getting this error in root.log: DEBUG util.py:257: Error: Package: ceph-0.37-2.fc17.x86_64 (build) DEBUG util.py:257: Requires: libtcmalloc.so.0()(64bit) Well, the problem isn't ceph itself exactly - that dep is provided by google-perftools, which seems to have been retired. I can't find a retirement notice for it. Ah. git log shows: commit 549559068142be7d7f98022df24528be5d3bfa5e Author: Tom Callaway s...@fedoraproject.org Date: Tue Feb 14 16:03:02 2012 -0500 renamed to gperftools But that's post-freeze, so gperftools hasn't been pushed stable; so now gnome-perftools is 'dead' so won't be pulled into composes, but gperftools is not pushed stable and *also* won't be pulled into composes. we either force gnome-perftools into the images or just push gperftools stable, I guess. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Wed, Feb 15, 2012 at 7:22 PM, jonathan bioinfornat...@gmail.com wrote: Apple move step by step to LLVM and stop to use gcc. The latest apple IDE (Xcode) will not ship gcc but llvm. https://developer.apple.com/technologies/tools/whats-new.html It will be great to know if llvm is ready to do same for several important linux package. Do I take that to mean you're working on building a variety of packages with LLVM? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/15/2012 11:09 PM, Emanuel Rietveld wrote: I propose the following script in /etc/init.d/iptables I propose you file a BUG against IPTABLES and put your proposal into that bug report then wait and see what Thomas has to say. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ceph in Rawhide and F17 broken?
On Wed, 2012-02-15 at 21:59 +, Richard W.M. Jones wrote: In F17 and Rawhide, I'm getting this error in root.log: DEBUG util.py:257: Error: Package: ceph-0.37-2.fc17.x86_64 (build) DEBUG util.py:257: Requires: libtcmalloc.so.0()(64bit) Well, the problem isn't ceph itself exactly - that dep is provided by google-perftools, which seems to have been retired. I can't find a retirement notice for it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 15/02/12 01:30 PM, Adam Williamson wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. Right. And thanks to this thread I just learned what broke bash completion for me after fresh install of F16: 'rpm -e bash-completion' fixed bash for me :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On 02/16/2012 02:06 AM, Jóhann B. Guðmundsson wrote: On 02/15/2012 11:09 PM, Emanuel Rietveld wrote: I propose the following script in /etc/init.d/iptables I propose you file a BUG against IPTABLES and put your proposal into that bug report then wait and see what Thomas has to say. JBG I did so. Thomas pointed out that complying with my request would be against the packaging guidelines and suggested this needs to be discussed at best on Fedora-devel. The addition of 'at best' in there leads me to believe that he is not especially interested in my proposal, but may be willing to add the wrapper script if I get wider support for it and/or get the packaging guidelines changed. Presumably, getting the packaging guidelines changed involves a lot of people's attention - people who are generally already very busy, and do not really want to spend precious brain cycles and time on what is ultimately a minor improvement visible to only a small number of people. Oh well, at least I tried. Thanks Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 2/15/12 7:22 PM, jonathan wrote: Apple move step by step to LLVM and stop to use gcc. The latest apple IDE (Xcode) will not ship gcc but llvm. https://developer.apple.com/technologies/tools/whats-new.html It will be great to know if llvm is ready to do same for several important linux package. And? - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/16/2012 07:46 AM, Dariusz J. Garbowski wrote: Right. And thanks to this thread I just learned what broke bash completion for me after fresh install of F16: 'rpm -e bash-completion' fixed bash for me :-) As a quick note; you should probably use yum remove instead of rpm -e because yumdb will be consistent if you stick to yum and that allows rollback etc. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 15 February 2012 17:23, Steve Clark scl...@netwolves.com wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: On Wed, Feb 15, 2012 at 8:30 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. Before getting too far down this rabbit hole... realize there are two bash-completions 1) The built in one. I type ls chtab and bash goes to look at things and either completes or gives me a list of possible completions. 2) The bash-completions add-on. Which does all kinds of wonderful things which when they work is really nice.. it will autocomplete hostnames if you type ssh ftab, it will autocomplete depending on the command you typed the most obvious items... etc etc. It also can really really slow you down at times or cause issues with just normal bash completion. A bad autocomplete can cause you to sit 3-4 minutes as DNS or other things time out. The people talking in this conversation are talking about 2. The type you are talking about is 1. Completely different. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. You may have been working with them since the earliy nineties, but the feature was only introduced in 2.04 in 2000. Programmable completion is fairly modern compared to the rest of bash... -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Thu, Feb 16, 2012 at 01:22:51AM +0100, jonathan wrote: Apple move step by step to LLVM and stop to use gcc. The latest apple IDE (Xcode) will not ship gcc but llvm. https://developer.apple.com/technologies/tools/whats-new.html It will be great to know if llvm is ready to do same for several important linux package. We're already building at least one package (hfsplus-tools) with llvm because it relies on non-standard C extensions that gcc doesn't support, and I believe the current software rasteriser in mesa depends on it. In terms of it being the general compiler - it needs to work on all the architectures we care about, it needs to have a level of maintenance in Fedora at least as good as gcc, it needs to build better code than gcc and (most importantly) it needs somebody to actually take responsibility for proving all of that and making the transition happen. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-17 Branched report: 20120213 changes
On Mon, 2012-02-13 at 18:07 -0800, Adam Williamson wrote: On Mon, 2012-02-13 at 19:36 +, Sérgio Basto wrote: On Mon, 2012-02-13 at 10:33 +, Branched Report wrote: Hi, on http://kojipkgs.fedoraproject.org/mash/branched/i386/os/images/ we got boot.iso on http://kojipkgs.fedoraproject.org/mash/branched/x86_64/os/images/ we got macboot.img and efiboot.img what happened to boot.iso ? . To start one vm, I need it . There's a thread from a couple of days ago discussing it: the compose is failing. It's not usually a great idea to rely on the automated daily composes working, they can often fail for one reason or another. If you just need a boot.iso to do an install with, go with the last pre-release (candidate) build, which at present is Alpha TC2 - http://dl.fedoraproject.org/pub/alt/stage/17-Alpha.TC2/ . yeah, I just read this now, but this staging images, we have a new one, http://dl.fedoraproject.org/pub/alt/stage/17-Alpha.RC2/ (15-Feb-2012 22:08 ) are based on daily composes ? isn't it ? I built my own boot.iso for x86_64 (based on compose) between 17-Alpha.RC2 and 17-Alpha.TC2 :), and I'm quite surprised that installed very well, the default gnome-desktop on VirtualBox. Don't found any problem of rendering. I to be honest, I think I will try again and install kde , which is the desktop that I currently use. Many thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-17 Branched report: 20120213 changes
On Thu, 2012-02-16 at 04:00 +, Sérgio Basto wrote: On Mon, 2012-02-13 at 18:07 -0800, Adam Williamson wrote: On Mon, 2012-02-13 at 19:36 +, Sérgio Basto wrote: On Mon, 2012-02-13 at 10:33 +, Branched Report wrote: Hi, on http://kojipkgs.fedoraproject.org/mash/branched/i386/os/images/ we got boot.iso on http://kojipkgs.fedoraproject.org/mash/branched/x86_64/os/images/ we got macboot.img and efiboot.img what happened to boot.iso ? . To start one vm, I need it . There's a thread from a couple of days ago discussing it: the compose is failing. It's not usually a great idea to rely on the automated daily composes working, they can often fail for one reason or another. If you just need a boot.iso to do an install with, go with the last pre-release (candidate) build, which at present is Alpha TC2 - http://dl.fedoraproject.org/pub/alt/stage/17-Alpha.TC2/ . yeah, I just read this now, but this staging images, we have a new one, http://dl.fedoraproject.org/pub/alt/stage/17-Alpha.RC2/ (15-Feb-2012 22:08 ) are based on daily composes ? isn't it ? I built my own boot.iso for x86_64 (based on compose) between 17-Alpha.RC2 and 17-Alpha.TC2 :), and I'm quite surprised that installed very well, the default gnome-desktop on VirtualBox. Don't found any problem of rendering. I to be honest, I think I will try again and install kde , which is the desktop that I currently use. Well, they ultimately use the packages that are in the repos, of course. There are some differences, though. The spins are done 'by hand' by the releng team, and we cherry-pick specific packages that aren't yet in the stable repos into the composes via the blocker/NTH bug processes. But sure, if you spin your own boot.iso and it happens to work well, by all means, use it. Nothing will explode. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-17 Branched report: 20120213 changes
On Wed, 2012-02-15 at 20:16 -0800, Adam Williamson wrote: But sure, if you spin your own boot.iso and it happens to work well, by all means, use it. Nothing will explode. :) I just built one because don't found any, in next test I will use one from Testings , of course, to help on tests. Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 02/15/2012 10:38 PM, Matthew Garrett wrote: We're already building at least one package (hfsplus-tools) with llvm because it relies on non-standard C extensions that gcc doesn't support, and I believe the current software rasteriser in mesa depends on it. In terms of it being the general compiler - it needs to work on all the architectures we care about, it needs to have a level of maintenance in Fedora at least as good as gcc, it needs to build better code than gcc and (most importantly) it needs somebody to actually take responsibility for proving all of that and making the transition happen. Not to mention that the kernel devs use gcc to compile the kernel - and it most certainly puts a lot of pressure on the compiler. I suspect unless linus drops gcc as well, we'll at a minimum need to keep it to build the kernel itself. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 02/16/2012 10:08 AM, Genes MailLists wrote: Not to mention that the kernel devs use gcc to compile the kernel - and it most certainly puts a lot of pressure on the compiler. I suspect unless linus drops gcc as well, we'll at a minimum need to keep it to build the kernel itself. Not quite. LLVM can be used to build the kernel and what Linus does doesn't matter as much (kernel is important but only one component) as showing that Fedora on the whole will actually benefit from moving to LLVM. For that, LLVM has to so much better than GCC and someone has to do the work within Fedora to show that it is the case. FWIW, Red Hat is heavily invested in GCC and Apple has a strong control over LLVM. Considering the recent changes that Apple has been making to CUPS, I think it is more than a pure technical choice. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 15.02.2012 17:45, Jóhann B. Guðmundsson wrote: Thomas Woerner has been working on a more user friendly firewall solution for Fedora so firewall solution is in a bit of state of flux in Fedora at this point in time and explains why things are as they are. He was going to push this in at the same time as systemd as in Fedora F15 but due to various reasons he backed out of it at that time. ( but it is one of F17 features ) Experienced admins dont use service iptables blah anyway ( they use iptables commands directly ) so it hardly matters to them documentation should however be updated for those that actually use service iptables blah to point this out so you should file a DOC bug for it. Experienced admins use shorewall (http://www.shorewall.net/). Would be cool if this firewall implementation will be default in Fedora. - -- WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk88shsACgkQb3oGR6aVLpqd1gCfWrjkcDbAG1Jg7TEC/OY13ub2 lgUAnA3nnjFoTZdNgy8xf7UcjsxAippQ =MtEX -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Params-Coerce/el4] (8 commits) ...Merge branch 'master' into el6
Summary of changes: 482b132... Initialize branch EL-5 for perl-Params-Coerce (*) 5564a5b... Fix typo that causes a failure to update the common directo (*) b2269ee... Fix typo that causes a failure to update the common directo (*) 3eacb7a... Initialize branch EL-6 for perl-Params-Coerce (*) 27a51d6... dist-git conversion (*) fb1e3f2... dist-git conversion (*) e480d6a... Merge branch 'master' into el5 ee36e58... 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Coerce/el4: 7/8] Merge branch 'master' into el5
commit e480d6ad499648c884b40627cb63c67e09843897 Merge: 27a51d6 e2bb3f3 Author: Paul Howarth p...@city-fan.org Date: Wed Feb 15 23:50:41 2012 + Merge branch 'master' into el5 Conflicts: .gitignore .gitignore |2 +- perl-Params-Coerce.spec | 104 +++ 2 files changed, 70 insertions(+), 36 deletions(-) --- -- 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-Params-Coerce/el4: 8/8] Merge branch 'master' into el6
commit ee36e583635297f9bf14c419ba2bffbbd81fc965 Merge: fb1e3f2 e480d6a Author: Paul Howarth p...@city-fan.org Date: Wed Feb 15 23:52:11 2012 + Merge branch 'master' into el6 Conflicts: .gitignore .gitignore |2 +- perl-Params-Coerce.spec | 99 +- 2 files changed, 63 insertions(+), 38 deletions(-) --- -- 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-Params-Coerce/el5] (21 commits) ...Merge branch 'master' into el6
Summary of changes: 41f441c... Initialize branch EL-4 for perl-Params-Coerce (*) b51bfac... new perl (*) b7986ca... - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass (*) 56159d5... - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass (*) 15de7d0... Fix typo that causes a failure to update the common directo (*) ba27074... Fix typo that causes a failure to update the common directo (*) b2269ee... Fix typo that causes a failure to update the common directo (*) 6e27e84... - rebuild against perl 5.10.1 (*) cd858ef... - Mass rebuild with perl-5.12.0 (*) 3eacb7a... Initialize branch EL-6 for perl-Params-Coerce (*) 0818571... dist-git conversion (*) 0a87052... dist-git conversion (*) fb1e3f2... dist-git conversion (*) 87a219c... - 661697 rebuild for fixing problems with vendorach/lib (*) c5333ad... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) afeae2d... Perl mass rebuild (*) 55b9b50... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 0de31b1... Spec clean-up (*) e2bb3f3... Merge branch 'master' into el4 (*) e480d6a... Merge branch 'master' into el5 (*) ee36e58... 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Coerce/el6] (18 commits) ...Merge branch 'master' into el6
Summary of changes: 41f441c... Initialize branch EL-4 for perl-Params-Coerce (*) 482b132... Initialize branch EL-5 for perl-Params-Coerce (*) 15de7d0... Fix typo that causes a failure to update the common directo (*) ba27074... Fix typo that causes a failure to update the common directo (*) 5564a5b... Fix typo that causes a failure to update the common directo (*) 6e27e84... - rebuild against perl 5.10.1 (*) cd858ef... - Mass rebuild with perl-5.12.0 (*) 0818571... dist-git conversion (*) 27a51d6... dist-git conversion (*) 0a87052... dist-git conversion (*) 87a219c... - 661697 rebuild for fixing problems with vendorach/lib (*) c5333ad... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) afeae2d... Perl mass rebuild (*) 55b9b50... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 0de31b1... Spec clean-up (*) e2bb3f3... Merge branch 'master' into el4 (*) e480d6a... Merge branch 'master' into el5 (*) ee36e58... 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Coerce] (12 commits) ...Merge branch 'master' into el6
Summary of changes: 41f441c... Initialize branch EL-4 for perl-Params-Coerce (*) 482b132... Initialize branch EL-5 for perl-Params-Coerce (*) ba27074... Fix typo that causes a failure to update the common directo (*) 5564a5b... Fix typo that causes a failure to update the common directo (*) b2269ee... Fix typo that causes a failure to update the common directo (*) 3eacb7a... Initialize branch EL-6 for perl-Params-Coerce (*) 0818571... dist-git conversion (*) 27a51d6... dist-git conversion (*) fb1e3f2... dist-git conversion (*) e2bb3f3... Merge branch 'master' into el4 (*) e480d6a... Merge branch 'master' into el5 (*) ee36e58... 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Coerce] Created tag perl-Params-Coerce-0.14-11.el4
The lightweight tag 'perl-Params-Coerce-0.14-11.el4' was created pointing to: e2bb3f3... Merge branch 'master' into el4 -- 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-Params-Coerce] Created tag perl-Params-Coerce-0.14-11.el5
The lightweight tag 'perl-Params-Coerce-0.14-11.el5' was created pointing to: ee36e58... Merge branch 'master' into el6 -- 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-Params-Coerce] Created tag perl-Params-Coerce-0.14-11.el6
The lightweight tag 'perl-Params-Coerce-0.14-11.el6' was created pointing to: ee36e58... Merge branch 'master' into el6 -- 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 791078] New: perl-Config-IniFiles should require IO::Scalar
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: perl-Config-IniFiles should require IO::Scalar
https://bugzilla.redhat.com/show_bug.cgi?id=791078
Summary: perl-Config-IniFiles should require IO::Scalar
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: perl-Config-IniFiles
AssignedTo: tcall...@redhat.com
ReportedBy: boche...@fedoraproject.org
QAContact: extras...@fedoraproject.org
CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
It is possible to pass a reference to a variable containing the ini config
file to Config::IniFiles-new()
This feature requires IO::Scalar to be installed.
However, rpmbuild doesn't pick this dependency automatically.
Version-Release number of selected component (if applicable):
perl-Config-IniFiles-2.68-1.fc16.noarch
How reproducible:
Always
Steps to Reproduce:
1. yum install perl-Config-IniFiles
2. Run the following perl script:
-- test.pl --
use Config::IniFiles;
my $ini = [section]\nkey=value;
my $config = Config::IniFiles-new(-file=\$ini);
-
Actual results:
On a system without perl-IO-stringy installed, I get:
[mathieu@localhost ~]$ perl test.pl
Failed to open SCALAR(0x1034c48): No such file or directory at test.pl line 5
This means that the package is missing a requires on perl(IO::Scalar)
Expected results:
The script should not fail, because perl-IO-stringy would be installed.
Additional info:
The problem is present both in Fedora 16 and EPEL 6, probably in other releases
as well.
Note that the requirement should probably be picked up by rpmbuild, my guess is
that rpmbuild doesn't like the way IO::Scalar is used in Config::IniFiles:
-- lib/Config/IniFiles.pm:2265 --
if (ref($thing) eq SCALAR) {
if (eval { require IO::Scalar; $IO::Scalar::VERSION = 2.109; }) {
return IO::Scalar-new($thing);
} else {
warn SCALAR reference as file descriptor requires
IO::stringy .
v2.109 or later if ($^W);
return;
}
}
-
Perhaps it could be added to the spec file in the meantime?
--
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 791078] perl-Config-IniFiles should require IO::Scalar
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=791078 Mathieu Bridon boche...@fedoraproject.org changed: What|Removed |Added Version|rawhide |16 --- Comment #1 from Mathieu Bridon boche...@fedoraproject.org 2012-02-15 23:51:55 EST --- I didn't actually verify the bug in Rawhide, so I'm setting the Version to Fedora 16. Sorry for the extra email, I should have paid more attention before submitting the 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
