Re: /var/run/reboot-required

[Ruben Kerkhof]

On Wed, Jul 27, 2016 at 5:42 PM, Ruben Kerkhof <ru...@rubenkerkhof.com> wrote:
> On Wed, Jul 27, 2016 at 5:17 PM, John Florian <john.flor...@dart.biz> wrote:
>> How can this metadata be leveraged with automation?  I have the dnf
>> tracer plugin which I believe is using this metadata to tell me when I
>> need to reboot, but what if I have this in a cron job?
>
> The docs at http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html
> say it calls tracer directly, so it shouldn't be too hard to do the
> same thing from cron.

I also just learned of dnf updateinfo. Unfortunately I didn't get it
to show the reboot recommendation.

$ dnf updateinfo list updates security
Last metadata expiration check: 0:30:23 ago on Wed Jul 27 21:18:51 2016.
FEDORA-2016-615f3bf06e security gd-2.2.3-1.fc24.x86_64
FEDORA-2016-9a16b2e14e security kernel-4.6.4-301.fc24.x86_64
FEDORA-2016-42514bee97 security libidn-1.33-1.fc24.x86_64
FEDORA-2016-42514bee97 security libidn-debuginfo-1.33-1.fc24.x86_64
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: /var/run/reboot-required

[Ruben Kerkhof]

On Wed, Jul 27, 2016 at 8:56 PM, Josh Boyer  wrote:
> How does the reboot-required package get installed in the first place?
>  I was assuming something during the update process would install it,
> which means something has to Require it or install it in some manner.

I haven't figured that part out yet, one reason I started this discussion.
For now I think leaving it up to the adminstrator is best, just like
unattended-upgrades in Debian.

>
> (As an aside, I've never heard of /etc/kerne/postinst.d until now.  I
> have no idea if anything even looks in there in Fedora.)

Neither did I. /usr/sbin/new-kernel-pkg is the one executing the
scripts in there.
At one point it looks like mkinitrd owned that directory:
https://bugzilla.redhat.com/44
dracut drops scripts in there, but it doesn't own it either.

>
> Also, I think "recommended" is really the appropriate terminology
> here.  There is very little that _requires_ a reboot to be done after
> it is installed.

 It's that little part I care very much about ;)
>>>
>>> For what purpose though?  Do you care because you want to make sure
>>> your software is running with all security fixes?  Do you care because
>>> you want to simply be running the latest and greatest at all times?
>>
>> Primarily security fixes.
>
> OK.  It might be beneficial to look at the update metadata anyway in
> that case, to see what is labeled as a security fix.

I will do that.

>
>>> Checking the update metadata could probably be done in dnf itself if
>>> it isn't already.  I believe Software already looks at this flag if
>>> you are using that to apply your updates.  If you simply want to
>>> always be running the latest, then 'dnf update && reboot' solves that
>>> need.
>>
>> In the case I've been thinking of the updates are done by us, or
>> puppet, but the reboots are scheduled
>> by our customers at a time which suits them. We don't always know if
>> they've rebooted already
>> and checking /var/run/reboot-required would be an easy way to remind them.
>>
>> For Debian / Ubuntu motd also lets them know as soon as they login, which 
>> helps.
>
> I think what you're trying to accomplish is certainly possible.  I'm
> not sure the exact implementation of having it done as a separate
> package is the best method, but it's a possibility I guess.

I'll get started on it, and I'm certain other people will prove me wrong ;)

Thank you for your comments,

Ruben
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: /var/run/reboot-required

[Ruben Kerkhof]

On Wed, Jul 27, 2016 at 6:58 PM, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> On Wed, Jul 27, 2016 at 11:39 AM, Ruben Kerkhof <ru...@rubenkerkhof.com> 
> wrote:
>> On Wed, Jul 27, 2016 at 2:16 PM, Josh Boyer <jwbo...@fedoraproject.org> 
>> wrote:
>>> Why would you want this to be something packaged?  We have 'reboot
>>> recommended' in our bodhi update metadata, and that seems like a much
>>> better place for it.
>>
>> My guess is that 'reboot recommended' is true for each kernel update.
>
> Yes, of course.  But it isn't required.

You're right of course, we can't require anything from our users, only
recommend they do something.

