HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Jan Synacek]

Hello all,

I've created a review request for compat-guile1.8:
https://bugzilla.redhat.com/show_bug.cgi?id=868263

Once the compat package lands in rawhide, I will leave some time for the
transition (I may work on the required patches if time allows me). After that,
guile (now version 1.8) will become 2.0.x.

I've already tried patching a few packages and there seem to be no real
problems, unlike patching the old apps for the new guile.

Affected packages:
aisleriot
autogen
coot
denemo
drgeo
freehoo
freetalk
geda
gnubik
gnucash
gnurobots
gnutls
graphviz
libctl
libgeda
lilypond
mdk
rumor
TeXmacs
trackballs
xbindkeys

Cheers,

-- 
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Any progress in Software Center in Fedora effort?

[Lukas Zapletal]

On Sun, Oct 07, 2012 at 06:51:26PM +0200, tim.laurid...@gmail.com wrote:
 The ultimate software center is a web application, like Google playstore.

+1

Why to waste time creating a desktop app when this could be in the cloud
already. Plus this could be turned into a desktop web app easily,
browser just need to handle links correctly.

Remember Lindows with their Click-And-Run (TM) technology? It was a
great idea by the way, years before App Store and these kinds of things.

http://en.wikipedia.org/wiki/Linspire

-- 
Later,

 Lukas lzap Zapletal
 #katello #systemengine
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Lukas Zapletal]

 Fedora Infrastructure has begun using ansible for some system setup
 and other orchestration/automation tasks.
 
 Our (just beginning) public repos of it are here:
 
 http://infrastructure.fedoraproject.org/cgit/ansible.git/


Just out of my curiosity, is Fedora Infra going to replace Puppet with
this, or you are planning to use these two technologies in parallel?

Thanks

-- 
Later,

 Lukas lzap Zapletal
 #katello #systemengine
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Lukas Zapletal]

On Fri, Oct 19, 2012 at 07:35:28PM -0400, Matthew Miller wrote:
  * Move EPEL 6, Fedora = 17 to use Puppet 3.0.
 Speaking for my previous job, it would really be unfortunate to have a
 non-compatible update of puppet in EPEL. Unless accompanied by very loud
 trumpets and fireworks beforehand, the day that update went out would be a
 very sad and busy day for a number of sysadmins.

+1

I vote for having puppet3 and not touching the default version. This
will be more challenging, but we all know a bit about puppet upgrades
and transitions - it can be big pain.

-- 
Later,

 Lukas lzap Zapletal
 #katello #systemengine
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Lukas Zapletal]

 I'm sure that 2.6 won't last for the life of EL5, let alone EL6.  At
 the same time, I didn't push to get 2.7 in EPEL because it isn't a
 completely compatible update.  And 3.0 was coming so I figured we
 could wait to see what things looked like when it did.  The
 alternative would have been more updates and more potential to break
 things and annoy the users who were perfectly happy with how 2.6 was
 working.  (Those that needed the newest shiny or were supporting
 Fedora 17 could get newer bits from yum.puppetlabs.com.)

Yes, but this this is not really necessary. From the EPEL FAQ:

***

How long are EPEL packages updated?
---

The plan is for EPEL packages to get updates as long as the
corresponding RHEL release is supported. That is 10 years after the
initial release according to the current errata support policy for 5 and
6 releases.

How can we be sure that someone will maintain the packages until end of
life of the distribution the packages were built for?
-

The only way to be sure is to do it yourself, which is coincidentally
the reason EPEL was started in the first place.

Software packages in EPEL are maintained on a voluntary basis. If you to
want ensure that the packages you want remain available, get involved
directly in the EPEL effort. More experienced maintainers help review
your packages and you learn about packaging. If you can, get your
packaging role included as part of your job description; EPEL has
written a generic description that you can use as the basis for adding
to a job description.

We do our best to make this a healthy project with many contributors who
take care of the packages in the repository, and the repository as a
whole, for all releases until RHEL closes support for the distribution
version the packages were built for. That is seven years after release
(currently) -- a long time frame, and we know a lot can happen in seven
years. Your participation is vital for the success of this project.

*** 

Users have been warned (and asked for help).

-- 
Later,

 Lukas lzap Zapletal
 #katello #systemengine
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

A bash script to create Desktop Background gallery xml files now available

[G.Wolfe Woodbury]

  I've written a bash script to turn a directory, directory tree, or
list of files into an XML file suitable for use with the Desktop
Background gallery construct in GNOME.

  I could not find one @GNOME.org or freedesktop.org, so I wrote one for
myself based on the Cosmos gallery definition and some experimenting.

  I haven't yet found what program or library is handling the decoding
of this XML file (nor what draws the desktop background actually) so I
can't be sure that I fully handle all the DTD options.  Any pointers on
where to find the specification(s) are appreciated.

  I've been running it under GNOME 3.4.2 for a couple of weeks now and
it seems solid enough.  Some of the other options that I suspect should
be available in the DTD/XML (such as scale vs. stretch etcetera) can
be set via dconf-editor or GNOME Control Center.

  It has been quite a while since I've done much programming, and this
is the first thing I'm throwing into the Fedora Project and GNOME
waters. (Be gentle in your criticisms please.)

  The script is to be found at:

http://redwolfe.fedorapeople.org/BkgMake/BkgMake.sh

There is a fairly detailed -h option, and it is commented throughout.

TODO: add an option to automatically shuffle the image file list
before writing the output.  write a man page and texinfo file.  make a
real Fedora package for the thing.

  Have at it people.

-- 
Gregory Wolfe Woodbury
FAS: redwolfe
redwo...@gmail.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 17 'tig' package update change

[Lukas Zapletal]

Hello,

I have noticed that latest tig update in Fedora 17 changed it's
behavior. Default key binding is different, j and k keys now
automatically change from change-list to change-content, therefore I
need to hit the tab key. Annoying, I want the mutt-like behavior
back :-)

Anyone noticed the change?

-- 
Later,

 Lukas lzap Zapletal
 #katello #systemengine
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Kalev Lember]

On 10/23/2012 08:51 AM, Jan Synacek wrote:
 Hello all,
 
 I've created a review request for compat-guile1.8:
 https://bugzilla.redhat.com/show_bug.cgi?id=868263
 
 Once the compat package lands in rawhide, I will leave some time for the
 transition (I may work on the required patches if time allows me). After that,
 guile (now version 1.8) will become 2.0.x.

Hello Jan,

Very cool. The lack of guile 2.0 has been keeping Aisleriot updates back
for several Fedora releases now.

Are you planning to make the 2.0 version available for F18 as well?

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

koji errors

[Simone Caronni]

Hello,

yesterday I had some invalid channel policy errors when trying to
build packages with koji. Tasks were never ending with the building
status on.
I canceled the builds after few hours and today I tried again to build them.

The jobs always fail because I have errors like the following (3
packages, fc18 went fine):

GenericError: Error importing archive file,
/mnt/koji/packages/guacamole-ext/0.6.2/1.fc16/src/guacamole-ext-0.6.2-1.fc16.src.rpm
already exists
GenericError: Error importing archive file,
/mnt/koji/packages/guacamole-ext/0.6.2/1.fc17/src/guacamole-ext-0.6.2-1.fc17.src.rpm
already exists
GenericError: Error importing archive file,
/mnt/koji/packages/guacamole-ext/0.6.2/1.fc19/src/guacamole-ext-0.6.2-1.fc19.src.rpm
already exists

Can someone check it or reset the builds so I can build them?

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Jan Synacek]

On 10/23/2012 11:15 AM, Kalev Lember wrote:
 On 10/23/2012 08:51 AM, Jan Synacek wrote:
 Hello all,

 I've created a review request for compat-guile1.8:
 https://bugzilla.redhat.com/show_bug.cgi?id=868263

 Once the compat package lands in rawhide, I will leave some time for the
 transition (I may work on the required patches if time allows me). After 
 that,
 guile (now version 1.8) will become 2.0.x.
 
 Hello Jan,
 
 Very cool. The lack of guile 2.0 has been keeping Aisleriot updates back
 for several Fedora releases now.
 
 Are you planning to make the 2.0 version available for F18 as well?
 

I'm quite hesitant to update F18 as well. I mean, it would be nice, but I'm not
sure if all can be probably patched and tested in time. If only I had done this
a few weeks earlier..:)

-- 
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[SOLVED] kernel 2.6.x and Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (kmod-wl)

[Dario Lesca]

On this Asus EeePC seashell series Notebook:
http://www.smolts.org/client/show/pub_e9f34fbb-dd9d-4b7d-8c77-027292c81297

After kernel update to 3.6.[12] (plus relative kmod-wl* module) the WiFi
stop work

I have found this article:
https://bbs.archlinux.org/viewtopic.php?pid=1176829