>
>> What I'd like to know is if the system is booted into the latest
>> kernel, and I need that
>> information in an easy to consume way.
>
> That's entirely separate from 'reboot recommended' or
> 'reboot-required'.  There are many cases where a kernel update is
> pushed out but you might not have any reason to actually boot into it.
> I quite frequently skip non-security kernel updates if nothing else is
> actually wrong.  We fix bugs in a large number of places, and not all
> of those places are things your machine might care about.

My understanding of /var/run/reboot-required in Debian is simply of
being an indicator
that there's a different kernel installed from the current one, and
that you need to reboot for it to have effect.

You're still free to not look at this file and skip kernel updates of course.
I'm assuming (perhaps wrongly) that a majority of users just run the
latest and greatest.

>
>> Unless I misunderstand what you're proposing, in that case, can you
>> please elaborate?
>
> I can try.
>
> If all you want to know is whether the most recently installed kernel
> is running, then you can do that via a script that compares uname to
> the output of an RPM query on the kernel package.  That's fairly
> trivial to do.

I have something mostly working
(http://paste.fedoraproject.org/396520/69643975/ for those interested)

> (I explicitly say 'most recently installed' because the kernel is odd
> in that multiple kernels are installed and the most recently installed
> kernel may actually not be the _newest_ kernel.)

I hadn't thought of that, thanks.

>
> However, if you are looking to know whether something (kernel or
> otherwise) recommends rebooting, then you would want to look at the
> update metadata.  Grub, openssl, glibc, etc can all recommend
> rebooting for a variety of reasons.
>
>>> Otherwise, you run into cases where multiple
>>> packages want to write/own the file, etc.
>>
>> Hence my proposal for a reboot-required package which is the owner and
>> writes the file.
>
> Sure, but that is a lot of hassle that seems unnecessary.  Also,
> because recommend vs. required are different, I would not be willing
> to e.g. modify the kernel package to Require: reboot-required.  It
> simply isn't an accurate reflection of every possibility.  Nor would I
> be willing to add it in cases where it is required but remove it other
> times.  That's a lot of spec file munging and it would get annoying.

If the reboot-required package just drops a script in /etc/kernel/postinst.d,
the kernel package doesn't need to Require: anything, or am I missing something?

>
>>> Also, I think "recommended" is really the appropriate terminology
>>> here.  There is very little that _requires_ a reboot to be done after
>>> it is installed.
>>
>> It's that little part I care very much about ;)
>
> For what purpose though?  Do you care because you want to make sure
> your software is running with all security fixes?  Do you care because
> you want to simply be running the latest and greatest at all times?

Primarily security fixes.

>
> Checking the update metadata could probably be done in dnf itself if
> it isn't already.  I believe Software already looks at this flag if
> you are using that to apply your updates.  If you simply want to
> always be running the latest, then 'dnf update && reboot' solves that
> need.

In the case I've been thinking of the updates are done by us, or
puppet, but the reboots are scheduled
by our customers at a time which suits them. We don't always know if
they've rebooted already
and checking /var/run/reboot-required would be an easy way to remind them.

For Debian / Ubuntu motd also lets them know as soon as they login, which helps.

>
> josh
> --

Kind regards,

Ruben
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: /var/run/reboot-required

[Ruben Kerkhof]

On Wed, Jul 27, 2016 at 5:17 PM, John Florian  wrote:
> How can this metadata be leveraged with automation?  I have the dnf
> tracer plugin which I believe is using this metadata to tell me when I
> need to reboot, but what if I have this in a cron job?

The docs at http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html
say it calls tracer directly, so it shouldn't be too hard to do the
same thing from cron.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: /var/run/reboot-required

[Ruben Kerkhof]

On Wed, Jul 27, 2016 at 2:16 PM, Josh Boyer  wrote:
> Why would you want this to be something packaged?  We have 'reboot
> recommended' in our bodhi update metadata, and that seems like a much
> better place for it.

My guess is that 'reboot recommended' is true for each kernel update.
What I'd like to know is if the system is booted into the latest
kernel, and I need that
information in an easy to consume way.

Unless I misunderstand what you're proposing, in that case, can you
please elaborate?

> Otherwise, you run into cases where multiple
> packages want to write/own the file, etc.

Hence my proposal for a reboot-required package which is the owner and
writes the file.

> Also, I think "recommended" is really the appropriate terminology
> here.  There is very little that _requires_ a reboot to be done after
> it is installed.

It's that little part I care very much about ;)

>
> josh

Kind regards,

Ruben
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

/var/run/reboot-required

[Ruben Kerkhof]

Hi all,

Debian and Ubuntu have a package called unattended-upgrades.
We have yum-cron which does something similar.

One difference though is that unattended-upgrade drops a script in
/etc/kernel/postinst.d/unattended-upgrades, which does this:

#!/bin/sh
if [ -d /var/run ]; then
   touch /var/run/reboot-required
fi

Using Ansible, I can quickly see which servers need a reboot due to a
kernel upgrade.

I think this would be nice to have in Fedora as well, the only
question is which package
should provide it.

We have /etc/kernel/postinst.d too, but this directory is currently unowned.
So if I'd wanted to add this to some package, which one should it be
and what should it depend on?

Alternatively, I could create a new package, let's call it 'reboot-required'.

Thoughts?

Kind regards,

Ruben Kerkhof
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: zfs_arc plugin for collectd disabled by default

[Ruben Kerkhof]

On Sun, Jul 24, 2016 at 5:43 AM, Kevin Fenzi <ke...@scrye.com> wrote:
> On Sat, 23 Jul 2016 23:58:54 -
> "Michael Woon" <w...@mit.edu> wrote:
>
>> Hello devel,
>>
>> Hello ruben, fab, mhlavink, kevin, jskarvad, xaeth,
>>
>>
>> I have a quick question about the collectd packages for Fedora /
>> Epel. By default, the spec has the zfs_arc plugin disabled and
>> collectd builds without it. Is this intentional?
>
> No. It's enabled in rawhide as of:
>
> * Sat Feb 27 2016 Ruben Kerkhof <ru...@rubenkerkhof.com> - 5.5.1-5
> - Enable zfs_arc plugin now that it supports ZoL.
>
>> I can rebuild the rpm fine with the option enabled, so it doesn't
>> seem there are any missing dependencies or things that would
>> otherwise stop this from working properly. Perhaps it's simply
>> un-used or un-demanded for most users, and therefore left out by
>> default?
>
> It was left out before because it didn't support ZoL/wasn't requested.
>>
>> I'm using collectd to monitor a zfs-based storage server, so that's
>> the root of this question.
>
> If you need it in specific releases, could you file a bug and ask for
> those and we can see about updating those.
>
> kevin

It should just work just fine on EPEL, but it was indeed never requested.
I tend to be somewhat conservative with which plugins I add to EPEL since
we need to support them for a long time.

So what Kevin said, please file an issue and I'll look into it.

Kind regards,

Ruben
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: libsodium soname bump in rawhide/F24

[Ruben Kerkhof]

On Mon, Mar 7, 2016 at 12:34 PM, Remi Collet  wrote:
> Hi

Hi Remi
>
> I'm upgrading libsodium from 1.0.5 (soname 13) to 1.0.8 (soname 18)
>
> I will also rebuild dependent packages:
>
> - fastd
> - usbguard
> - zeromq

I'll rebuild dnsdist which also depends on libsodium.

Kind regards,

Ruben
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: glibc in Fedora rawhide now split by langpacks.

[Ruben Kerkhof]

On Fri, Feb 26, 2016 at 10:47 AM, Carlos O'Donell <car...@redhat.com> wrote:
> The glibc in Fedora rawhide and F24 is now split by
> language packs. We have over 180 supported languages
> in glibc, and those have been split into langpacks
> for transparent install and support via dnf. This
> greatly reduces the size of a glibc install from 130MB
> down to a couple of megs. It drops support for the hacky
> %_inst_langs feature, and relies entirely on langpack
> support (it was one or the other).
>
> Thanks to Mike Fabian for the great work!

I'm now seeing this in mock / koji builds:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

For example 
https://kojipkgs.fedoraproject.org//packages/collectd/5.5.1/4.fc25/data/logs/armv7hl/build.log

It looks harmless, but could this be related to this change and is
this already a known issue?

Kind regards,

Ruben Kerkhof
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Orphaning packages

[Ruben Kerkhof]

Hi all,

Due to lack of time I'm orphaning the following packages:

- pyutil
- python-zfec
- python-zbase32
- python-setuptools_trial
- python-foolscap
- pycryptopp


They're pretty low maintenance, please pick them up if you want.

Kind regards,

Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaning some packages

[Ruben Kerkhof]

On Sun, Apr 1, 2012 at 18:00, Kevin Fenzi ke...@scrye.com wrote:
 On Sun, 1 Apr 2012 14:55:56 +0200
 Ruben Kerkhof ru...@rubenkerkhof.com wrote:

 Due to lack of time I'd like to orphan a few of my packages, being:
 ...snip...
 incron
 ...snip...

 I find incron very handy... I'll take it if no one else does.

 Co-maintainers welcome.

 kevin

Thanks, feel free to take it.

Regards,

Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning some packages

[Ruben Kerkhof]

Due to lack of time I'd like to orphan a few of my packages, being:

Pound
debmirror
incron
mysql-proxy
perl-Beanstalk-Client
perl-Math-Calc-Units
perl-Nagios-Plugin
perl-Nagios-Plugin-Beanstalk
python-wokkel
whatsup

They're all low-maintenance packages with a release maybe once or twice a year.

Kind regards,

Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning some packages

[Ruben Kerkhof]

On Sun, Apr 1, 2012 at 15:18, Dominic Hopf dma...@googlemail.com wrote:
 On Sun, 2012-04-01 at 14:55 +0200, Ruben Kerkhof wrote:
 mysql-proxy

 I'd take that one.

 Best Regards,
 Dominic

Thanks, I've released ownership.

Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning some packages

[Ruben Kerkhof]

On Sun, Apr 1, 2012 at 15:27, Paul Howarth p...@city-fan.org wrote:
 On Sun, 1 Apr 2012 14:55:56 +0200
 Ruben Kerkhof ru...@rubenkerkhof.com wrote:

 Due to lack of time I'd like to orphan a few of my packages, being:
 ...
 perl-Math-Calc-Units

 I'll take that one.

 Paul.

Thanks, I've released ownership.

Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning Ajaxterm

[Ruben Kerkhof]

Since I've no personal use for it anymore, I'm orphaning Ajaxterm.

Any takers?

Kind regards,

Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning MogileFS

[Ruben Kerkhof]

Since I'm not able to give MogileFS the attention it deserves anymore,
I'd like to orphan it, including its dependencies.

Those are the following packages:

perl-mogilefs-server
perl-Sys-Syscall
perl-Perlbal-XS-HTTPHeaders
perl-MogileFS-Utils
perl-MogileFS-Client
perl-Gearman-Server
perl-Gearman-Client-Async
perl-Gearman
perl-Danga-Socket
Perlbal
perl-IO-AIO

Kind regards,

Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Orphaning rubygem-eventmachine

[Ruben Kerkhof]

Since I'm not using it anymore, I'd like to orphan rubygem-eventmachine.

Any takers?

Thanks, Ruben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Nagios-Plugin-0.35.tar.gz uploaded to lookaside cache by ruben

[Ruben Kerkhof]

A file has been added to the lookaside cache for perl-Nagios-Plugin:

96b3510798e28f3ebed8c23f4225e80e  Nagios-Plugin-0.35.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Nagios-Plugin] - Upstream released new version

[Ruben Kerkhof]

commit c050f33597e769fe66361b1ff7a2bf8dc7a9bd5e
Author: Ruben ru...@rubenkerkhof.com
Date:   Sun Dec 12 17:27:48 2010 +0100

- Upstream released new version

 .gitignore  |1 +
 perl-Nagios-Plugin.spec |5 -
 sources |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 153ba47..e0f8e80 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 Nagios-Plugin-0.34.tar.gz
+/Nagios-Plugin-0.35.tar.gz
diff --git a/perl-Nagios-Plugin.spec b/perl-Nagios-Plugin.spec
index 26e3ea1..5cb601e 100644
--- a/perl-Nagios-Plugin.spec
+++ b/perl-Nagios-Plugin.spec
@@ -1,7 +1,7 @@
 %global libname Nagios-Plugin
 
 Name:   perl-%{libname}
-Version:0.34
+Version:0.35
 Release:1%{?dist}
 Summary:Family of perl modules to streamline writing Nagios plugins
 License:GPL+ or Artistic
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/Nagios::Plugin*
 
 %changelog
+* Sun Dec 12 2010 Ruben Kerkhof ru...@rubenkerkhof.com 0.35-1
+- Upstream released new version
+
 * Thu Jun 24 2010 Ruben Kerkhof ru...@rubenkerkhof.com 0.34-1
 - Upstream released new version
 