then I have install the akmod driver and I have apply to .spec file this
patch:
 
 [root@ludvic ~]# diff -Naur rpmbuild/SPECS/wl-kmod.spec.orig 
 rpmbuild/SPECS/wl-kmod.spec
 --- rpmbuild/SPECS/wl-kmod.spec.orig2012-10-22 22:57:55.284478328 +0200
 +++ rpmbuild/SPECS/wl-kmod.spec 2012-10-22 22:32:17.134583423 +0200
 @@ -69,7 +69,7 @@
  %build
  for kernel_version in %{?kernel_versions}; do
   pushd _kmod_build_${kernel_version%%___*}
 - make -C ${kernel_version##*___} M=`pwd` modules
 + make -C ${kernel_version##*___} M=`pwd` modules API=WEXT
   popd
  done

Rebuild with rpmbuild -ba rpmbuild/SPECS/wl-kmod.spec, remove old
module rmmod wl, uninstall and reinstall new RPMS generated, reload
module modprobe wl, and test it:

Now WiFi work

Hope this help

Many thanks

-- 
Dario Lesca - sip:da...@solinos.it
(Inviato dal mio Linux Fedora 17 Gnome3)

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

[perl-XML-LibXML] 2.0008 bump

[Petr Šabata]

commit aa5091e31dcb2f09ed0f9894d6aeae31af8c1200
Author: Petr Šabata con...@redhat.com
Date:   Tue Oct 23 11:35:44 2012 +0200

2.0008 bump

This update fixes XML::LibXML builds with libxml2 in non-standard
locations.

 .gitignore   |1 +
 perl-XML-LibXML.spec |5 -
 sources  |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9a9945a..b498f1a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ XML-LibXML-1.70.tar.gz
 /XML-LibXML-2.0004.tar.gz
 /XML-LibXML-2.0006.tar.gz
 /XML-LibXML-2.0007.tar.gz
+/XML-LibXML-2.0008.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index 8307a6f..980d094 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -3,7 +3,7 @@ Name:   perl-XML-LibXML
 # https://bugzilla.redhat.com/show_bug.cgi?id=469480
 # it might not be needed anymore
 # this module is maintained, the other is not
-Version:2.0007
+Version:2.0008
 Release:1%{?dist}
 Epoch:  1
 Summary:Perl interface to the libxml2 library
@@ -102,6 +102,9 @@ fi
 %{_mandir}/man3/*.3*
 
 %changelog
+* Tue Oct 23 2012 Petr Šabata con...@redhat.com - 1:2.0008-1
+- 2.0008 bump
+
 * Thu Oct 18 2012 Petr Šabata con...@redhat.com - 1:2.0007-1
 - 2.0007 bump
 
diff --git a/sources b/sources
index 247ab81..ff5d526 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cbce16e0081f2129f44e02293f0d175a  XML-LibXML-2.0007.tar.gz
+d2bb8b6453574a47b46e3329902bde2d  XML-LibXML-2.0008.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

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Kalev Lember]

On 10/23/2012 11:42 AM, Jan Synacek wrote:
 On 10/23/2012 11:15 AM, Kalev Lember wrote:
 On 10/23/2012 08:51 AM, Jan Synacek wrote:
 Hello all,

 I've created a review request for compat-guile1.8:
 https://bugzilla.redhat.com/show_bug.cgi?id=868263

 Once the compat package lands in rawhide, I will leave some time for the
 transition (I may work on the required patches if time allows me). After 
 that,
 guile (now version 1.8) will become 2.0.x.

 Hello Jan,

 Very cool. The lack of guile 2.0 has been keeping Aisleriot updates back
 for several Fedora releases now.

 Are you planning to make the 2.0 version available for F18 as well?

 
 I'm quite hesitant to update F18 as well. I mean, it would be nice, but I'm 
 not
 sure if all can be probably patched and tested in time. If only I had done 
 this
 a few weeks earlier..:)

I agree, updating 21 packages is a bit too much at this point in F18
schedule.

However, a way to make this work for F18 would be creating a parallel
installable guile20 package. So instead of what you are planning now:

guile-2.0.x
compat-guile1.8-1.8.x

We'd have:
guile20-2.0.x
guile-1.8.x

This way no apps need to be updated for the guile - compat-guile1.8
transition. Instead, they could be ported to guile20 at their own pace
and there wouldn't have to be a flag day for switching all of them over
at once.

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

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Jan Synacek]

On 10/23/2012 11:55 AM, Kalev Lember wrote:
 I agree, updating 21 packages is a bit too much at this point in F18
 schedule.
 
 However, a way to make this work for F18 would be creating a parallel
 installable guile20 package. So instead of what you are planning now:
 
 guile-2.0.x
 compat-guile1.8-1.8.x
 
 We'd have:
 guile20-2.0.x
 guile-1.8.x
 
 This way no apps need to be updated for the guile - compat-guile1.8
 transition. Instead, they could be ported to guile20 at their own pace
 and there wouldn't have to be a flag day for switching all of them over
 at once.
 

This is what I had originally in mind. After trying to realize this idea and
consulting it with the maintainer (I'm a comaintainer of guile), it didn't seem
right. The problem is that a lot of things have to be renamed, including some
autotools macros, and that creates a lot of mess long term (if it was done the
the new package). With the compat package however, this are renamed as well, but
it's the old stuff and then you can only slightly patch (mainly spec, no code
changes needed) the old apps so they compile and run and don't have to worry
about future changes. After guile is upgraded to 2.0.x, you can slowly start
porting as well.

Huh, I hope my point is clearly visible in my slightly complicated message..

Cheers,

-- 
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Test-Memory-Cycle] Specify all dependencies.

[Marcela Mašláňová]

commit adc9f1d12e8f1a6ba1f8154f2b8e95b5524e8f1b
Author: Marcela Mašláňová mmasl...@redhat.com
Date:   Tue Oct 23 12:13:26 2012 +0200

Specify all dependencies.

Signed-off-by: Marcela Mašláňová mmasl...@redhat.com

 perl-Test-Memory-Cycle.spec |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)
---
diff --git a/perl-Test-Memory-Cycle.spec b/perl-Test-Memory-Cycle.spec
index 03b6301..409e8b1 100644
--- a/perl-Test-Memory-Cycle.spec
+++ b/perl-Test-Memory-Cycle.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-Memory-Cycle
 Version:1.04
-Release:15%{?dist}
+Release:16%{?dist}
 Summary:Check for memory leaks and circular memory references
 
 Group:  Development/Libraries
@@ -12,11 +12,16 @@ BuildRoot:  
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 BuildRequires:  perl(CGI)
 BuildRequires:  perl(Devel::Cycle) = 1.07
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Getopt::Long)
 BuildRequires:  perl(PadWalker)
+BuildRequires:  perl(Scalar::Util)
+BuildRequires:  perl(Test::Builder)
 BuildRequires:  perl(Test::Builder::Tester)
+BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Test::Simple) = 0.62
-BuildRequires:  perl(Test::Pod)
-BuildRequires:  perl(Test::Pod::Coverage)
+BuildRequires:  perl(Test::Pod) = 1.14
+BuildRequires:  perl(Test::Pod::Coverage) = 1.04
 Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
 
 %description
@@ -60,6 +65,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Tue Oct 23 2012 Jitka Plesnikova jples...@redhat.com - 1.04-16
+- Specify all dependencies.
+
 * Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.04-15
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
--
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: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Kalev Lember]

On 10/23/2012 12:12 PM, Jan Synacek wrote:
 This is what I had originally in mind. After trying to realize this idea and
 consulting it with the maintainer (I'm a comaintainer of guile), it didn't 
 seem
 right. The problem is that a lot of things have to be renamed, including some
 autotools macros, and that creates a lot of mess long term (if it was done the
 the new package). With the compat package however, this are renamed as well, 
 but
 it's the old stuff and then you can only slightly patch (mainly spec, no code
 changes needed) the old apps so they compile and run and don't have to worry
 about future changes. After guile is upgraded to 2.0.x, you can slowly start
 porting as well.
 
 Huh, I hope my point is clearly visible in my slightly complicated message..

Oh, I see -- are you trying to make guile 2.x and guile 1.8.x -devel
packages parallel installable?

I am not sure it's worth the effort. Or more bluntly, I am not even sure
it's the right thing to do. E.g. something like the following (from
compat-guile1.8 spec file) strikes me as unusual and can cause a lot of
churn in dependent packages:

 ac=${RPM_BUILD_ROOT}%{_datadir}/aclocal/guile1.8.m4
 sed -i -e 's|,guile|,guile1.8|g' $ac
 sed -i -e 's|guile-tools|guile1.8-tools|g' $ac
 sed -i -e 's|guile-config|guile1.8-config|g' $ac
 sed -i -e 's|GUILE_PROGS|GUILE1_8_PROGS|g' $ac
 sed -i -e 's|GUILE_FLAGS|GUILE1_8_FLAGS|g' $ac
 sed -i -e 's|GUILE_SITE_DIR|GUILE1_8_SITE_DIR|g' $ac
 sed -i -e 's|GUILE_CHECK|GUILE1_8_CHECK|g' $ac
 sed -i -e 's|GUILE_MODULE_CHECK|GUILE1_8_MODULE_CHECK|g' $ac
 sed -i -e 's|GUILE_MODULE_AVAILABLE|GUILE1_8_MODULE_AVAILABLE|g' $ac
 sed -i -e 's|GUILE_MODULE_REQUIRED|GUILE1_8_MODULE_REQUIRED|g' $ac
 sed -i -e 's|GUILE_MODULE_EXPORTS|GUILE1_8_MODULE_EXPORTS|g' $ac
 sed -i -e 's|GUILE_MODULE_REQUIRED_EXPORT|GUILE1_8_MODULE_REQUIRED_EXPORT|g' 
 $ac

The two -devel packages could just as well have explicit Conflicts set
to make sure they can't be installed at the same time; I don't think
it's important to hack them up to make them parallel installable, if it
involves such invasive changes.

What really matters is that end users can have 1.8 and 2.0 interpreter
and libraries installed at the same time. Not -devel packages; these are
mostly just used within koji for building binary packages.

This also appears to be what Debian is doing.

Parallel installable guile interpreters:
http://packages.debian.org/sid/amd64/guile-1.8/filelist
http://packages.debian.org/sid/amd64/guile-2.0/filelist

Conflicting -dev package:
http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist
http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist

-- 
Hope this helps,
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Vít Ondruch]

Dne 23.10.2012 09:55, Lukas Zapletal napsal(a):

On Fri, Oct 19, 2012 at 07:35:28PM -0400, Matthew Miller wrote:

* Move EPEL 6, Fedora = 17 to use Puppet 3.0.

Speaking for my previous job, it would really be unfortunate to have a
non-compatible update of puppet in EPEL. Unless accompanied by very loud
trumpets and fireworks beforehand, the day that update went out would be a
very sad and busy day for a number of sysadmins.

+1

I vote for having puppet3 and not touching the default version. This
will be more challenging, but we all know a bit about puppet upgrades
and transitions - it can be big pain.



Lets have puppet-3.x and puppet2 for whoever wants to use old version.


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

F-18 Branched report: 20121023 changes

[Fedora Branched Report]

Compose started at Tue Oct 23 09:15:30 UTC 2012

Compose finished at Tue Oct 23 12:07:10 UTC 2012

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

Re: [mate-screensaver] Initial import

[TASAKA Mamoru]

Hello, mate-screensaver maintainer:

leigh123linux wrote, at 10/23/2012 04:13 PM +9:00:

commit e8b3798a18387d3e05675f40c4ee5998e94d0dfd
Author: leigh123linux leigh123li...@googlemail.com
Date:   Tue Oct 23 08:13:31 2012 +0100

 Initial import

  .gitignore|1 +
  mate-screensaver.spec |  131 +
  sources   |1 +
  3 files changed, 133 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..ea3919d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/mate-screensaver-1.4.0.tar.xz
diff --git a/mate-screensaver.spec b/mate-screensaver.spec
new file mode 100644
index 000..b4c2afd
--- /dev/null
+++ b/mate-screensaver.spec



@@ -0,0 +1,131 @@


skip


+%build
+%configure \
+--disable-static \
+--disable-schemas-install \
+--with-xscreensaverdir=%{_datadir}/xscreensaver/config \
+--with-xscreensaverhackdir=%{_libexecdir}/xscreensaver  \
+--enable-locking \
+--enable-pam
+


Maybe mate-screensaver will use xscreensaver-foo.desktop under
%{_datadir}/applications/screensavers (in xscreensaver-extras-gss
and xscreensaver-gl-extras-gss) like gnome-screensaver 2.x?
If so, it may be better that I drop Requires: gnome-screensaver on
xscreensaver-extras-gss and xscreensaver-gl-extras-gss because
if gnome-screensaver user wants to use these desktop files he/she
will install gnome-screensaver beforehand anyway, and if mate-screensaver
user wants to use these desktop files he/she does not want to install
gnome-screensaver (and he/she will install mate-screensaver beforehand).

How do you think? I will appreciate your opinion

Regards,
Mamoru Tasaka



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

Re: Fixing Puppet in Fedora/EPEL

[Matthew Miller]

On Tue, Oct 23, 2012 at 01:57:13PM +0200, Vít Ondruch wrote:
 I vote for having puppet3 and not touching the default version. This
 will be more challenging, but we all know a bit about puppet upgrades
 and transitions - it can be big pain.
 Lets have puppet-3.x and puppet2 for whoever wants to use old version.

But that doesn't help people running puppet 2.6 _now_, and just introduces
complication into the packaging. 



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Vít Ondruch]

Dne 23.10.2012 15:10, Matthew Miller napsal(a):

On Tue, Oct 23, 2012 at 01:57:13PM +0200, Vít Ondruch wrote:

I vote for having puppet3 and not touching the default version. This
will be more challenging, but we all know a bit about puppet upgrades
and transitions - it can be big pain.

Lets have puppet-3.x and puppet2 for whoever wants to use old version.

But that doesn't help people running puppet 2.6 _now_, and just introduces
complication into the packaging.





Introducing new package is complication anyway, so what is the point?


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

Re: koji errors

[Eric Sparks Christensen]

On Tue, Oct 23, 2012 at 5:24 AM, Simone Caronni negativ...@gmail.com wrote:
 Hello,

 yesterday I had some invalid channel policy errors when trying to
 build packages with koji. Tasks were never ending with the building
 status on.
 I canceled the builds after few hours and today I tried again to build them.

 The jobs always fail because I have errors like the following (3
 packages, fc18 went fine):

I, too, had these problems building cqrlog for fc17.  Not sure what's going on.

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

Re: Fixing Puppet in Fedora/EPEL

[M A Young]

On Tue, 23 Oct 2012, Vít Ondruch wrote:


Dne 23.10.2012 15:10, Matthew Miller napsal(a):

On Tue, Oct 23, 2012 at 01:57:13PM +0200, Vít Ondruch wrote:

Lets have puppet-3.x and puppet2 for whoever wants to use old version.

But that doesn't help people running puppet 2.6 _now_, and just introduces
complication into the packaging.


Introducing new package is complication anyway, so what is the point?


The problem is that upgrading from 2.6 to 2.7 (and therefore to 3) will 
almost certainly break things depending on how the update is done, for 
example resulting in clients that don't work against the server, so you 
don't want to break lots of puppet installations out there by 
automatically updating the puppet to version 3 which is what would happen 
if you changed the version in the puppet package. With a puppet3 package 
people can choose when they upgrade and do it in a controlled manner.


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

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Miroslav Lichvar]

On Tue, Oct 23, 2012 at 12:52:47PM +0200, Kalev Lember wrote:
 Parallel installable guile interpreters:
 http://packages.debian.org/sid/amd64/guile-1.8/filelist
 http://packages.debian.org/sid/amd64/guile-2.0/filelist

So both new and old guile scripts need to be patched to call
the right binary? Or is there a symlink created?

 Conflicting -dev package:
 http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist
 http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist

Jan was proposing this approach too, but I thought if some packages
need to be patched to use the 1.8 guile paths, why not make one step
further and patch also the paths used in building. At least, when the
maintainers of the old packages prepare the patches, they can make
sure if the packages still work correctly.

Our packaging guidelines seem to allow (but discourage) conflicts with
compat devel packages, if you think this will be a lot of unnecessary
work, I'm ok with the conflict.

FWIW, the OpenSuse packages don't seem to have the conflict and their
libguile1-devel package has the aclocal file renamed to guile1.m4.

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

Re: Schedule for Wednesday's FESCo Meeting (2012-10-24)

[Jaroslav Reznik]

- Original Message -
 Following is the list of topics that will be discussed in the FESCo
 meeting Wednesday at 17:00UTC (1:00pm EDT) in #fedora-meeting on
 irc.freenode.net.
 
 Links to all tickets below can be found at:
 https://fedorahosted.org/fesco/report/9
 
 = Followups =
 
 #topic #946 Fedora 18 Beta freeze readiness: is major functionality
 in place?
 .fesco 946
 https://fedorahosted.org/fesco/ticket/946
 
 #topic #938 F18 Features - progress at Features 100% Complete
 deadline
 (was: Feature Freeze)
 .fesco 938
 https://fedorahosted.org/fesco/ticket/938

Correct ticket is https://fedorahosted.org/fesco/ticket/932

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

Re: Schedule for Wednesday's FESCo Meeting (2012-10-24)

[Jon Ciesla]

On Tue, Oct 23, 2012 at 8:46 AM, Jaroslav Reznik jrez...@redhat.com wrote:
 - Original Message -
 Following is the list of topics that will be discussed in the FESCo
 meeting Wednesday at 17:00UTC (1:00pm EDT) in #fedora-meeting on
 irc.freenode.net.

 Links to all tickets below can be found at:
 https://fedorahosted.org/fesco/report/9

 = Followups =

 #topic #946 Fedora 18 Beta freeze readiness: is major functionality
 in place?
 .fesco 946
 https://fedorahosted.org/fesco/ticket/946

 #topic #938 F18 Features - progress at Features 100% Complete
 deadline
 (was: Feature Freeze)
 .fesco 938
 https://fedorahosted.org/fesco/ticket/938

 Correct ticket is https://fedorahosted.org/fesco/ticket/932

D'oh!  Thanks!

-J

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



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: Fixing Puppet in Fedora/EPEL

[Vít Ondruch]

Dne 23.10.2012 15:37, Matthew Miller napsal(a):

On Tue, Oct 23, 2012 at 03:22:27PM +0200, Vít Ondruch wrote:

But that doesn't help people running puppet 2.6 _now_, and just introduces
complication into the packaging.

Introducing new package is complication anyway, so what is the point?

See earlier comments. The point is that when the update goes live, people
running the older version with non-compatible configs won't have their
systems break. This is important.




Yes, I understand that ... therefore you need two versions of puppet 
installed in parallel. There was proposal to prepare puppet3 package, 
while I think that the correct way is to move puppet to version 3 and 
prepare new puppet2 or compat-puppet package.


Once you introduce version into the name, you will never be able to get 
rid of it, although puppet 4 might be 100% compatible with puppet 3 and 
I hope you don't like to have package puppet3-4.x in the future.



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

Re: koji errors

[Simone Caronni]

On 23 October 2012 15:25, Eric Sparks Christensen
spa...@fedoraproject.org wrote:
 On Tue, Oct 23, 2012 at 5:24 AM, Simone Caronni negativ...@gmail.com wrote:
 Hello,

 yesterday I had some invalid channel policy errors when trying to
 build packages with koji. Tasks were never ending with the building
 status on.
 I canceled the builds after few hours and today I tried again to build them.

 The jobs always fail because I have errors like the following (3
 packages, fc18 went fine):

 I, too, had these problems building cqrlog for fc17.  Not sure what's going 
 on.

I just received the broken deps mail for the package I can't build...

Is there any way to force delete a specific n-v-r from koji?

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Greg Swift]

On Tue, Oct 23, 2012 at 8:47 AM, Vít Ondruch vondr...@redhat.com wrote:
 Dne 23.10.2012 15:37, Matthew Miller napsal(a):

 On Tue, Oct 23, 2012 at 03:22:27PM +0200, Vít Ondruch wrote:

 But that doesn't help people running puppet 2.6 _now_, and just
 introduces
 complication into the packaging.

 Introducing new package is complication anyway, so what is the point?

 See earlier comments. The point is that when the update goes live, people
 running the older version with non-compatible configs won't have their
 systems break. This is important.



 Yes, I understand that ... therefore you need two versions of puppet
 installed in parallel. There was proposal to prepare puppet3 package, while
 I think that the correct way is to move puppet to version 3 and prepare new
 puppet2 or compat-puppet package.

 Once you introduce version into the name, you will never be able to get rid
 of it, although puppet 4 might be 100% compatible with puppet 3 and I hope
 you don't like to have package puppet3-4.x in the future.

I'm still not sold on parallel installation being the solution for
this situation.  I get the idea behind it, but to me that just adds
unnecessary complication to the whole thing.  Not saying its not the
route to go, just not at the top of my list.

What I do think would be a good idea is if we could try addressing
this issue from a higher level since Puppet is decidedly not the only
package with this problem.

but then... i've a vested interest in that concept because I started a
thread about it on the epel-devel list last week (as Toshio mentioned
earlier in this thread).

https://www.redhat.com/archives/epel-devel-list/2012-October/msg00015.html

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

Re: Fixing Puppet in Fedora/EPEL

[Seth Vidal]

On Tue, 23 Oct 2012, Lukas Zapletal wrote:


Fedora Infrastructure has begun using ansible for some system setup
and other orchestration/automation tasks.

Our (just beginning) public repos of it are here:

http://infrastructure.fedoraproject.org/cgit/ansible.git/



Just out of my curiosity, is Fedora Infra going to replace Puppet with
this, or you are planning to use these two technologies in parallel?



As we move things into our private cloud instance we need a provisioning 
system that:
 1. doesn't have a bunch of painful dependencies that go on every system 
(ruby)
 2. doesn't require us to provision our systems before we provision our 
systems
 3. doesn't require some other other daemon or cron job running on the 
systems to maintain them



If it can take care of the needs we have I would certainly like to replace 
puppet. I do not speak for everyone work on the infrastructure team, but I 
am working on it as if our goal is replacement.


-sv


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

HEADUP for all PEAR packages

[Remi Collet]

For years... pear have its metadata database stored in /usr/share/pear

This will move soon to /var/lib/pear (to be FHS compliant).
(feature approved/merged by upstream)

With this last change, we'll have only libraries in /usr/share/pear
(which is part of the default php include_path)

WARNING : all pear packages will be FTBFS.

Very simple fix:

Define the default metadata directory location

   %{!?pear_metadir: %global pear_metadir %{pear_phpdir}}


And instead of
   # Clean up unnecessary files
   rm -rf %{buildroot}%{pear_phpdir}/.??*

Use
   rm -rf %{buildroot}%{pear_metadir}/.??*


This can be applied on all branches
(already used on some of my packages, see php-phpunit-PHPUnit p.e.)


Best regards,
Remi.


[1]
http://pkgs.fedoraproject.org/cgit/php-phpunit-PHPUnit.git/commit/?id=a010eeaf57324c5f9cbb8580f14d589dcf7b6f62
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [SOLVED] kernel 3.6.x and Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (kmod-wl)

[Dario Lesca]

Il giorno mar, 23/10/2012 alle 11.41 +0200, Dario Lesca ha scritto:
 After kernel update to 3.6.[12]
Sorry, kernel is 3.6.x and not 2.6.x as erroneously reported in the
subject

-- 
Dario Lesca - sip:da...@solinos.it
(Inviato dal mio Linux Fedora 17 Gnome3)

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

Re: What are reasonable blockers for making journald the default logger in F19?

[Richard W.M. Jones]

On Sun, Oct 21, 2012 at 01:50:59AM +0200, Lennart Poettering wrote:
 On Wed, 17.10.12 18:02, Richard W.M. Jones (rjo...@redhat.com) wrote:
 
  I'd like to see the current binary format officially documented
  upstream, and a promise not maintain backwards compatibility forever
  (and some forwards compat too if possible).
 
 The format is documented now:
 
 http://www.freedesktop.org/wiki/Software/systemd/journal-files
 
 And it's included in the stability promise:
 
 http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart

Thanks for doing this.

In case it's not clear already, libguestfs will use the file format
(or more likely the C API) to read journal files out of guests, so
we'll definitely encounter the host journal version != guest journal
version case in future.

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

[Tom Callaway]

On 10/22/2012 07:52 PM, Michael Weiner wrote:
 Did you try re-installing rJava within R (i.e.
 install.packages(rJava)) ?? I wasnt aware these contrib packages
 were available through yum

rJava is included as a subpackage of R. (yum install R-java)

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: R

[Tom Callaway]

On 10/22/2012 09:39 PM, Richard Vickery wrote:
 sorry I mistakenly deleted the R discussion from my inbox. Here is what

Based on your errors, I'm wondering if you're using the R packages in
Fedora, or if you've built R from source. I did a fresh install of R:
(yum install R R-java), then ran install.packages(JGR) and it worked
properly. Can you please confirm how you installed R?

The only major difference I can see is that you're on a 32bit system and
I tested on x86_64, but that shouldn't be an issue.

Also, confirming that you have java-1.7.0-openjdk-devel installed would
be helpful. One of your logs showed it failing to compile rJava, and
there is probably useful debugging in the config.log that was generated.

Thanks,

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Matthew Miller]

On Tue, Oct 23, 2012 at 03:47:43PM +0200, Vít Ondruch wrote:
 Yes, I understand that ... therefore you need two versions of puppet
 installed in parallel. There was proposal to prepare puppet3
 package, while I think that the correct way is to move puppet to
 version 3 and prepare new puppet2 or compat-puppet package.

That's probably correct for a new major release. It's not okay during the
lifecycle of a stable product, if we can avoid it. (Sometimes we can't.
We're not at can't yet for this.)

 Once you introduce version into the name, you will never be able to
 get rid of it, although puppet 4 might be 100% compatible with

That's not true. In the future, puppet can obsolete puppet3 -- for example,
in EPEL 7.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg / koji error

[Tom Callaway]

On 10/22/2012 10:37 PM, Ralf Corsepius wrote:
 On 10/22/2012 10:43 PM, Tom Callaway wrote:
 On 10/22/2012 12:09 PM, Ralf Corsepius wrote:
 There is currently no way to undefine a macro at the rpm commandline,

 rpmbuild --define  %{nil} ?

 Huh, I swear I knew that once. :) Attached is a patch to use the %{nil}
 behavior instead of setting the unused dist macro to 0. I smoke tested
 and confirmed that the %{rhel} macro is unset on Fedora with this patch
 applied.
 
 I haven't tried your patch, but don't you have to unset/define %{nil}
 all build-host related rpm macros from /etc/rpm/macros.dist?
 
 It's at least what I can not avoid doing in my before-mentioned
 build-scripts.
 
 I.e. when running my script on Fedora 17, I invoke rpmbuild this way:
 
 rpmbuild ... \
  --define fedora %{nil} --define fc17 %{nil}
  --define dist .el6 --define rhel 6  --define el6 1
  ...
 
 Otherwise constructs such as
 %{?fc17:}
 %{?el6:}
 also won't work correctly in rpm.specs.
 
 IIUC, fedpkg with your patch sets %dist and unsets %fedora, but it
 doesn't seem to catch fc17.

Yeah, thats a valid corner case. It wasn't in the original issue, so I
didn't think about it. I'll work on a fix that covers that as well.

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: R

[Richard W.M. Jones]

Please use the Fedora users list for user questions:

https://admin.fedoraproject.org/mailman/listinfo/users

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: R

[Richard Vickery]

Here's what I get:

$ sudo yum install R-java
[sudo] password for :
Loaded plugins: langpacks, presto, refresh-packagekit
adobe-linux-i386 |  951 B 00:00

google-chrome|  951 B 00:00

rpmfusion-free-updates
  | 3.3 kB 00:00
updates/metalink
  |  14 kB 00:00
updates
 | 4.7 kB 00:00
updates/primary_db
  | 5.2 MB 00:09
rpmfusion-free-updates/primary_db
 | 258 kB 00:00
updates/group_gz
  | 435 kB 00:01
Package R-java-2.15.1-1.fc17.i686 already installed and latest version
Nothing to do

Thanks for the help - Hopefully I won't have to use the Window's machines
on campus for the exam. I could if I need to, and I have trouble typing -
an old injury - so I am leery of typing the code because of time
constraints. I partly use R-Studio, but it doesn't give me the plots I
might need.

On Tue, Oct 23, 2012 at 8:11 AM, Tom Callaway tcall...@redhat.com wrote:

 On 10/22/2012 07:52 PM, Michael Weiner wrote:
  Did you try re-installing rJava within R (i.e.
  install.packages(rJava)) ?? I wasnt aware these contrib packages
  were available through yum

 rJava is included as a subpackage of R. (yum install R-java)

 ~tom

 ==
 Fedora Project
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADUP for all PEAR packages

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 23/10/2012 16:44, Reindl Harald a écrit :

 does pear update pear this also know?

Currently we have latest pear 1.9.4 in fedora.

As this feature have been merged by upstream,
yes next version will be aware of this feature.

And pear, in fedora, is mostly released closed to upstream.

 in the real life mostly even as RPM packed pear packages are
 updated with pear upgrade because the RPM's are way behind by
 design

I disagree.

RPM maintainers keep a consistent PEAR stack and add more QA.

Before running any pear update ... you should ask why this is not
available as RPM. I have often differ updates because new package is
broken (or break others)

Remi.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCGud0ACgkQYUppBSnxahgouQCeLE/Mg2QyOhf+qY1mIttQv1qS
6uwAnA6E9E12HUVvzJJQRc2x/S5iK6Vx
=6imF
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADUP for all PEAR packages

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 23/10/2012 17:45, Reindl Harald a écrit :

 because i never found all used packages as RPM

And ?
What are you waiting for ?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCGvl8ACgkQYUppBSnxahhpRQCg8GJigG2A5l/+nf0Ih+TFVJ9J
ZPoAniCMhYubYosU/tUZz+8x/DE8RpyD
=EqAl
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADUP for all PEAR packages

[Reindl Harald]

Am 23.10.2012 16:40, schrieb Remi Collet:
 For years... pear have its metadata database stored in /usr/share/pear
 
 This will move soon to /var/lib/pear (to be FHS compliant).
 (feature approved/merged by upstream)
 
 With this last change, we'll have only libraries in /usr/share/pear
 (which is part of the default php include_path)
 
 WARNING : all pear packages will be FTBFS.
 
 Very simple fix:
 
 Define the default metadata directory location
 
%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
 
 
 And instead of
# Clean up unnecessary files
rm -rf %{buildroot}%{pear_phpdir}/.??*
 
 Use
rm -rf %{buildroot}%{pear_metadir}/.??*
 
 
 This can be applied on all branches
 (already used on some of my packages, see php-phpunit-PHPUnit p.e.)

does pear update pear this also know?
in the real life mostly even as RPM packed pear
packages are updated with pear upgrade because
the RPM's are way behind by design



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADUP for all PEAR packages

[Reindl Harald]

Am 23.10.2012 17:38, schrieb Remi Collet:
 in the real life mostly even as RPM packed pear packages are
 updated with pear upgrade because the RPM's are way behind by
 design
 
 I disagree.
 
 RPM maintainers keep a consistent PEAR stack and add more QA.
 
 Before running any pear update ... you should ask why this is not
 available as RPM. I have often differ updates because new package is
 broken (or break others)

because i never found all used packages as RPM
i would be much more happy to not have any php-package
depend on pear-RPMs

my QA is test against the used software with internal
unit-tests and rsync /usr/share/pear as it is on all
other machines which is one reason more why i do not
like a additional split to /usr/share/doc/pear/
while some years ago you had to care only about one
folder to distribute

pear-updates per RPM are often enough downgrades here

Installed packages, channel pear.php.net:
=
Package  Version   State
Archive_Tar  1.3.10stable
Archive_Zip  0.1.2 beta
Auth 1.6.4 stable
Auth_HTTP2.1.8 stable
Auth_SASL1.0.6 stable
Benchmark1.2.9 stable
Cache1.5.6 stable
Cache_Lite   1.7.15stable
Config   1.10.12   stable
Console_Color1.0.3 stable
Console_Getargs  1.3.5 stable
Console_Getopt   1.3.1 stable
Console_ProgressBar  0.5.2beta beta
Console_Table1.1.4 stable
Contact_Vcard_Build  1.1.2 stable
Contact_Vcard_Parse  1.32.0stable
Crypt_Blowfish   1.0.1 stable
Crypt_CBC1.0.1 stable
Crypt_CHAP   1.5.0 stable
Crypt_DiffieHellman  0.2.6 beta
Crypt_GPG1.3.2 stable
Crypt_HMAC   1.0.1 stable
Crypt_RC41.0.3 stable
Crypt_RSA1.0.0 stable
Crypt_Xtea   1.1.0 stable
DB   1.7.14stable
Date 1.4.7 stable
Date_Holidays0.21.6alpha
Date_Holidays_Austria0.1.4 alpha
Event_Dispatcher 1.1.0 stable
File 1.4.1 stable
File_CSV 1.0.0 stable
File_CSV_DataSource  1.0.1 stable
File_DNS 0.1.0 devel
File_Find1.3.1 stable
File_IMC 0.5.0 beta
File_PDF 0.3.3 beta
File_Passwd  1.1.7 stable
File_SearchReplace   1.1.4 stable
File_Util1.0.0 stable
HTML_AJAX0.5.6 beta
HTML_BBCodeParser1.2.3 stable
HTML_CSS 1.5.4 stable
HTML_Common  1.2.5 stable
HTML_Common2 2.1.0 stable
HTML_Crypt   1.3.4 stable
HTML_Entities0.2.2 alpha
HTML_Form1.3.0 stable
HTML_Javascript  1.1.2 stable
HTML_Menu2.1.4 stable
HTML_Page2   0.6.3 beta
HTML_Progress2   2.4.2 stable
HTML_QuickForm2  2.0.0 stable
HTML_Select  1.3.1 stable
HTML_Table   1.8.3 stable
HTML_Table_Matrix1.0.10stable
HTML_TagCloud1.0.0 stable
HTML_TreeMenu1.2.2 stable
HTTP 1.4.1 stable
HTTP_Client  1.2.1 stable
HTTP_Download1.1.4 stable
HTTP_Header  1.2.1 stable
HTTP_OAuth   0.2.3 alpha
HTTP_Request 1.4.4 stable
HTTP_Request22.1.1 stable
HTTP_Session20.7.3 beta
HTTP_Upload  0.9.1 stable
I18Nv2   0.11.4beta
Image_Canvas 0.3.5 alpha
Image_Color  1.0.4 stable
Image_Color2 0.1.5 alpha
Image_Graph  0.8.0 alpha
Image_GraphViz   1.3.0 stable
Image_IPTC   1.0.2 stable
Image_JpegMarkerReader   0.5.0 beta
Image_JpegXmpReader  0.5.3 beta
Image_Puzzle 0.2.2 beta
Image_Remote 1.0.2 stable
Image_Text   0.6.1 beta
Image_Transform  0.9.5 alpha
Log  1.12.7stable
MDB2 2.5.0b3   beta
MDB2_Driver_mysql1.5.0b3   beta
MIME_Type1.3.1 stable
MP3_IDv2 0.1.8 alpha
MP3_Id   1.2.2 stable
MP3_Playlist 0.5.2 alpha
Mail 1.2.0 stable
Mail_Mime1.8.5 stable
Mail_mimeDecode  1.5.5 stable
Math_BigInteger  1.0.0 stable
Math_Stats   0.8.5 stable
Message  0.6   beta
Net_CheckIP  1.2.2 stable
Net_DNS  1.0.7 stable
Net_FTP  1.3.7 

Re: HEADUP for all PEAR packages

[Reindl Harald]

Am 23.10.2012 17:57, schrieb Remi Collet:
 Le 23/10/2012 17:45, Reindl Harald a écrit :
 
 because i never found all used packages as RPM
 
 And ?
 What are you waiting for?

what should i wait for?
pear install whatever

pear itself is a package-system which should not be wrapped
in another one - the rpm-db overhead with a lot of files
is mostly larger than the scripts itself.

only php-pear would be needed to have the pear commands
available and all would be fine if there would not be some
packages require pear-rpms



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [SOLVED] kernel 2.6.x and Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (kmod-wl)

[tim.laurid...@gmail.com]

On Tue, Oct 23, 2012 at 5:41 AM, Dario Lesca d.le...@solinos.it wrote:

 On this Asus EeePC seashell series Notebook:
 http://www.smolts.org/client/show/pub_e9f34fbb-dd9d-4b7d-8c77-027292c81297

 After kernel update to 3.6.[12] (plus relative kmod-wl* module) the WiFi
 stop work

 I have found this article:
 https://bbs.archlinux.org/viewtopic.php?pid=1176829

 then I have install the akmod driver and I have apply to .spec file this
 patch:

  [root@ludvic ~]# diff -Naur rpmbuild/SPECS/wl-kmod.spec.orig
 rpmbuild/SPECS/wl-kmod.spec
  --- rpmbuild/SPECS/wl-kmod.spec.orig2012-10-22 22:57:55.284478328
 +0200
  +++ rpmbuild/SPECS/wl-kmod.spec 2012-10-22 22:32:17.134583423 +0200
  @@ -69,7 +69,7 @@
   %build
   for kernel_version in %{?kernel_versions}; do
pushd _kmod_build_${kernel_version%%___*}
  - make -C ${kernel_version##*___} M=`pwd` modules
  + make -C ${kernel_version##*___} M=`pwd` modules API=WEXT
popd
   done

 Rebuild with rpmbuild -ba rpmbuild/SPECS/wl-kmod.spec, remove old
 module rmmod wl, uninstall and reinstall new RPMS generated, reload
 module modprobe wl, and test it:

 Now WiFi work

 Hope this help

 Many thanks

 --
 Dario Lesca - sip:da...@solinos.it
 (Inviato dal mio Linux Fedora 17 Gnome3)

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


my laptop has

03:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n
Wireless LAN Controller (rev 01)

and it works great with the 3.6.x kernel in F18 out of the box, in earlier
releases I had to use the kmod-wl driver.

Have you tried to remove all the wl stuff and see if it work without, if
you have kmod-wl installed it will black list the kernel buildin BCM4313
drivers.

You can also try to boot an F18 Live cd to check if it works. in tree
drivers is preferred over out of tree ones :)

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

Re: HEADUP for all PEAR packages

[Matthias Runge]

On 10/23/2012 06:00 PM, Reindl Harald wrote:



Am 23.10.2012 17:57, schrieb Remi Collet:

Le 23/10/2012 17:45, Reindl Harald a écrit :


because i never found all used packages as RPM


And ?
What are you waiting for?


what should i wait for?
pear install whatever

pear itself is a package-system which should not be wrapped
in another one - the rpm-db overhead with a lot of files
is mostly larger than the scripts itself.

I couldn't disagree more.
Using a centralized packaging system has the benefit to be able to 
install an exact version on all managed hosts. Show me, how to do that 
with pear.

Is pear also able to answer you: to which package belongs file ?

I'd even propose to disable other packaging systems in Fedora, or to 
change them to prompt the user:


Yes, I know this voids warranty and I'll take the risk

(or something like that).

Pear is here just a example, but there are other package systems in 
fedora as well: python-pip, I know there's something similar in ruby 
(gem?),...



--
Matthias Runge mru...@matthias-runge.de
   mru...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: R

[Richard Vickery]

On Tue, Oct 23, 2012 at 8:20 AM, Tom Callaway tcall...@redhat.com wrote:

 On 10/22/2012 09:39 PM, Richard Vickery wrote:
  sorry I mistakenly deleted the R discussion from my inbox. Here is what

 Based on your errors, I'm wondering if you're using the R packages in
 Fedora, or if you've built R from source. I did a fresh install of R:
 (yum install R R-java), then ran install.packages(JGR) and it worked
 properly. Can you please confirm how you installed R?

 The only major difference I can see is that you're on a 32bit system and
 I tested on x86_64, but that shouldn't be an issue.

 Also, confirming that you have java-1.7.0-openjdk-devel installed would
 be helpful. One of your logs showed it failing to compile rJava, and
 there is probably useful debugging in the config.log that was generated.

 Thanks,

 ~tom

 ==
 Fedora Project


I did yum install R, and I do have openjdk installed. When 18 comes out -
versus alpha, or beta - I might switching to 64 bit, at least for a while,
until I find whether I like the trade-off of stability.

To the concern whether this is a users - versus developers - list question,
I considered that, but I'm not on the users list, and at the time thought
that it might have been served better on this list. If I am on the list, it
is very quiet and I thought that to get the best people, the law of
averages suggest to post on the group with the most activity; If I am not,
I can't remember how to get on the lists. Since you can get what I want in
Windows, I thought it might be a developers issue. If you disagree, that is
fine. If you don't like the posts and think they belong somewhere else, an
/ or don't want to help, you don't have to read them. It is possible to
delete them, or have the program delete them before you even see them. I
don't see what the issue is if you don't want to see them on the list, or
if you think the R issue belongs elsewhere.

Thanks for the help Tom,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Michael Stahnke]

I am still not in favor of a puppet3 package. This is largely due to
overall compatibility.  Puppet is a distributed system.  Having the
package be called puppet in some repositories and puppet3 in others
(along with bin files/utils) will only the make the overall
user-experience of Puppet worse IMHO.

Also if the existing Puppet (2.6.x) stays out there, how would a user
know that 2.6 is no longer maintained?  Does having a second package
without an upgrade path leaves the end-user out-to-dry in the longrun?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

How do I find the maintainers of a package ?

[Alain Williams]

Hi,

when maintaining/configuring my systems I occasionally make changes that I think
would be generally useful. What is the easiest way of bringing an idea to the
attention of a package maintainer  if he likes the idea I would then collect
up  push what I have done, etc.

I have looked at the URL below, but it does not give what I want:


https://fedoraproject.org/wiki/Category:Package_Maintainers?rd=PackageMaintainers


The package that I am looking at today is dhcp. If you have more than one
interface and need different parameters on each interface the current setup does
not work - mine does and cleanly drops back to the current config.

Regards

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How do I find the maintainers of a package ?

[Jon Ciesla]

On Tue, Oct 23, 2012 at 1:39 PM, Alain Williams a...@phcomp.co.uk wrote:
 Hi,

 when maintaining/configuring my systems I occasionally make changes that I 
 think
 would be generally useful. What is the easiest way of bringing an idea to the
 attention of a package maintainer  if he likes the idea I would then 
 collect
 up  push what I have done, etc.

 I have looked at the URL below, but it does not give what I want:

 
 https://fedoraproject.org/wiki/Category:Package_Maintainers?rd=PackageMaintainers


 The package that I am looking at today is dhcp. If you have more than one
 interface and need different parameters on each interface the current setup 
 does
 not work - mine does and cleanly drops back to the current config.

File a Bug in Bugzilla at https://bugzilla.redhat.com.  It will be
assigned to the maintainer of the component you select.

-J

 Regards

 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information: 
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: Fixing Puppet in Fedora/EPEL

[Matthew Miller]

On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote:
 I am still not in favor of a puppet3 package. This is largely due to
 overall compatibility.  Puppet is a distributed system.  Having the
 package be called puppet in some repositories and puppet3 in others
 (along with bin files/utils) will only the make the overall
 user-experience of Puppet worse IMHO.
 
 Also if the existing Puppet (2.6.x) stays out there, how would a user
 know that 2.6 is no longer maintained?  Does having a second package
 without an upgrade path leaves the end-user out-to-dry in the longrun?

We can make the new package available, and do something to publicize that
there is going to be a change. When 2.6.x is no longer maintained for
security updates, the new package gets the old name and obsoletes the
temporary name.

If there's some way to put deprecation notices into the default output for
puppet, it might be worth considering that.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How do I find the maintainers of a package ?

[Nathanael D. Noblet]

On 10/23/2012 12:39 PM, Alain Williams wrote:

Hi,

when maintaining/configuring my systems I occasionally make changes that I think
would be generally useful. What is the easiest way of bringing an idea to the
attention of a package maintainer  if he likes the idea I would then collect
up  push what I have done, etc.

I have looked at the URL below, but it does not give what I want:

 
https://fedoraproject.org/wiki/Category:Package_Maintainers?rd=PackageMaintainers


The package that I am looking at today is dhcp. If you have more than one
interface and need different parameters on each interface the current setup does
not work - mine does and cleanly drops back to the current config.


You should be able to email packagename-ow...@fedoraproject.org and it 
will get to whoever owns the package. One caveat is make sure its the 
*package name* as the src.rpm would be named, not the sub-packages it 
may produce.



--
Nathanael d. Noblet
t 403.875.4613
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[Ken Dreyer]

On Tue, Oct 23, 2012 at 12:46 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 We can make the new package available, and do something to publicize that
 there is going to be a change. When 2.6.x is no longer maintained for
 security updates, the new package gets the old name and obsoletes the
 temporary name.

There will have to be a public announcement either way, so I would
prefer to have the public announcement be Puppet 3 is coming to EPEL;
please test it in updates-testing, and if you don't want it, please
block it on your local systems.

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

Re: How do I find the maintainers of a package ?

[Kevin Fenzi]

On Tue, 23 Oct 2012 12:49:01 -0600
Nathanael D. Noblet nathan...@gnat.ca wrote:

 You should be able to email packagename-ow...@fedoraproject.org and
 it will get to whoever owns the package. One caveat is make sure its
 the *package name* as the src.rpm would be named, not the
 sub-packages it may produce.

Yep. However as noted it's usually much better to file a bug. 

bugs are public, so other people can see it and provide feedback. 

bugs stay around attached to the package even if the current
maintainers are no longer able to maintain the package. New maintainers
would never have seen any email you sent directly in the past. 

It's much easier to mark bugs duplicate and such. 

Anyhow, when in doubt, please just file a bug. ;) 

kevin



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Toshio Kuratomi]

On Tue, Oct 23, 2012 at 03:44:11PM +0200, Miroslav Lichvar wrote:
 On Tue, Oct 23, 2012 at 12:52:47PM +0200, Kalev Lember wrote:
  Parallel installable guile interpreters:
  http://packages.debian.org/sid/amd64/guile-1.8/filelist
  http://packages.debian.org/sid/amd64/guile-2.0/filelist
 
 So both new and old guile scripts need to be patched to call
 the right binary? Or is there a symlink created?
 
  Conflicting -dev package:
  http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist
  http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist
 
 Jan was proposing this approach too, but I thought if some packages
 need to be patched to use the 1.8 guile paths, why not make one step
 further and patch also the paths used in building. At least, when the
 maintainers of the old packages prepare the patches, they can make
 sure if the packages still work correctly.
 
 Our packaging guidelines seem to allow (but discourage) conflicts with
 compat devel packages, if you think this will be a lot of unnecessary
 work, I'm ok with the conflict.
 

Compat Package Conflicts
It is acceptable to use Conflicts: in some cases involving compat packages.
These are the cases where it is not feasible to patch applications to look
in alternate locations for the -compat files, so the foo-devel and
foo-compat-devel packages need to Conflict:. Whenever possible, this should
be avoided.


at sonme point we should probably clarify that section I can't remember
now where we wanted the line to be drawn.  The fact that htis has been done
in SUSE and that porting is proceeding here seems to indicate that we
wouldn't want a Conflicts in this case.

-Toshio

 FWIW, the OpenSuse packages don't seem to have the conflict and their
 libguile1-devel package has the aclocal file renamed to guile1.m4.
 


pgpZjSmT6kHzu.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 17 'tig' package update change

[Jason L Tibbitts III]

 LZ == Lukas Zapletal lzap+...@redhat.com writes:

LZ Hello, I have noticed that latest tig update in Fedora 17 changed
LZ it's behavior.

tig has not ever been updated in F17; it still has the same 0.18-2
release that was there when F17 was spun.

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

Re: HEADUP for all PEAR packages

[Reindl Harald]

Am 23.10.2012 19:03, schrieb Matthias Runge:
 On 10/23/2012 06:00 PM, Reindl Harald wrote:


 Am 23.10.2012 17:57, schrieb Remi Collet:
 Le 23/10/2012 17:45, Reindl Harald a écrit :

 because i never found all used packages as RPM

 And ?
 What are you waiting for?

 what should i wait for?
 pear install whatever

 pear itself is a package-system which should not be wrapped
 in another one - the rpm-db overhead with a lot of files
 is mostly larger than the scripts itself.
 I couldn't disagree more.
 Using a centralized packaging system has the benefit to be able to install an 
 exact version on all managed hosts.
 Show me, how to do that with pear

nothing easier than that, proven on 20 production servers
and 5 development machines since 2008 while the machines
were installd with F9 and until now upgraeded with yum
to F17 - so yes i know how to manage hosts

[root@buildserver:~]$ cat /buildserver/distribute-pear.sh
#!/bin/bash
source /Volumes/dune/buildserver/server-list.txt
find /usr/share/pear/ -type d -exec /bin/chmod 0755 {} \;
find /usr/share/pear/ -type f -exec /bin/chmod 0644 {} \;
find /usr/share/doc/pear/ -type d -exec /bin/chmod 0755 {} \;
find /usr/share/doc/pear/ -type f -exec /bin/chmod 0644 {} \;
function rh_push_pear
{
 echo $1
 rsync --times \
  --progress \
  --force \
  --recursive \
  --delete-after  \
  --links --perms \
  --owner --group \
  --executability  \
  --acls  \
  --xattrs /usr/share/pear/ root@$1:/usr/share/pear/
 echo 
}
for item in ${RH_TARGET_SERVERS[*]}
do
 rh_push_pear $item
done


 Is pear also able to answer you: to which package belongs file ?

no, but that does not change the problem of having hundrets of
pear apckages and only a subset as RPM - so in the real world
you mix them which is BAD

if ALL pear packages would be in the repos this whould be
a diffeent story - but taht is unlikely because who
would maintain all this packages really?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 869160] perl-PAR-1.007 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869160

--- Comment #2 from Fedora Update System upda...@fedoraproject.org ---
Package perl-PAR-1.007-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-PAR-1.007-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16727/perl-PAR-1.007-1.fc18
then log in and leave karma (feedback).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 869158] perl-Encode-JP-Mobile-0.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869158

--- Comment #3 from Fedora Update System upda...@fedoraproject.org ---
Package perl-Encode-JP-Mobile-0.30-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing
perl-Encode-JP-Mobile-0.30-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16731/perl-Encode-JP-Mobile-0.30-1.fc18
then log in and leave karma (feedback).

-- 
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: Fixing Puppet in Fedora/EPEL

[Greg Swift]

On Tue, Oct 23, 2012 at 1:46 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote:
 I am still not in favor of a puppet3 package. This is largely due to
 overall compatibility.  Puppet is a distributed system.  Having the
 package be called puppet in some repositories and puppet3 in others
 (along with bin files/utils) will only the make the overall
 user-experience of Puppet worse IMHO.

 Also if the existing Puppet (2.6.x) stays out there, how would a user
 know that 2.6 is no longer maintained?  Does having a second package
 without an upgrade path leaves the end-user out-to-dry in the longrun?

 We can make the new package available, and do something to publicize that
 there is going to be a change. When 2.6.x is no longer maintained for
 security updates, the new package gets the old name and obsoletes the
 temporary name.

 If there's some way to put deprecation notices into the default output for
 puppet, it might be worth considering that.

An easy way would be to roll and update to the 2.6 release that logs a
deprecation error on start via the init script.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: koji errors

[Kevin Fenzi]

On Tue, 23 Oct 2012 15:57:37 +0200
Simone Caronni negativ...@gmail.com wrote:

 On 23 October 2012 15:25, Eric Sparks Christensen
 spa...@fedoraproject.org wrote:
  On Tue, Oct 23, 2012 at 5:24 AM, Simone Caronni
  negativ...@gmail.com wrote:
  Hello,
 
  yesterday I had some invalid channel policy errors when trying to
  build packages with koji. Tasks were never ending with the
  building status on.
  I canceled the builds after few hours and today I tried again to
  build them.
 
  The jobs always fail because I have errors like the following (3
  packages, fc18 went fine):
 
  I, too, had these problems building cqrlog for fc17.  Not sure
  what's going on.
 
 I just received the broken deps mail for the package I can't
 build...
 
 Is there any way to force delete a specific n-v-r from koji?

There was some issues yesterday when we were trying to adjust some
permissions. ;( 

If you have builds that are in a weird state like above, can you please
file a rel-eng trac ticket with pointers to the exact builds and we can
get them cleaned up. 

https://fedorahosted.org/rel-eng/newticket

Sorry for the trouble. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADUP for all PEAR packages

[Nathanael D. Noblet]

On 10/23/2012 08:40 AM, Remi Collet wrote:

For years... pear have its metadata database stored in /usr/share/pear

This will move soon to /var/lib/pear (to be FHS compliant).
(feature approved/merged by upstream)

With this last change, we'll have only libraries in /usr/share/pear
(which is part of the default php include_path)

WARNING : all pear packages will be FTBFS.

Very simple fix:

Define the default metadata directory location

%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}


And instead of
# Clean up unnecessary files
rm -rf %{buildroot}%{pear_phpdir}/.??*

Use
rm -rf %{buildroot}%{pear_metadir}/.??*


This can be applied on all branches
(already used on some of my packages, see php-phpunit-PHPUnit p.e.)


I presume php-pecl packages are un-affected by this?


--
Nathanael d. Noblet
t 403.875.4613
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing Puppet in Fedora/EPEL

[John . Florian]

 From: Greg Swift xa...@fedoraproject.org
 To: Development discussions related to Fedora 
devel@lists.fedoraproject.org
 Date: 10/23/2012 15:51
 Subject: Re: Fixing Puppet in Fedora/EPEL
 Sent by: devel-boun...@lists.fedoraproject.org
 
 On Tue, Oct 23, 2012 at 1:46 PM, Matthew Miller
 mat...@fedoraproject.org wrote:
  On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote:
  I am still not in favor of a puppet3 package. This is largely due to
  overall compatibility.  Puppet is a distributed system.  Having the
  package be called puppet in some repositories and puppet3 in others
  (along with bin files/utils) will only the make the overall
  user-experience of Puppet worse IMHO.
 
  Also if the existing Puppet (2.6.x) stays out there, how would a user
  know that 2.6 is no longer maintained?  Does having a second package
  without an upgrade path leaves the end-user out-to-dry in the 
longrun?
 
  We can make the new package available, and do something to publicize 
that
  there is going to be a change. When 2.6.x is no longer maintained for
  security updates, the new package gets the old name and obsoletes the
  temporary name.
 
  If there's some way to put deprecation notices into the default output 
for
  puppet, it might be worth considering that.
 
 An easy way would be to roll and update to the 2.6 release that logs a
 deprecation error on start via the init script.

And ideally the message would also land in the tagmail deliveries once 
upon first catalog compilation after the puppet master is restarted -- 
much like the 2.7 deprecation notice for dynamically scoped variables was 
handled.  That was a very nice compromise between (1) you should see this 
and (2) not being annoying about it.  I would personally like to see the 
puppet folks adopt something like this as an ongoing policy for all 
deprecations/obsoletions with as much as advance notice as reasonably 
possible.

--
John Florian

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

Re: fedpkg / koji error

[Thorsten Leemhuis]

Lo!

On 23.10.2012 17:23, Tom Callaway wrote:

On 10/22/2012 10:37 PM, Ralf Corsepius wrote:

On 10/22/2012 10:43 PM, Tom Callaway wrote:

On 10/22/2012 12:09 PM, Ralf Corsepius wrote:

There is currently no way to undefine a macro at the rpm commandline,


rpmbuild --define  %{nil} ?


Huh, I swear I knew that once. :) Attached is a patch to use the %{nil}
behavior instead of setting the unused dist macro to 0. I smoke tested
and confirmed that the %{rhel} macro is unset on Fedora with this patch
applied.


I haven't tried your patch, but don't you have to unset/define %{nil}
all build-host related rpm macros from /etc/rpm/macros.dist?

It's at least what I can not avoid doing in my before-mentioned
build-scripts.

I.e. when running my script on Fedora 17, I invoke rpmbuild this way:

rpmbuild ... \
  --define fedora %{nil} --define fc17 %{nil}
  --define dist .el6 --define rhel 6  --define el6 1
  ...

Otherwise constructs such as
%{?fc17:}
%{?el6:}
also won't work correctly in rpm.specs.

IIUC, fedpkg with your patch sets %dist and unsets %fedora, but it
doesn't seem to catch fc17.


Yeah, thats a valid corner case. It wasn't in the original issue, so I
didn't think about it. I'll work on a fix that covers that as well.


Spot: Thanks for working on this and finding a solution that removes the 
inconsistency I was running into with someone else package.


Ralf: Thanks for the idea with the %{nil}

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

Re: Fixing Puppet in Fedora/EPEL

[Adam Williamson]

On Tue, 2012-10-23 at 15:47 +0200, Vít Ondruch wrote:

 Once you introduce version into the name, you will never be able to get 
 rid of it,

Of course you can. In fact we've done this more than once in Fedora.
There was a gtk+3 package parallel installable with with 'gtk+' (which
was a 2.x version) for a while; now 'gtk+' is 3.x. It's not a problem at
all from a packaging perspective.
-- 
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: Fixing Puppet in Fedora/EPEL

[Jan-Frode Myklebust]

On Sat, Oct 20, 2012 at 1:04 AM, Michael Stahnke stah...@puppetlabs.com wrote:
 Puppet in the Fedora/EPEL ecosystem is a bit wonky currently.

 I'd really like to fix it.

 Problems:
 * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x.  2.7.x is not
   100% compatible with 1.9.3. The number of issues in this space continues to
   grow.

 * Puppet 3.0.x is out and is the fully supported branch from Puppet Labs and
   supports Ruby 1.9.3+ fully.


 My proposal would be the following:
 * Move EPEL 6, Fedora = 17 to use Puppet 3.0.

What about ruby on RHEL6? Will puppet 3.0 work with RHEL6's ruby
1.8.7, or do you expect RHEL6 users to replace the distro native ruby
stack ?



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

Re: How do I find the maintainers of a package ?

[Adam Williamson]

On Tue, 2012-10-23 at 19:39 +0100, Alain Williams wrote:
 Hi,
 
 when maintaining/configuring my systems I occasionally make changes that I 
 think
 would be generally useful. What is the easiest way of bringing an idea to the
 attention of a package maintainer  if he likes the idea I would then 
 collect
 up  push what I have done, etc.
 
 I have looked at the URL below, but it does not give what I want:
 
 
 https://fedoraproject.org/wiki/Category:Package_Maintainers?rd=PackageMaintainers
 
 
 The package that I am looking at today is dhcp. If you have more than one
 interface and need different parameters on each interface the current setup 
 does
 not work - mine does and cleanly drops back to the current config.

In addition to all the other answers covering the right way to do
things, a couple of other options...

If you really want to *know who the maintainer is* - not just contact
'the maintainer' and wait for them to get back - you can check it at
https://admin.fedoraproject.org/pkgdb/ .
https://admin.fedoraproject.org/pkgdb/acls/name/dhcp tells you the owner
is jpopelka.

That's the 'right way'. Or you can do the AdamW Patented Dumb Fast Way:

rpm -q --changelog dhcp-client | less

and see who makes the most commits to the package, then mail that
person. Even if they're not technically the package owner...they're
probably the person you want.
-- 
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: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Adam Williamson]

On Tue, 2012-10-23 at 12:17 -0700, Toshio Kuratomi wrote:

 
 Compat Package Conflicts
 It is acceptable to use Conflicts: in some cases involving compat packages.
 These are the cases where it is not feasible to patch applications to look
 in alternate locations for the -compat files, so the foo-devel and
 foo-compat-devel packages need to Conflict:. Whenever possible, this should
 be avoided.
 
 
 at sonme point we should probably clarify that section I can't remember
 now where we wanted the line to be drawn.  The fact that htis has been done
 in SUSE and that porting is proceeding here seems to indicate that we
 wouldn't want a Conflicts in this case.

That's funny, I was going to say the opposite...I think we should
clarify it to say that in the cases where it makes sense to have a
libfoo-compat package, there's no need to bend over backwards to try and
make libfoo-devel and libfoo-compat-devel be parallel installable,
because there's just no important use case for it. There is no reason
you'd need to compile one code base against two different versions of
the same library, so there's no case where you would need to have both
-devel packages installed simultaneously.

I think we should be strict about trying not to package multiple majors
of the same library wherever possible, but where it's pretty much
unavoidable, I think it's perfectly fine for the -devel packages to
conflict. In fact I think it's better to leave them conflicting than to
hack them up with patches to make them not conflict; that's always going
to be a hack job, nothing clean. The library thinks it's called libfoo,
not libfoo2 or libfoo-compat. I think the guidelines should reflect
this...they should explicitly say that a -devel package conflict is fine
and indeed recommended in the specific case of packaging multiple majors
of a single library.
-- 
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: HEADUP for all PEAR packages

[Adam Williamson]

On Tue, 2012-10-23 at 21:42 +0200, Reindl Harald wrote:

 if ALL pear packages would be in the repos this whould be
 a diffeent story - but taht is unlikely because who
 would maintain all this packages really?

It seems like something that should be automatable, really. Don't we
already have this, to some degree? The layout, contents and build
process for PEAR packages is standardized, AIUI, so they can use
virtually the same spec file and bumps should be entirely automatable in
the vast majority of cases.

Would it be super-hard to just write a bot that does PEAR package builds
and updates? That seems like it'd mostly solve the problem.
-- 
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: Fixing Puppet in Fedora/EPEL

[Michael Stahnke]

On Tue, Oct 23, 2012 at 2:50 PM, Jan-Frode Myklebust janfr...@tanso.net wrote:
 On Sat, Oct 20, 2012 at 1:04 AM, Michael Stahnke stah...@puppetlabs.com 
 wrote:
 Puppet in the Fedora/EPEL ecosystem is a bit wonky currently.

 I'd really like to fix it.

 Problems:
 * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x.  2.7.x is 
 not
   100% compatible with 1.9.3. The number of issues in this space continues to
   grow.

 * Puppet 3.0.x is out and is the fully supported branch from Puppet Labs and
   supports Ruby 1.9.3+ fully.


 My proposal would be the following:
 * Move EPEL 6, Fedora = 17 to use Puppet 3.0.

 What about ruby on RHEL6? Will puppet 3.0 work with RHEL6's ruby
 1.8.7, or do you expect RHEL6 users to replace the distro native ruby
 stack ?
1.8.7 is fully supported in Puppet 3.0



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

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Toshio Kuratomi]

On Tue, Oct 23, 2012 at 02:58:28PM -0700, Adam Williamson wrote:
 On Tue, 2012-10-23 at 12:17 -0700, Toshio Kuratomi wrote:
 
  
  Compat Package Conflicts
  It is acceptable to use Conflicts: in some cases involving compat packages.
  These are the cases where it is not feasible to patch applications to look
  in alternate locations for the -compat files, so the foo-devel and
  foo-compat-devel packages need to Conflict:. Whenever possible, this should
  be avoided.
  
  
  at sonme point we should probably clarify that section I can't remember
  now where we wanted the line to be drawn.  The fact that htis has been done
  in SUSE and that porting is proceeding here seems to indicate that we
  wouldn't want a Conflicts in this case.
 
 That's funny, I was going to say the opposite...I think we should
 clarify it to say that in the cases where it makes sense to have a
 libfoo-compat package, there's no need to bend over backwards to try and
 make libfoo-devel and libfoo-compat-devel be parallel installable,
 because there's just no important use case for it. There is no reason
 you'd need to compile one code base against two different versions of
 the same library, so there's no case where you would need to have both
 -devel packages installed simultaneously.
 
 I think we should be strict about trying not to package multiple majors
 of the same library wherever possible, but where it's pretty much
 unavoidable, I think it's perfectly fine for the -devel packages to
 conflict. In fact I think it's better to leave them conflicting than to
 hack them up with patches to make them not conflict; that's always going
 to be a hack job, nothing clean. The library thinks it's called libfoo,
 not libfoo2 or libfoo-compat. I think the guidelines should reflect
 this...they should explicitly say that a -devel package conflict is fine
 and indeed recommended in the specific case of packaging multiple majors
 of a single library.

Feel free to submit a draft -- the conflicts guidelines haen't been worked
on in several years so there's many new people  on the FPC.  I believe
that mschwendt was one of the people who had a lot of influence on the
current guideline if you'd like to get some feedback on your draft.

-Toshio


pgp2RagPIWTsS.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Adam Williamson]

On Tue, 2012-10-23 at 16:25 -0700, Toshio Kuratomi wrote:
 On Tue, Oct 23, 2012 at 02:58:28PM -0700, Adam Williamson wrote:
  On Tue, 2012-10-23 at 12:17 -0700, Toshio Kuratomi wrote:
  
   
   Compat Package Conflicts
   It is acceptable to use Conflicts: in some cases involving compat 
   packages.
   These are the cases where it is not feasible to patch applications to look
   in alternate locations for the -compat files, so the foo-devel and
   foo-compat-devel packages need to Conflict:. Whenever possible, this 
   should
   be avoided.
   
   
   at sonme point we should probably clarify that section I can't 
   remember
   now where we wanted the line to be drawn.  The fact that htis has been 
   done
   in SUSE and that porting is proceeding here seems to indicate that we
   wouldn't want a Conflicts in this case.
  
  That's funny, I was going to say the opposite...I think we should
  clarify it to say that in the cases where it makes sense to have a
  libfoo-compat package, there's no need to bend over backwards to try and
  make libfoo-devel and libfoo-compat-devel be parallel installable,
  because there's just no important use case for it. There is no reason
  you'd need to compile one code base against two different versions of
  the same library, so there's no case where you would need to have both
  -devel packages installed simultaneously.
  
  I think we should be strict about trying not to package multiple majors
  of the same library wherever possible, but where it's pretty much
  unavoidable, I think it's perfectly fine for the -devel packages to
  conflict. In fact I think it's better to leave them conflicting than to
  hack them up with patches to make them not conflict; that's always going
  to be a hack job, nothing clean. The library thinks it's called libfoo,
  not libfoo2 or libfoo-compat. I think the guidelines should reflect
  this...they should explicitly say that a -devel package conflict is fine
  and indeed recommended in the specific case of packaging multiple majors
  of a single library.
 
 Feel free to submit a draft -- the conflicts guidelines haen't been worked
 on in several years so there's many new people  on the FPC.  I believe
 that mschwendt was one of the people who had a lot of influence on the
 current guideline if you'd like to get some feedback on your draft.

Well, I don't mind doing that, but I'd like to be sure there's a broad
consensus that this is the way to go first. I don't think 'duelling
drafts' is the best way to decide on what direction to go; I'd rather
make sure we agree on the direction first, and use the drafting process
simply to refine how we express that direction.
-- 
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: Review swaps

[Ankur Sinha]

On Sun, 2012-10-21 at 14:46 +0200, Brendan Jones wrote:
 Hi all
 
 I have a number of outstanding reviews that are available for swap.
 All 
 are fairly trivial so shouldn't take too much time:

Hey Brendan,

 
 ams - ALSA Modular Synth - a port from the CCRMA repo
 https://bugzilla.redhat.com/show_bug.cgi?id=866358 

I'll review this one. Could you please review:

octave-odepkg - A package for solving ordinary differential equations
and more 

https://bugzilla.redhat.com/show_bug.cgi?id=869469

It should be pretty straight forward too.

-- 
Thanks, 
Warm regards,
Ankur: FranciscoD

Please only print if necessary. 

Looking to contribute to Fedora? Look here: 
https://fedoraproject.org/wiki/Fedora_Join_SIG

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADUP for all PEAR packages

[Mathieu Bridon]

On Wednesday, October 24, 2012 06:04 AM, Adam Williamson wrote:

On Tue, 2012-10-23 at 21:42 +0200, Reindl Harald wrote:


if ALL pear packages would be in the repos this whould be
a diffeent story - but taht is unlikely because who
would maintain all this packages really?


It seems like something that should be automatable, really. Don't we
already have this, to some degree? The layout, contents and build
process for PEAR packages is standardized, AIUI, so they can use
virtually the same spec file and bumps should be entirely automatable in
the vast majority of cases.

Would it be super-hard to just write a bot that does PEAR package builds
and updates? That seems like it'd mostly solve the problem.


You'd still have to review the license of the sources before actually 
pushing the package.



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

[Test-Announce] 2012-10-24 @ 16:00 UTC - F18 Beta Blocker Bug Review #5

[Tim Flink]

# F18 Beta Blocker Review meeting #5
# Date: 2012-10-24
# Time: 16:00 UTC [1] (12:00 EDT, 09:00 PDT)
# Location: #fedora-qa on irc.freenode.net

Keeping with what we've done for the last couple of weeks, we're
planning to stop around the 3 hour mark if we're not done by then and
resume on 2012-10-25.

We'll be running through the beta blockers and nice-to-haves. The
current list of blocker bugs is available at:
http://qa.fedoraproject.org/blockerbugs/current

We'll be reviewing the bugs to determine ...

1. Whether they meet the Beta release criteria [1] and should stay
 on the list
2. Whether they are getting the attention they need

[1] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria

For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process 

For the blocker review meeting protocol, see
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting


signature.asc
Description: PGP 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

Re: Fixing Puppet in Fedora/EPEL

[Vít Ondruch]

Dne 23.10.2012 17:21, Matthew Miller napsal(a):

Once you introduce version into the name, you will never be able to
get rid of it, although puppet 4 might be 100% compatible with

That's not true. In the future, puppet can obsolete puppet3 -- for example,
in EPEL 7.



Yes, it can, but I doubt it will happen, because the arguments will be 
similar there are users which have scripts which has hardcoded puppet3 
for some reason and it might break.



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

Re: HEADUP for all PEAR packages

[Remi Collet]

Le 23/10/2012 23:02, Nathanael D. Noblet a écrit :

 I presume php-pecl packages are un-affected by this?

Right.


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

[Bug 869158] New: perl-Encode-JP-Mobile-0.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869158

Bug ID: 869158
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Assignee: ppi...@redhat.com
   Summary: perl-Encode-JP-Mobile-0.30 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-Encode-JP-Mobile
   Product: Fedora

Latest upstream release: 0.30
Current version in Fedora Rawhide: 0.29
URL: http://search.cpan.org/dist/Encode-JP-Mobile/

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

-- 
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 869160] New: perl-PAR-1.007 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869160

Bug ID: 869160
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Assignee: mmasl...@redhat.com
   Summary: perl-PAR-1.007 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-PAR
   Product: Fedora

Latest upstream release: 1.007
Current version in Fedora Rawhide: 1.006
URL: http://search.cpan.org/dist/PAR/

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

-- 
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 869162] New: perl-POE-Component-Server-SimpleHTTP-2.16 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869162

Bug ID: 869162
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com
  Assignee: psab...@redhat.com
   Summary: perl-POE-Component-Server-SimpleHTTP-2.16 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-POE-Component-Server-SimpleHTTP
   Product: Fedora

Latest upstream release: 2.16
Current version in Fedora Rawhide: 2.14
URL: http://search.cpan.org/dist/POE-Component-Server-SimpleHTTP/

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

-- 
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 869164] New: perl-XML-LibXML-2.0008 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869164

Bug ID: 869164
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Assignee: mmasl...@redhat.com
   Summary: perl-XML-LibXML-2.0008 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-XML-LibXML
   Product: Fedora

Latest upstream release: 2.0008
Current version in Fedora Rawhide: 2.0007
URL: http://search.cpan.org/dist/XML-LibXML/

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

-- 
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 869158] perl-Encode-JP-Mobile-0.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869158

--- Comment #1 from Petr Pisar ppi...@redhat.com ---
This release fixes internal tests. Suitable for F≥18.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Encode-JP-Mobile-0.30.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-Encode-JP-Mobile:

9bc17f7979be5fcf2de912ae1ceb0f25  Encode-JP-Mobile-0.30.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-Encode-JP-Mobile] 0.30 bump

[Petr Pisar]

commit 5aebf3c9c44c5d08a77e6c31d019c3e88e680fe1
Author: Petr Písař ppi...@redhat.com
Date:   Tue Oct 23 09:56:53 2012 +0200

0.30 bump

 .gitignore |1 +
 perl-Encode-JP-Mobile.spec |5 -
 sources|2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 82f4ef9..101cb32 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /Encode-JP-Mobile-0.28.tar.gz
 /Encode-JP-Mobile-0.29.tar.gz
+/Encode-JP-Mobile-0.30.tar.gz
diff --git a/perl-Encode-JP-Mobile.spec b/perl-Encode-JP-Mobile.spec
index 460960c..685e319 100644
--- a/perl-Encode-JP-Mobile.spec
+++ b/perl-Encode-JP-Mobile.spec
@@ -1,5 +1,5 @@
 Name:   perl-Encode-JP-Mobile
-Version:0.29
+Version:0.30
 Release:1%{?dist}
 Summary:Japan mobile phone Shift_JIS (CP932) / UTF-8 encoding
 Summary(ja_JP): 日本の携帯電話向け Shift_JIS (CP932) / UTF-8 エンコーディング
@@ -63,6 +63,9 @@ make test
 %{perl_vendorarch}/*
 
 %changelog
+* Tue Oct 23 2012 Petr Pisar ppi...@redhat.com - 0.30-1
+- 0.30 bump
+
 * Wed Oct 17 2012 Petr Pisar ppi...@redhat.com - 0.29-1
 - 0.29 bump
 
diff --git a/sources b/sources
index 2b10aec..3a11467 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4fb8039848589605650429da578d2f97  Encode-JP-Mobile-0.29.tar.gz
+9bc17f7979be5fcf2de912ae1ceb0f25  Encode-JP-Mobile-0.30.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-Encode-JP-Mobile/f18] 0.30 bump

[Petr Pisar]

Summary of changes:

  5aebf3c... 0.30 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 869158] perl-Encode-JP-Mobile-0.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869158

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Encode-JP-Mobile-0.30-
   ||1.fc19

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

Re: [Fedora-packaging] [perl-Coro] Work-aroung missing libecb package on build-triggering host

[Rex Dieter]

On 10/22/2012 10:06 AM, Ralf Corsepius wrote:

On 10/22/2012 03:47 PM, Petr Pisar wrote:

commit e00f8293097f8331883f1df35f74be70fbb290b9
Author: Petr Písař ppi...@redhat.com
Date:   Mon Oct 22 15:46:27 2012 +0200

 Work-aroung missing libecb package on build-triggering host

  perl-Coro.spec |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Coro.spec b/perl-Coro.spec
index 50a855d..31589a5 100644
--- a/perl-Coro.spec
+++ b/perl-Coro.spec
@@ -35,7 +35,7 @@ Requires:   perl(EV) = 3
  Requires:   perl(Event) = 1.08
  Requires:   perl(Guard) = 0.5
  Requires:   perl(Storable) = 2.15
-Provides:   bundled(libecb) = %(rpm -q libecb --qf '%{VERSION}')
+Provides:   bundled(libecb)%(rpm -q libecb --qf ' = %{VERSION}'
2/dev/null)


I could be wrong, but IIRC, calling rpm inside of rpm specs is not
allowed in Fedora.

Apart of this, what you are doing is rendering your built
non-deterministic - Another strictly forbidden item.


Agreed.  What you're trying to say essentially is that the bundled 
libecb version matches the system/non-bundled version, which really 
doesn't make any sense.  I'd suggest you simply remove the versioning 
(or list the real bundled version some other way).


-- rex


--
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 869158] perl-Encode-JP-Mobile-0.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869158

--- Comment #2 from Fedora Update System upda...@fedoraproject.org ---
perl-Encode-JP-Mobile-0.30-1.fc18 has been submitted as an update for Fedora
18.
https://admin.fedoraproject.org/updates/perl-Encode-JP-Mobile-0.30-1.fc18

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File PAR-1.007.tar.gz uploaded to lookaside cache by psabata

[Petr Šabata]

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

eff0397dc552f52f071908f3cc178637  PAR-1.007.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-PAR] 1.007 bump

[Petr Šabata]

commit bdd07be82bcfb70b6fcfe64c544f8312f7d53132
Author: Petr Šabata con...@redhat.com
Date:   Tue Oct 23 10:23:24 2012 +0200

1.007 bump

 .gitignore|1 +
 perl-PAR.spec |5 -
 sources   |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8e411b5..bf427a3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ PAR-1.000.tar.gz
 /PAR-1.004.tar.gz
 /PAR-1.005.tar.gz
 /PAR-1.006.tar.gz
+/PAR-1.007.tar.gz
diff --git a/perl-PAR.spec b/perl-PAR.spec
index 19536e4..ea94b61 100644
--- a/perl-PAR.spec
+++ b/perl-PAR.spec
@@ -1,5 +1,5 @@
 Name:   perl-PAR
-Version:1.006
+Version:1.007
 Release:1%{?dist}
 Summary:Perl Archive Toolkit
 License:GPL+ or Artistic
@@ -42,6 +42,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Oct 23 2012 Petr Šabata con...@redhat.com - 1.007-1
+- 1.007 bugfix bump
+
 * Mon Oct 15 2012 Petr Šabata con...@redhat.com - 1.006-1
 - 1.006 bump
 - Drop command macros
diff --git a/sources b/sources
index 004e773..ce2ff69 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5738c81781336c58567fdac63d35b3b1  PAR-1.006.tar.gz
+eff0397dc552f52f071908f3cc178637  PAR-1.007.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-PAR/f18] (2 commits) ...1.007 bump

[Petr Šabata]

Summary of changes:

  9471aac... 1.006 bump (*)
  bdd07be... 1.007 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 869164] perl-XML-LibXML-2.0008 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869164

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||psab...@redhat.com
   Assignee|mmasl...@redhat.com |psab...@redhat.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File POE-Component-Server-SimpleHTTP-2.16.tar.gz uploaded to lookaside cache by psabata

[Petr Šabata]

A file has been added to the lookaside cache for 
perl-POE-Component-Server-SimpleHTTP:

d7a3791b473f095aac3ac9f1632ca35e  POE-Component-Server-SimpleHTTP-2.16.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-POE-Component-Server-SimpleHTTP] 2.16 bump

[Petr Šabata]

commit 2f9ef048b4af4de56e806fbadd43033bd28e42b5
Author: Petr Šabata con...@redhat.com
Date:   Tue Oct 23 10:27:45 2012 +0200

2.16 bump

 .gitignore|1 +
 perl-POE-Component-Server-SimpleHTTP.spec |7 +--
 sources   |2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c1ed5a0..db74a78 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 POE-Component-Server-SimpleHTTP-2.04.tar.gz
 /POE-Component-Server-SimpleHTTP-2.06.tar.gz
 /POE-Component-Server-SimpleHTTP-2.14.tar.gz
+/POE-Component-Server-SimpleHTTP-2.16.tar.gz
diff --git a/perl-POE-Component-Server-SimpleHTTP.spec 
b/perl-POE-Component-Server-SimpleHTTP.spec
index cec7e10..f5bd936 100644
--- a/perl-POE-Component-Server-SimpleHTTP.spec
+++ b/perl-POE-Component-Server-SimpleHTTP.spec
@@ -1,7 +1,7 @@
 Name:   perl-POE-Component-Server-SimpleHTTP
 # Use two digit pricision since 2.04 version
-Version:2.14
-Release:3%{?dist}
+Version:2.16
+Release:1%{?dist}
 Summary:Serve HTTP requests in POE
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -73,6 +73,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Oct 23 2012 Petr Šabata con...@redhat.com - 2.16-1
+- 2.16 bump (Module::Install updated)
+
 * Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 2.14-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
diff --git a/sources b/sources
index e159310..d6ee485 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fa8f96d80083cb0cfbb54248a9160330  POE-Component-Server-SimpleHTTP-2.14.tar.gz
+d7a3791b473f095aac3ac9f1632ca35e  POE-Component-Server-SimpleHTTP-2.16.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 Module-ScanDeps-1.10.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-Module-ScanDeps:

f01f36a25bf372712ff6b1e4aad8d89c  Module-ScanDeps-1.10.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 869160] perl-PAR-1.007 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869160

--- Comment #1 from Fedora Update System upda...@fedoraproject.org ---
perl-PAR-1.007-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/perl-PAR-1.007-1.fc18

-- 
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 869162] perl-POE-Component-Server-SimpleHTTP-2.16 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=869162

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-POE-Component-Server-S
   ||impleHTTP-2.16-1.fc19
 Resolution|--- |RAWHIDE
Last Closed||2012-10-23 04:51:39

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Module-ScanDeps] 1.10 bump

[Petr Pisar]

commit 7d6ded30c43458ac72bf1c782859ab10d49e71b7
Author: Petr Písař ppi...@redhat.com
Date:   Tue Oct 23 10:37:45 2012 +0200

1.10 bump

 .gitignore|1 +
 perl-Module-ScanDeps.spec |   11 +++
 sources   |2 +-
 3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index bf679e8..10f8bf8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Module-ScanDeps-0.97.tar.gz
 /Module-ScanDeps-1.06.tar.gz
 /Module-ScanDeps-1.07.tar.gz
 /Module-ScanDeps-1.08.tar.gz
+/Module-ScanDeps-1.10.tar.gz
diff --git a/perl-Module-ScanDeps.spec b/perl-Module-ScanDeps.spec
index 07abcbd..e5a7537 100644
--- a/perl-Module-ScanDeps.spec
+++ b/perl-Module-ScanDeps.spec
@@ -1,7 +1,7 @@
 Name:   perl-Module-ScanDeps
 Summary:Recursively scan Perl code for dependencies
-Version:1.08
-Release:3%{?dist}
+Version:1.10
+Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RS/RSCHUPP/Module-ScanDeps-%{version}.tar.gz
 
@@ -14,7 +14,7 @@ BuildRequires:  perl(Cwd)
 BuildRequires:  perl(DynaLoader)
 BuildRequires:  perl(Encode)
 BuildRequires:  perl(Exporter)
-BuildRequires:  perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires:  perl(ExtUtils::MakeMaker) = 6.59
 BuildRequires:  perl(File::Basename)
 BuildRequires:  perl(File::Find)
 BuildRequires:  perl(File::Path)
@@ -45,7 +45,7 @@ Requires:   perl(version)
 
 %description
 This module scans potential modules used by perl programs and returns a
-hash reference.  Its keys are the module names as appears in %INC (e.g.
+hash reference.  Its keys are the module names as appears in %%INC (e.g.
 Test/More.pm).  The values are hash references.
 
 %prep
@@ -72,6 +72,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Oct 23 2012 Petr Pisar ppi...@redhat.com - 1.10-1
+- 1.10 bump
+
 * Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.08-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
diff --git a/sources b/sources
index c10bf1a..ad20d82 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2b3d20c2f11fd60878d4308d0f35df65  Module-ScanDeps-1.08.tar.gz
+f01f36a25bf372712ff6b1e4aad8d89c  Module-ScanDeps-1.10.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-Module-ScanDeps] Modernize spec file

[Petr Pisar]

commit 3cec759fa5d3fb41620fd71e05823602b09a9ea0
Author: Petr Písař ppi...@redhat.com
Date:   Tue Oct 23 10:38:41 2012 +0200

Modernize spec file

 perl-Module-ScanDeps.spec |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)
---
diff --git a/perl-Module-ScanDeps.spec b/perl-Module-ScanDeps.spec
index e5a7537..4f172fe 100644
--- a/perl-Module-ScanDeps.spec
+++ b/perl-Module-ScanDeps.spec
@@ -41,7 +41,6 @@ Requires:   perl(version)
 
 
 %{?perl_default_filter}
-%{?perl_default_subpackage_tests}
 
 %description
 This module scans potential modules used by perl programs and returns a
@@ -56,9 +55,8 @@ Test/More.pm).  The values are hash references.
 make %{?_smp_mflags}
 
 %install
-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}/*
 
 %check
--
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-Module-ScanDeps] Unbundle inc/* and correct dependencies

[Petr Pisar]

commit a2f0e0160147322b3149c92070e9158331453c69
Author: Petr Písař ppi...@redhat.com
Date:   Tue Oct 23 11:29:46 2012 +0200

Unbundle inc/* and correct dependencies

 perl-Module-ScanDeps.spec |   30 --
 1 files changed, 16 insertions(+), 14 deletions(-)
---
diff --git a/perl-Module-ScanDeps.spec b/perl-Module-ScanDeps.spec
index 4f172fe..2743f2a 100644
--- a/perl-Module-ScanDeps.spec
+++ b/perl-Module-ScanDeps.spec
@@ -6,15 +6,18 @@ License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RS/RSCHUPP/Module-ScanDeps-%{version}.tar.gz
 
 URL:http://search.cpan.org/dist/Module-ScanDeps/
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
 BuildArch:  noarch
 
+BuildRequires:  perl(inc::Module::Install) = 1.00
+# Run-time:
+BuildRequires:  perl(B)
 BuildRequires:  perl(Config)
+BuildRequires:  perl(constant)
 BuildRequires:  perl(Cwd)
+BuildRequires:  perl(Data::Dumper)
 BuildRequires:  perl(DynaLoader)
 BuildRequires:  perl(Encode)
 BuildRequires:  perl(Exporter)
-BuildRequires:  perl(ExtUtils::MakeMaker) = 6.59
 BuildRequires:  perl(File::Basename)
 BuildRequires:  perl(File::Find)
 BuildRequires:  perl(File::Path)
@@ -22,22 +25,18 @@ BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(File::Temp)
 BuildRequires:  perl(FileHandle)
 BuildRequires:  perl(Module::Build::ModuleInfo)
-BuildRequires:  perl(Module::Pluggable)
-BuildRequires:  perl(Test::More)
-BuildRequires:  perl(Test::Pod)
-BuildRequires:  perl(constant)
-BuildRequires:  perl(prefork)
 BuildRequires:  perl(vars)
 BuildRequires:  perl(version)
-
-Requires:   perl(DynaLoader)
+# Tests:
+BuildRequires:  perl(lib)
+BuildRequires:  perl(prefork)
+BuildRequires:  perl(Test::More)
+# Optional tests:
+BuildRequires:  perl(Module::Pluggable)
+BuildRequires:  perl(Test::Pod) = 1.00
+Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
 Requires:   perl(Encode)
-Requires:   perl(Exporter)
 Requires:   perl(File::Find)
-Requires:   perl(File::Spec)
-Requires:   perl(File::Temp)
-Requires:   perl(Module::Build::ModuleInfo)
-Requires:   perl(version)
 
 
 %{?perl_default_filter}
@@ -49,6 +48,9 @@ Test/More.pm).  The values are hash references.
 
 %prep
 %setup -q -n Module-ScanDeps-%{version}
+# Remove bundled modules
+rm -rf inc/*
+sed -i '/^inc\//d' MANIFEST
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
--
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