diff --git a/sources b/sources
index 71c2daf..773b7f7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cf9c54fe89115916fb15609f4ff5fd3f  Nagios-Plugin-0.34.tar.gz
+96b3510798e28f3ebed8c23f4225e80e  Nagios-Plugin-0.35.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Nagios-Plugin-0.34.tar.gz uploaded to lookaside cache by ruben

[Ruben Kerkhof]

A file has been added to the lookaside cache for perl-Nagios-Plugin:

cf9c54fe89115916fb15609f4ff5fd3f  Nagios-Plugin-0.34.tar.gz
--
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

rpms/perl-Nagios-Plugin/devel .cvsignore, 1.2, 1.3 perl-Nagios-Plugin.spec, 1.3, 1.4 sources, 1.2, 1.3

[Ruben Kerkhof]

Author: ruben

Update of /cvs/pkgs/rpms/perl-Nagios-Plugin/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv15105

Modified Files:
.cvsignore perl-Nagios-Plugin.spec sources 
Log Message:
* Thu Jun 24 2010 Ruben Kerkhof ru...@rubenkerkhof.com 0.34-1
- Upstream released new version



Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Nagios-Plugin/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore  28 Aug 2009 14:50:55 -  1.2
+++ .cvsignore  24 Jun 2010 15:08:04 -  1.3
@@ -1 +1 @@
-Nagios-Plugin-0.33.tar.gz
+Nagios-Plugin-0.34.tar.gz


Index: perl-Nagios-Plugin.spec
===
RCS file: /cvs/pkgs/rpms/perl-Nagios-Plugin/devel/perl-Nagios-Plugin.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-Nagios-Plugin.spec 4 May 2010 08:23:19 -   1.3
+++ perl-Nagios-Plugin.spec 24 Jun 2010 15:08:04 -  1.4
@@ -1,15 +1,15 @@
-Name:   perl-Nagios-Plugin
-Version:0.33
-Release:4%{?dist}
+%global libname Nagios-Plugin
+
+Name:   perl-%{libname}
+Version:0.34
+Release:1%{?dist}
 Summary:Family of perl modules to streamline writing Nagios plugins
 License:GPL+ or Artistic
 Group:  Development/Libraries
-URL:http://search.cpan.org/dist/Nagios-Plugin/
-Source0:
http://www.cpan.org/modules/by-module/Nagios/Nagios-Plugin-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+URL:http://search.cpan.org/dist/%{libname}/
+Source0:
http://www.cpan.org/modules/by-module/Nagios/%{libname}-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl(Class::Accessor)
-Requires:   perl(Class::Accessor::Fast)
 BuildRequires:  perl(Config::Tiny)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(Math::Calc::Units)
@@ -29,15 +29,13 @@ providing a simpler functional interface
 available functionality.
 
 %prep
-%setup -q -n Nagios-Plugin-%{version}
+%setup -q -n %{libname}-%{version}
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-rm -rf %{buildroot}
-
 make pure_install PERL_INSTALL_ROOT=%{buildroot}
 
 find %{buildroot} -type f -name .packlist -exec rm -f {} \;
@@ -48,16 +46,16 @@ find %{buildroot} -depth -type d -exec r
 %check
 make test
 
-%clean
-rm -rf %{buildroot}
-
 %files
 %defattr(-,root,root,-)
 %doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Nagios
+%{_mandir}/man3/Nagios::Plugin*
 
 %changelog
+* Thu Jun 24 2010 Ruben Kerkhof ru...@rubenkerkhof.com 0.34-1
+- Upstream released new version
+
 * Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 0.33-4
 - Mass rebuild with perl-5.12.0
 


Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Nagios-Plugin/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 28 Aug 2009 14:50:55 -  1.2
+++ sources 24 Jun 2010 15:08:04 -  1.3
@@ -1 +1 @@
-7f5e00a3d683b1d39b169d9d772de33b  Nagios-Plugin-0.33.tar.gz
+cf9c54fe89115916fb15609f4ff5fd3f  Nagios-Plugin-0.34.tar.gz

--
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