date:20131022

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

Bug ID: 1021852
   Summary: perl-HTML-Template-2.95 is available
   Product: Fedora
   Version: rawhide
 Component: perl-HTML-Template
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org,
tcall...@redhat.com



Latest upstream release: 2.95
Current version/release in Fedora Rawhide: 2.94-4.fc20
URL: http://search.cpan.org/dist/HTML-Template/

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.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=U3cBmupsfma=cc_unsubscribe
--
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: Fwd: Broken dependencies: tika mvn(org.bouncycastle:bc*-jdk16:1.46)

2013-10-22 Thread Stanislav Ochotnicky

Quoting punto...@libero.it (2013-10-21 23:32:47)
 
 any ideas?
 thanks
 regards
 
  Messaggio originale 
 Oggetto:Broken dependencies: tika
 Data:   Mon, 21 Oct 2013 21:01:15 + (UTC)
 Mittente:   build...@fedoraproject.org
 A:  tika-ow...@fedoraproject.org
 
 
 
 tika has broken dependencies in the rawhide tree:
 On x86_64:
 tika-parsers-1.4-2.fc21.noarch requires 
 mvn(org.bouncycastle:bcprov-jdk16:1.46)
 tika-parsers-1.4-2.fc21.noarch requires 
 mvn(org.bouncycastle:bcmail-jdk16:1.46)
 On i386:
 tika-parsers-1.4-2.fc21.noarch requires 
 mvn(org.bouncycastle:bcprov-jdk16:1.46)
 tika-parsers-1.4-2.fc21.noarch requires 
 mvn(org.bouncycastle:bcmail-jdk16:1.46)
 On armhfp:
 tika-parsers-1.4-2.fc21.noarch requires 
 mvn(org.bouncycastle:bcprov-jdk16:1.46)
 tika-parsers-1.4-2.fc21.noarch requires 
 mvn(org.bouncycastle:bcmail-jdk16:1.46)
 Please resolve this as soon as possible.


This is a bug in bouncycastle, it should not have versioned jar symlinks unless
it's a compat package.

-- 
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: Broken dependencies: tika mvn(org.bouncycastle:bc*-jdk16:1.46)

2013-10-22 Thread Mikolaj Izdebski

On 10/21/2013 11:32 PM, punto...@libero.it wrote:
 tika has broken dependencies in the rawhide tree:
 On x86_64:
 tika-parsers-1.4-2.fc21.noarch requires
 mvn(org.bouncycastle:bcprov-jdk16:1.46)
 tika-parsers-1.4-2.fc21.noarch requires
 mvn(org.bouncycastle:bcmail-jdk16:1.46)

This is a bug in bouncycastle -- it does not follow Java packaging
guidelines in terms of versioned JARs and compatibility packages.

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

Re: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

2013-10-22 Thread Ralf Corsepius


On 10/22/2013 10:26 AM, Ville Skyttä wrote:

On Mon, Oct 21, 2013 at 3:08 PM, Michael Schwendt mschwe...@gmail.com wrote:

On Mon, 21 Oct 2013 04:01:15 +0200, Kevin Kofler wrote:

We already have one, it's called %{__global_ldflags}. You are indeed
supposed to set LDFLAGS of handwritten makefiles to that. The guidelines
need to be updated.

Also raises the question whether we want more such packages to do

[...]

In many cases the values aren't picked up from the environment but
need to be passed in by other means (such as arguments to make etc).
Also, the meaning of LDFLAGS is ambigous, which means implicitly 
passing it is somewhat dangerous.


It may mean flags to be passed to the linker through the compiler, but 
there also exist Makefiles/build environment, which treat LDFLAGS as 
flags to be directly passed to the linker.


-Wl,-z,relo is from the former family (-Wl ... gcc options to be passed 
to the linker through gcc).


gmake defines it as (from info make):

`LDFLAGS'
 Extra flags to give to compilers when they are supposed to invoke
 the linker, `ld'.

Ralf



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

Re: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

2013-10-22 Thread Michael Schwendt

On Tue, 22 Oct 2013 11:26:18 +0300, Ville Skyttä wrote:

 In many cases the values aren't picked up from the environment but
 need to be passed in by other means (such as arguments to make etc).

Okay. make -e … could be run in that case as a work-around. But
overriding Makefile variables completely can be less than ideal (this
can be observed in some spec files where the packagers also adds the
libs to link with, so the build doesn't break). Better would be that
the Makefile inherits from values passed in via Make or the env.

When using %configure always, even if not available, that makes it
possible to reuse the env vars it defines, and one doesn't need to
access the RPM macros:

  %configure || :
  make CFLAGS=$CFLAGS LDFLAGS=$LDFLAGS

To repeat from the earlier reply, one may want to take precautions,
so when a future upgrade adds a configure script, one drops the '|| :'.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: Broken dependencies: tika mvn(org.bouncycastle:bc*-jdk16:1.46)

2013-10-22 Thread punto...@libero.it


Il 22/10/2013 10:53, Mikolaj Izdebski ha scritto:

On 10/21/2013 11:32 PM, punto...@libero.it wrote:

tika has broken dependencies in the rawhide tree:
On x86_64:
 tika-parsers-1.4-2.fc21.noarch requires
mvn(org.bouncycastle:bcprov-jdk16:1.46)
 tika-parsers-1.4-2.fc21.noarch requires
mvn(org.bouncycastle:bcmail-jdk16:1.46)

This is a bug in bouncycastle -- it does not follow Java packaging
guidelines in terms of versioned JARs and compatibility packages.


hi
fine, removed the version to bcprov and bcmail JARs (F20 and rawhide)
thanks
gil
attachment: puntogil.vcf-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

dracut: how do I...

2013-10-22 Thread Felix Miata

Difference in size between initramfs generated with and without nohostonly is 
huge. I don't want to routinely use nohostonly, but neither do I want a 
specific root filesystem specified with root=UUID in the image. I want 
root= on cmdline to be obeyed in order to be able to clone the root 
filesystem for use on same hardware as many times as I want for various 
reasons and use whichever according to cmdline root=, having regenerated 
UUID(s)s on the clone(s). Is there a way? If there is one to be found in the 
dracut man page, I'm not seeing it. As it is, one must choose between 
nohostonly, or chrooting into the clone to regenerate with correct root UUID.

--
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

2013-10-22 Thread Ville Skyttä

On Tue, Oct 22, 2013 at 1:47 PM, Michael Schwendt mschwe...@gmail.com wrote:
 Better would be that
 the Makefile inherits from values passed in via Make or the env.

Sure.

   %configure || :
[...]
 To repeat from the earlier reply, one may want to take precautions,
 so when a future upgrade adds a configure script, one drops the '|| :'.

IMHO adding precaution cruft like [ -f configure ]  exit -1 [...]
is a sign of the packager doing package updates too carelessly if
(s)he doesn't even trust oneself or others to check if the upstream
build system has changed between releases...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

User/Group ID assignment

2013-10-22 Thread Mateusz Marzantowicz

Are there any guidelines regarding user and group id number assignment
on Fedora?

I'd like to add user/group for daemon, related to installed package, in
order to avoid running it as root. What numbers are already reserved and
where can I find up to date table with that numbers?

I see in my /etc/passwd that regular user accounts are assigned numbers
starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are
used by system accounts and packages like httpd, wireshark, etc.

I've found this [1] site but it looks outdated and incomplete because it
references FC5 and discussions pointed there are from 2005.

[1] https://fedoraproject.org/wiki/PackageUserCreation



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

Re: User/Group ID assignment

2013-10-22 Thread Mikolaj Izdebski

On 10/22/2013 01:25 PM, Mateusz Marzantowicz wrote:
 Are there any guidelines regarding user and group id number assignment
 on Fedora?
 
 I'd like to add user/group for daemon, related to installed package, in
 order to avoid running it as root. What numbers are already reserved and
 where can I find up to date table with that numbers?
 
 I see in my /etc/passwd that regular user accounts are assigned numbers
 starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are
 used by system accounts and packages like httpd, wireshark, etc.

UIDs = 1000 are reserved for users,  1000 for system.  System UIDs can
be allocated statically or dynamically.  Static UID allocation can be
found in [1], to add a new UID you need to file a RFE against setup
package.  Dynamic UID allocation is done from 999 downwards.  You don't
need to reserve anything, but UIDs can very between systems.

[1] /usr/share/doc/setup/uidgid

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

Re: User/Group ID assignment

2013-10-22 Thread Simone Caronni

Hello,

On 22 October 2013 13:25, Mateusz Marzantowicz mmarzantow...@osdf.com.plwrote:

 Are there any guidelines regarding user and group id number assignment
 on Fedora?


please read the packaging guidelines regarding user creation at rpm install
time:

http://fedoraproject.org/wiki/Packaging:UsersAndGroups

As a rule of thumb, your user must be dynamically allocated and not deleted
after rpm uninstallation.
If you need a static UID you need to open a ticket to FPC.

Details in the wiki page.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

Re: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

2013-10-22 Thread Michael Schwendt

On Tue, 22 Oct 2013 14:06:33 +0300, Ville Skyttä wrote:

 IMHO adding precaution cruft like [ -f configure ]  exit -1 [...]
 is a sign of the packager doing package updates too carelessly if
 (s)he doesn't even trust oneself or others to check if the upstream
 build system has changed between releases...

Agreed. It's a trade-off. Guards aren't bad, but in this case their
benefit is questionable. It probably doesn't work completely anyway, since
if the build framework uses Autotools, there likely are no pregenerated
Makefiles, and only a successful run on the configure script will generate
them.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: User/Group ID assignment

2013-10-22 Thread Mateusz Marzantowicz

On 22.10.2013 13:32, Mikolaj Izdebski wrote:
 On 10/22/2013 01:25 PM, Mateusz Marzantowicz wrote:
 Are there any guidelines regarding user and group id number assignment
 on Fedora?

 I'd like to add user/group for daemon, related to installed package, in
 order to avoid running it as root. What numbers are already reserved and
 where can I find up to date table with that numbers?

 I see in my /etc/passwd that regular user accounts are assigned numbers
 starting from 1000 (was it 500 on older systems?), 0-200 and 201-999 are
 used by system accounts and packages like httpd, wireshark, etc.
 
 UIDs = 1000 are reserved for users,  1000 for system.  System UIDs can
 be allocated statically or dynamically.  Static UID allocation can be
 found in [1], to add a new UID you need to file a RFE against setup
 package.  Dynamic UID allocation is done from 999 downwards.  You don't
 need to reserve anything, but UIDs can very between systems.
 
 [1] /usr/share/doc/setup/uidgid
 

Thanks, that is the list I was looking for. Is there any mechanism to
assign first available id from less than 999 pool or should I manually
find the right number? I understand that dynamic assignment is done by
package manager, but I don't want to rebuild and reinstall rpm package
for now on.


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

Broken dependencies: perl-MIME-Lite-HTML



perl-MIME-Lite-HTML has broken dependencies in the F-20 tree:
On x86_64:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
Please resolve this as soon as possible.


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

Broken dependencies: perl-PDL



perl-PDL has broken dependencies in the F-20 tree:
On x86_64:
perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2)
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
On i386:
perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2)
perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2
Please resolve this as soon as possible.


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

Broken dependencies: perl-Language-Expr



perl-Language-Expr has broken dependencies in the F-20 tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


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

Broken dependencies: slic3r



slic3r has broken dependencies in the F-20 tree:
On x86_64:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On i386:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
On armhfp:
slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3)
Please resolve this as soon as possible.


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

Broken dependencies: perl-BerkeleyDB



perl-BerkeleyDB has broken dependencies in the F-20 tree:
On x86_64:
perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21
On i386:
perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21
On armhfp:
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
Please resolve this as soon as possible.


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

Broken dependencies: perl-Padre



perl-Padre has broken dependencies in the F-20 tree:
On x86_64:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
Please resolve this as soon as possible.


--
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: dracut: how do I...

2013-10-22 Thread Harald Hoyer

On 10/22/2013 12:59 PM, Felix Miata wrote:
 Difference in size between initramfs generated with and without nohostonly is
 huge. I don't want to routinely use nohostonly, but neither do I want a 
 specific
 root filesystem specified with root=UUID in the image. I want root= on 
 cmdline
 to be obeyed in order to be able to clone the root filesystem for use on 
 same
 hardware as many times as I want for various reasons and use whichever 
 according
 to cmdline root=, having regenerated UUID(s)s on the clone(s). Is there a way?
 If there is one to be found in the dracut man page, I'm not seeing it. As it 
 is,
 one must choose between nohostonly, or chrooting into the clone to regenerate
 with correct root UUID.

If your root is on a non-assembled device (like a plain partition), then dracut
(at least for F20) does not store any UUIDs in the initramfs in hostonly mode.

You can check with:

# lsinitrd | egrep '.*requires.*\.device'

and

# lsinitrd | egrep 'etc/cmdline.d/.*\.conf'

Both should be empty for simple partition setups.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21/F22 System Wide Change: Python 3 as the Default Implementation

2013-10-22 Thread Daniel J Walsh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/17/2013 11:45 AM, Miloslav Trmač wrote:
 On Thu, Oct 17, 2013 at 9:13 AM, Bohuslav Kabrda bkab...@redhat.com
 wrote:
 * The Change plan should be updated to take into account Dennis's
 Feedback * I suggeested that perhaps a better contingency plan would be
 to simply ship with some applications using python2 and others using
 python3.
 
 
 Personally I don't have problem with this, but: - Side tag is a good
 contingency plan. If we have to revert for whatever reason, then without
 sidetag we will have to rebuild everything with Python 2 again.
 
 Yes.  In general it would be great to start frequently making disruptive
 changes on branches to not disrupt other people, and this is a very big
 change where at least having the option is very much warranted Mirek
 
Began working on porting all of the SELinux python code to python3.  I plan on
shipping bindings for both 2 and 3, but tools are hung up on missing yum and
dbus python3 bindings.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJmbgUACgkQrlYvE4MpobMUygCdFFfP2E4luT6+U1+y6sOdglWe
gK4AoMNhuRj8sB0ZuFvUD8nn3CZPDKqH
=4pTR
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-20 Branched report: 20131022 changes

2013-10-22 Thread Fedora Branched Report

Compose started at Tue Oct 22 09:15:02 UTC 2013

Broken deps for armhfp
--
[blueman]
blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3
blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp
[bwm-ng]
bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9
[cloud-init]
cloud-init-0.7.2-7.fc20.noarch requires dmidecode
[cobbler]
cobbler-2.4.0-2.fc20.noarch requires syslinux
[condor-wallaby]
condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf = 
0:0.9.1073306
[fts]
fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14
[glpi]
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc
glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache
[gnome-do-plugins]
gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird
[gofer]
ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0
[gradle]
gradle-1.0-18.fc20.noarch requires plexus-container-default
[grass]
grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so
grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so
[gtkd]
gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 
0:2.0.0-29.20120815git9ae9181.fc18
[kawa]
1:kawa-1.11-5.fc19.armv7hl requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0
kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0
[monotone]
monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so
perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2)
[mozilla-firetray]
mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires 
thunderbird = 0:11
[msp430-libc]
msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10
[nocpulse-common]
nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI)
[openbox]
gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel
gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel
[openpts]
openpts-0.2.6-7.fc20.armv7hl requires tboot
[osm2pgsql]
osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so
[oyranos]
oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5
[perl-BerkeleyDB]
perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21
[perl-Language-Expr]
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
[perl-MIME-Lite-HTML]
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
[perl-Padre]
perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0)
[pure]
pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20
[python-tag]
python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0
[rootplot]
rootplot-2.2.1-7.fc19.noarch requires root-python
[ruby-spqr]
ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf
[rubygem-audited-activerecord]
rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires 
rubygem(activerecord)  0:4
[rubygem-fog]
rubygem-fog-1.11.1-1.fc20.noarch requires rubygem(nokogiri)  0:1.6
[scala]

Re: User/Group ID assignment

2013-10-22 Thread Mikolaj Izdebski

On 10/22/2013 01:43 PM, Mateusz Marzantowicz wrote:
 Thanks, that is the list I was looking for. Is there any mechanism to
 assign first available id from less than 999 pool or should I manually
 find the right number? I understand that dynamic assignment is done by
 package manager, but I don't want to rebuild and reinstall rpm package
 for now on.

Dynamic assignment is done by adduser tool.  adduser -r will create user
with UID 999 if available, if not then 998 and so on.  Basically adduser
-r chooses UIDs from SYS_UID_MIN to SYS_UID_MAX, as defined in
/etc/login.defs

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

Introducing Myself

2013-10-22 Thread Baptiste Mille-Mathias

Hello,

Per the requested process for new packagers, I hereby introduce myself.

My name is Baptiste Mille-Mathias, I'm French, 34 years old guy.
I use Fedora since the beginning of 2011 but I only recently started
contributing to Fedora with packaging [0]. Haïkel Guémar (number80) is
mentoring me.

My day-to-day job is Production Application / System Engineer in the
South of France.
I'm also the president of GNOME-FR the non-profit organization that
promote GNOME in France (we participate events like FOSDEM too).

My FAS name is baptistemm [1]. You can found me on irc with this nickname.

Regards.

[0] 
https://lists.fedoraproject.org/pipermail/package-announce/2013-October/118884.html
[1] https://admin.fedoraproject.org/accounts/user/view/baptistemm
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Introducing Myself

2013-10-22 Thread Haïkel Guémar


Le 22/10/2013 16:06, Baptiste Mille-Mathias a écrit :

Hello,

Per the requested process for new packagers, I hereby introduce myself.

My name is Baptiste Mille-Mathias, I'm French, 34 years old guy.
I use Fedora since the beginning of 2011 but I only recently started
contributing to Fedora with packaging [0]. Haïkel Guémar (number80) is
mentoring me.

My day-to-day job is Production Application / System Engineer in the
South of France.
I'm also the president of GNOME-FR the non-profit organization that
promote GNOME in France (we participate events like FOSDEM too).

My FAS name is baptistemm [1]. You can found me on irc with this nickname.

Regards.

[0] 
https://lists.fedoraproject.org/pipermail/package-announce/2013-October/118884.html
[1] https://admin.fedoraproject.org/accounts/user/view/baptistemm


Welcome Baptiste !
I have no doubts you'll a be valuable member of the Fedora Community, 
keep up with the good work. :)


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

Canonical copy of config.guess/config.sub

2013-10-22 Thread Florian Weimer


What's the canonical system-wide copy of the config.guess file?  I have:

9c01fa8c4554cb2c7b92c95dfa0dbfcf /usr/lib/rpm/redhat/config.guess
9c01fa8c4554cb2c7b92c95dfa0dbfcf /usr/share/libtool/config/config.guess
c3178bdc1506f569388eaebec2026003 /usr/lib/rpm/config.guess
d9375ba9d0b8cfd7bb6737e3fc43984f /usr/share/dejagnu/libexec/config.guess
eea34cf893bb060ee20189e256a8065a /usr/share/automake-1.13/config.guess

The situation with config.sub isn't much better:

0b96c40308f509ba2c0e132c1d2e70e7  /usr/lib/rpm/config.sub
1803a1d601bcf4debccfe2902c4f0f65  /usr/lib/rpm/redhat/config.sub
1803a1d601bcf4debccfe2902c4f0f65  /usr/share/libtool/config/config.sub
520911d86319be25a97f4be9ed7e0301  /usr/share/automake-1.13/config.sub

I'm asking because I want to propose upstream that they put in a check 
if the system-wide version is newer, and if it is, just run it instead 
of the package-supplied copy.  But in order to do that, we need a 
canonical path.


Right now, iterating over /usr/share/automake*/config.{guess,sub} looks 
most promising and would work on Debian as well.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: --Wl,-z,relro in LDFLAGS required?/Inconsistency when not using %configure

2013-10-22 Thread Adam Jackson

On Sun, 2013-10-20 at 23:42 +0200, Till Maas wrote:
 Hi,
 
 https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Compiler_flags
 
 mentions only %optflags to be required for packages but I noticed that
 %configure sets LDFLAGS to a value different than %optflags:

As noted there does exist an rpm variable for this.  However at least
the relro part of it seems to be unnecessary with current binutils:

%if 0%{?fedora} = 18
* Tue Mar 06 2012 Nick Clifton ni...@redhat.com - 2.22.52.0.1-7
- Enable -zrelro by default. (#621983 #807831)
%endif

- ajax

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

[Bug 1013122] perl-MIME-Charset-1.011.1 is available

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

Xavier Bachelot xav...@bachelot.org changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2013-10-22 10:49:09



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=ljWClAELC9a=cc_unsubscribe
--
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: Canonical copy of config.guess/config.sub

2013-10-22 Thread Peter Lemenkov

2013/10/22 Florian Weimer fwei...@redhat.com:
 What's the canonical system-wide copy of the config.guess file?  I have:

I'm copying them from libtool.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: --Wl,-z,relro in LDFLAGS required?/Inconsistency when not using %configure

2013-10-22 Thread Reindl Harald


Am 22.10.2013 16:47, schrieb Adam Jackson:
 On Sun, 2013-10-20 at 23:42 +0200, Till Maas wrote:
 https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Compiler_flags

 mentions only %optflags to be required for packages but I noticed that
 %configure sets LDFLAGS to a value different than %optflags:
 
 As noted there does exist an rpm variable for this.  However at least
 the relro part of it seems to be unnecessary with current binutils:
 
 %if 0%{?fedora} = 18
 * Tue Mar 06 2012 Nick Clifton ni...@redhat.com - 2.22.52.0.1-7
 - Enable -zrelro by default. (#621983 #807831)
 %endif

this is only *partial* RELRO
Full RELRO: -Wl,-z,now -Wl,-z,relro

http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Is rpmbuild reentrant?

Is it healty to execute rpmbuild while building a package?

I have tests for perl dependencency generator filters. I.e. the tests
build a package using rpmbuild with redefeined all the `_*dir' macros,
then use librpm to query requires and provides from built package, and
then do checks on the values.

I'm thinking how to plug the tests into Fedora. The simplest solution is
to run the tests in %check phase of a package (I don't know which one,
but it does not matter which one).

I've already heard warnings that calling rpm from package scriptlets is
not recommend.

What the situation with rpmbuild?

-- Petr

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

Re: communications and community [was Re: Lack of response about sponsorship]

2013-10-22 Thread Matthew Miller

On Mon, Oct 21, 2013 at 08:26:54PM +0200, Michael Schwendt wrote:
 Correct. Less lists (or the same lists) and with a more well-defined
 target group and description.

So, in the not so far future, we'll have mailman3 and hyperkitty, and we
want to migrate the lists to that. That switchover point could also be a
time when we consolidate and rationalize the overall structure.




-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is rpmbuild reentrant?

2013-10-22 Thread Neil Horman

On Tue, Oct 22, 2013 at 03:03:44PM +, Petr Pisar wrote:
 Is it healty to execute rpmbuild while building a package?
 
 I have tests for perl dependencency generator filters. I.e. the tests
 build a package using rpmbuild with redefeined all the `_*dir' macros,
 then use librpm to query requires and provides from built package, and
 then do checks on the values.
 
 I'm thinking how to plug the tests into Fedora. The simplest solution is
 to run the tests in %check phase of a package (I don't know which one,
 but it does not matter which one).
 
 I've already heard warnings that calling rpm from package scriptlets is
 not recommend.
 
 What the situation with rpmbuild?
 
I'm not sure how re-entrant-safe rpmbuild is, but doing the above seems a bit
dodgy in general.  Could you instead package the test separately from the
dependency generator rpm, make the latter depedent on the former, and then use
chain-build in koji to build them at the same time?

Neil

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

Re: Canonical copy of config.guess/config.sub

2013-10-22 Thread Ralf Corsepius


On 10/22/2013 04:48 PM, Peter Lemenkov wrote:

2013/10/22 Florian Weimer fwei...@redhat.com:

What's the canonical system-wide copy of the config.guess file?  I have:

I'm copying them from libtool.


Why?

config.sub/config.guess originate from an upstream of their own (The 
config project):

http://savannah.gnu.org/projects/config
which is where GNU upstreams usually update their config.* from, when 
preparing releases.


Also, automake-based projects receive the versions bundled with 
automake, when running automake rsp. autoreconf.


So, if there's something resembling to a system-wide copy, then it's the 
version in automake or that in rpm (Because that's where rpmbuild 
currently picks it up from).


That said, it might be worth considering a system-wide config package ;)

Ralf



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

Re: The trouble with metadata-extractor

2013-10-22 Thread Andrea Musuruane

I send again the following post. I can't believe not to get an opinion :)

Bye,

Andrea.



On Sun, Oct 20, 2013 at 11:37 PM, Andrea Musuruane musur...@gmail.comwrote:

 Hi all,
 last April the following bug report was opened:
 https://bugzilla.redhat.com/show_bug.cgi?id=947457

 As I stated on bugzilla, metadata-extractor was just needed by JOSM.
 Updating metadata-extractor would break JOSM. Anyway I suggested to
 patch JOSM to use a newer version of metadata-extractor if he really
 needed it. I had no response at all.

 BTW, I am metadata-extractor maintainer, and not JOSM maintainer.

 This evening the submitter emailed me privately and I discovered that
 meanwhile, a new review request for a newer version of
 metadata-extractor was approved and now it is part of Fedora:
 https://bugzilla.redhat.com/show_bug.cgi?id=1004563

 As I understand now, newer metadata-extractor is required by Apache
 Sorl and Apache Tika, which are not yet part of Fedora.

 He asked me to exchange our repository to simplify some build with
 maven. And with that I presume that he would like to have his package
 called metadata-extractor because he has troubles to build sorl and
 tika.

 I think all this have been handled very badly. He could have told why
 he needed a more recent version of metadata-extractor in the first
 place, the reviewer of #1004563 could have checked if the package
 followed the naming guidelines and/or have checked if the package was
 already in Fedora.

 I still think that my original plan (i.e. patching JOSM). was more
 sensible.

 What to do now? What do you think?

 If it helps, if it makes things easier, I can release the ownership of
 metadata-extractor and someone else can have good care. I just
 packaged it because, as an openstreetmap mapper, I longed to have JOSM
 in Fedora.

 Regards,

 Andrea.

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

Re: The trouble with metadata-extractor

2013-10-22 Thread punto...@libero.it


Il 22/10/2013 17:54, Andrea Musuruane ha scritto:

I send again the following post. I can't believe not to get an opinion :)

Bye,

Andrea.



hi


On Sun, Oct 20, 2013 at 11:37 PM, Andrea Musuruane musur...@gmail.com 
mailto:musur...@gmail.com wrote:


Hi all,
last April the following bug report was opened:
https://bugzilla.redhat.com/show_bug.cgi?id=947457

As I stated on bugzilla, metadata-extractor was just needed by JOSM.
Updating metadata-extractor would break JOSM. Anyway I suggested to
patch JOSM to use a newer version of metadata-extractor if he really
needed it. I had no response at all.

BTW, I am metadata-extractor maintainer, and not JOSM maintainer.

This evening the submitter emailed me privately and I discovered that
meanwhile, a new review request for a newer version of
metadata-extractor was approved and now it is part of Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1004563

As I understand now, newer metadata-extractor is required by Apache
Sorl and Apache Tika, which are not yet part of Fedora.


wrong, Apache tika is already part of Fedora
and for question of time only for import some new libraries for Wildfly 8.x
was disabled a module (tika-parsers 
https://bugzilla.redhat.com/show_bug.cgi?id=1019650)

but is required also , by some Bigdata (hadhoop) packages


He asked me to exchange our repository to simplify some build with
maven. And with that I presume that he would like to have his package
called metadata-extractor because he has troubles to build sorl and
tika.


no i havent any trouble for me is the same


I think all this have been handled very badly. He could have told why
he needed a more recent version of metadata-extractor in the first
place, the reviewer of #1004563 could have checked if the package
followed the naming guidelines and/or have checked if the package was
already in Fedora.

I still think that my original plan (i.e. patching JOSM). was more
sensible.

What to do now? What do you think?

If it helps, if it makes things easier, I can release the ownership of
metadata-extractor and someone else can have good care. I just
packaged it because, as an openstreetmap mapper, I longed to have JOSM
in Fedora.


regards
gil


Regards,

Andrea.






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

Re: The trouble with metadata-extractor

2013-10-22 Thread Stanislav Ochotnicky

Ugh, what a mess..

Quoting Andrea Musuruane (2013-10-20 23:37:54)
 Hi all,
 last April the following bug report was opened:
 https://bugzilla.redhat.com/show_bug.cgi?id=947457
 
 As I stated on bugzilla, metadata-extractor was just needed by JOSM.
 Updating metadata-extractor would break JOSM. Anyway I suggested to
 patch JOSM to use a newer version of metadata-extractor if he really
 needed it. I had no response at all.

 BTW, I am metadata-extractor maintainer, and not JOSM maintainer.

Sorry but it is your responsibility as maintainer to keep the package up to date
as much as possible. If JOSM required older version you should work with JOSM
maintainer and upstream to update it to latest (providing patches/testing etc.)

Why are you even maintaining metadata-extractor if you have no use for it? It
only makese sense for JOSM maintainer to maintain metadata-extractor in the
first place since he's the only user of the library

 This evening the submitter emailed me privately and I discovered that
 meanwhile, a new review request for a newer version of
 metadata-extractor was approved and now it is part of Fedora:
 https://bugzilla.redhat.com/show_bug.cgi?id=1004563

I don't like the naming of the package, both are metadata-extractor 2.x. If
anything new package should have been metadata-extractor26. Technically the
review was OK, the packages do not conflict in any way, but they are helluva
confusing.

All in all, even if JOSM couldn't be ported it would have been better to package
metadata-extractor-compat solely for JOSM and then just update extractor to
latest upstream.

 As I understand now, newer metadata-extractor is required by Apache
 Sorl and Apache Tika, which are not yet part of Fedora.

Already are as was mentioned

 He asked me to exchange our repository to simplify some build with
 maven. And with that I presume that he would like to have his package
 called metadata-extractor because he has troubles to build sorl and
 tika.

Frankly...I'd rather ask for clarification. I have trouble understanding some
people

 I think all this have been handled very badly. He could have told why
 he needed a more recent version of metadata-extractor in the first
 place, the reviewer of #1004563 could have checked if the package
 followed the naming guidelines and/or have checked if the package was
 already in Fedora.

The review was technically OK, there was one question from reviewer missing: Why
cannot you use version already in Fedora and what have you done to fix that?

Other than that the packages don't really conflict or cause any issues to each
other AFAIK.

 I still think that my original plan (i.e. patching JOSM). was more sensible.

Agreed

 What to do now? What do you think?

Ideally? I'd say:

1. Update metadata-extractor to latest upstream, add maven metadata, shell
script in /usr/bin/ etc. Basically overwrite metadata-extractor with current
metadata-extractor2
2. Sort out JSOM breakage afterwards. Either package metadata-extractor-compat,
or patch JSOM (ideally going to upstream with the patch afterwards)
3. Obsolete/deprecate metadata-extractor2
4. Wham someone with a cluestick

 If it helps, if it makes things easier, I can release the ownership of
 metadata-extractor and someone else can have good care. I just
 packaged it because, as an openstreetmap mapper, I longed to have JOSM
 in Fedora

Libraries should be generally maintained by people who are actually using them
in some application. But it's up to you after all said and done if you want to
keep maintaining it.

-- 
Stanislav Ochotnicky sochotni...@redhat.com
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The trouble with metadata-extractor

2013-10-22 Thread punto...@libero.it


Il 22/10/2013 18:33, Stanislav Ochotnicky ha scritto:

Ideally? I'd say:

1. Update metadata-extractor to latest upstream, add maven metadata, shell
 script in/usr/bin/  etc. Basically overwrite metadata-extractor with 
current
 metadata-extractor2
2. Sort out JSOM breakage afterwards. Either package metadata-extractor-compat,
 or patch JSOM (ideally going to upstream with the patch afterwards)
3. Obsolete/deprecate metadata-extractor2
4. Wham someone with a cluestick


it was just that I was referring to in my private email. from which 
badly was extracted part of the contents

regards

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

File Test-Output-1.02.tar.gz uploaded to lookaside cache by pghmcfc

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

d80890160737cdf4c3241d48428d33ab  Test-Output-1.02.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: bcache-tools and bcache support in other linux packages

2013-10-22 Thread Rolf Fokkens

On 10/21/2013 06:47 PM, Piergiorgio Sartor wrote:

Interesting, then logic would suggest to (b)cache
the components of the RAID.
Of, even better, to (b)cache /dev/sd[ab] (in this
case) and cover, in this way, everything.
Well, I agree, there's more to it. Like cost. One could consider to pair
serveral HHD' each with a dedicated bcache SSD. And from that one could
build a RAID array. This RAID array has excellent (read) performance
because of the combined SSD performance. This storage system does break
when one of the HDD's or SDD's breaks, which is also a nice feature. So
if it weren't for the cost (and the number of availbale SATA connectors)
this could be interresting. But it's all a matter of requirements of course.

It's a desktop PC, I notice that performances
mainly depend on the storage subystem, the rest
(CPU, memory, GPU) is fine for me.

In my desktop PC I'm running singls SSD bcache on a RAID5 array. The
performance is fine, and when the SSD breaks, well, I hope the FS on the
HDD can be recovered. And if not? Well, it's only a desktop PC.

And when using multiple SSD's for reduncancy, the following article
covers some interresting features in bcache:

http://www.linux.com/news/featured-blogs/200-libby-clark/728209-about-the-linux-kernel-bcache

Quote Multiple SSDs will allow us to mirror dirty data and metadata,
but not clean data - you get redundancy without wasting SSD space
duplicating clean cached data.

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

Re: communications and community [was Re: Lack of response about sponsorship]

2013-10-22 Thread Bill Nottingham

Kevin Fenzi (ke...@scrye.com) said: 
  As a first step, I suggest clearing up the intended usage of devel
  list. There's too much traffic on that list. 792 messages so far in
  October. Even if one uses filtering, the recurring task of skimming
  over the devel list folder is tiresome, since it's not the only list
  one is subscribed to. Not even meetings logs are posted to
  devel-announce list, however.
 
 Good idea. What items could we move to announce that would be more
 useful for folks that don't have as much time/energy to skim the main
 list?
 
 fesco meeting agenda/minutes? (note that this would be weekly, so
 increase the announce list a good deal)
 Any other things that would be better as announcements?

I would think that if we are in a situation where people who do development
don't subscribe to the devel list because of 'energy' reasons
(disillusionment, feelings of either a) pointlessness b) fait-accompli,
etc.), then just moving things to -announce is not actually solving the
problem.

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

Orphaning ghemical and related packages

2013-10-22 Thread Carl Byington

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ghemical
libghemical
liboglappth
mopac7
mpqc

I hope someone is able to pick them up.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlJm7LYACgkQL6j7milTFsEY/ACbBCxTi5Z21XwHMIPOTPSMK/4I
ywsAoIEwfZ9J+r63sFe56r1u00TScDXi
=uTZg
-END PGP SIGNATURE-


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

Schedule for Wednesday's FESCo Meeting (2013-10-23)

2013-10-22 Thread Kevin Fenzi

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2013-10-23 18:00 UTC'

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

= Followups =

#topic ticket #1164 F20 Changes - Process on Changes Freeze
.fesco 1164

#topic ticket #1181 Fedora still vulnerable to BEAST
.fesco 1181

#topic ticket #1182 F21/F22 System Wide Change: Python 3
as the Default Implementation -
https://fedoraproject.org/wiki/Changes/Python_3_as_Default
.fesco 1182

#topic ticket #1170 Working Group call for Volunteers
.fesco 1170

= New business =

#topic ticket #1183 Don't enable prelink by default in Fedora
.fesco 1183

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.

[signature.asc  application/pgp-signature (836 bytes)] 


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

Re: --Wl, -z, relro in LDFLAGS required?/Inconsistency when not using %configure

2013-10-22 Thread Kevin Kofler

Michael Schwendt wrote:
 Agreed. It's a trade-off. Guards aren't bad, but in this case their
 benefit is questionable. It probably doesn't work completely anyway, since
 if the build framework uses Autotools, there likely are no pregenerated
 Makefiles, and only a successful run on the configure script will generate
 them.

Well, the exit in the guard would fail the build even before that, whereas 
the %configure || : would just succeed if %configure succeeds, and then 
the subsequent make would run too. (That said, that's not necessarily a 
problem, it just makes the || : redundant. Failing %configure would fail 
make too anyway, for the reason you describe.)

What the guard does not catch is if the package only ships configure.ac and 
expects you to run autoconf yourself, or if it uses CMake or some other 
configury tool. But then the make will likely fail anyway for the reason 
you describe.

Kevin Kofler

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

Re: pycairo

2013-10-22 Thread Zbigniew Jędrzejewski-Szmek

On Sun, Oct 20, 2013 at 11:27:22AM +0800, Christopher Meng wrote:
 Hi list,
 
 I'm building some packages which depend on the latest version of
 pycairo, and an inprogress feature also needs its
 rebuild(https://bugzilla.redhat.com/show_bug.cgi?id=1005447) as well.
 
 However the version in Fedora hasn't been updated for more than a
 year, and also there is a name change request to change it to
 python-pycairo(https://bugzilla.redhat.com/show_bug.cgi?id=731891).
So, is this Review request still live and waiting for a reviewer,
or is is dead, and waiting for a new prospective maintainer?
It would be great if the involved parties could provide some hints.

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

Re: pycairo

2013-10-22 Thread Mathieu Bridon

On Wed, 2013-10-23 at 05:21 +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Sun, Oct 20, 2013 at 11:27:22AM +0800, Christopher Meng wrote:
  Hi list,
  
  I'm building some packages which depend on the latest version of
  pycairo, and an inprogress feature also needs its
  rebuild(https://bugzilla.redhat.com/show_bug.cgi?id=1005447) as well.
  
  However the version in Fedora hasn't been updated for more than a
  year, and also there is a name change request to change it to
  python-pycairo(https://bugzilla.redhat.com/show_bug.cgi?id=731891).
 So, is this Review request still live and waiting for a reviewer,
 or is is dead, and waiting for a new prospective maintainer?
 It would be great if the involved parties could provide some hints.

Note that the package was renamed anyway, without waiting for the rename
review request to be completed:
http://pkgs.fedoraproject.org/cgit/pycairo.git/commit/?id=c700bd496bee56d8f0de03ef4d57a34d1a97bcf0


-- 
Mathieu

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

Re: pycairo

2013-10-22 Thread Christopher Meng

On Wed, Oct 23, 2013 at 11:21 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 So, is this Review request still live and waiting for a reviewer,
 or is is dead, and waiting for a new prospective maintainer?
 It would be great if the involved parties could provide some hints.

Dead de facto. But it has many comaintainers. I hope we can finish
this review but unfortunately J5 is not working on this area now,
thusly we need someone else.

Essentially, this package should get an update first as the latest
version was released in 2011, then we can see if it's possible to
change its name. But now as name change bug has been posted for
years(from f15 era, then dup of this one), we should think about both
simultaneously.

All comaintainers of this package are not willing to do that:

https://admin.fedoraproject.org/pkgdb/acls/name/pycairo

alexl
caillon
caolanm
hadess
mclasen
rhughes
rstrode
ssp
xiphmont

This package is pretty old comparing with other distros, this is not
bleeding edge but really need an update. And if someone want to set
python3 as default interpreter, you will find Fedora doesn't have its
py3 version, which is also being required by at least these on py2.x
version:

bkchem
dogtail
gnome-activity-journal
gnome-desktop
graphite-web
gtg
icaro
labyrinth
lv2-fil-plugins
pitivi
pycairo-devel
pygobject3
pygtk2
python-cairosvg
python-matplotlib
python-pycha
python-xdot
yumex

So? I don't know.

I hope some people like rhughes/hadness(who is of course alive and has
commit acl, too) can update it. But I think my words are tiny.
--

Yours sincerely,
Christopher Meng

Fєdоґa ї₴ al$о a кїпd оf нaт lїкє Яёd Haт.

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

Re: pycairo

2013-10-22 Thread Christopher Meng

On Wed, Oct 23, 2013 at 11:40 AM, Mathieu Bridon
boche...@fedoraproject.org wrote:
 Note that the package was renamed anyway, without waiting for the rename
 review request to be completed:
 http://pkgs.fedoraproject.org/cgit/pycairo.git/commit/?id=c700bd496bee56d8f0de03ef4d57a34d1a97bcf0

And I would ask why he can do that without reviews?

http://fedoraproject.org/wiki/Package_Renaming_Process

Just because he is working at Red Hat and has such power inherited?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: pycairo

2013-10-22 Thread Mathieu Bridon

On Wed, 2013-10-23 at 11:46 +0800, Christopher Meng wrote:
 On Wed, Oct 23, 2013 at 11:40 AM, Mathieu Bridon
 boche...@fedoraproject.org wrote:
  Note that the package was renamed anyway, without waiting for the rename
  review request to be completed:
  http://pkgs.fedoraproject.org/cgit/pycairo.git/commit/?id=c700bd496bee56d8f0de03ef4d57a34d1a97bcf0
 
 And I would ask why he can do that without reviews?
 
 http://fedoraproject.org/wiki/Package_Renaming_Process
 
 Just because he is working at Red Hat and has such power inherited?

Or more likely, because I was wrong: the renaming was done in Git long
before the review request was opened.

So the more likely explanation is that Matthew (who renamed the package
in Git) didn't know about the process, and John tried to fix things up
by creating the review request when he realized it.

Remember: assume good faith and double check the dates (that last one is
for me) ;)


-- 
Mathieu

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

Re: Is rpmbuild reentrant?

On 2013-10-22, Neil Horman nhor...@redhat.com wrote:
 On Tue, Oct 22, 2013 at 03:03:44PM +, Petr Pisar wrote:
 Is it healty to execute rpmbuild while building a package?
 
 I have tests for perl dependencency generator filters. I.e. the tests
 build a package using rpmbuild with redefeined all the `_*dir' macros,
 then use librpm to query requires and provides from built package, and
 then do checks on the values.
 
 I'm thinking how to plug the tests into Fedora. The simplest solution is
 to run the tests in %check phase of a package (I don't know which one,
 but it does not matter which one).
 
 I've already heard warnings that calling rpm from package scriptlets is
 not recommend.
 
 What the situation with rpmbuild?
 
 I'm not sure how re-entrant-safe rpmbuild is, but doing the above seems a bit
 dodgy in general.  Could you instead package the test separately from the
 dependency generator rpm, make the latter depedent on the former, and then use
 chain-build in koji to build them at the same time?

Do you say to create a dummy package in Fedora? Package which itself has
dummy (possibly) unsatisfied dependencies? Package that ends up in
Fedora repositories? That's fishy.

-- Petr

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

[Bug 1020809] Please simplify %perl_default_filter

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

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

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |ppi...@redhat.com



--- Comment #2 from Petr Pisar ppi...@redhat.com ---
We will see. I will do some tests and in case of success, I will implement it
in F21.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=0lSaQlCxFLa=cc_unsubscribe
--
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 1020809] Please simplify %perl_default_filter

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



--- Comment #4 from Petr Pisar ppi...@redhat.com ---
(In reply to Petr Pisar from comment #3)
 So it seems to work.
 
 However I would like to sanity the filters too: To anchor the expressions
 and to append them instead of redefining:
 
Correct new values would be:

%global __provides_exclude_from
%{?__provides_exclude_from:%__provides_exclude_from|}^%{_docdir}
%global __requires_exclude_from
%{?__requires_exclude_from:%__requires_exclude_from|}^%{_docdir}
%global __provides_exclude
%{?__provides_exclude:%__provides_exclude|}^perl(VMS|^perl(Win32|^perl(DB)|^perl(UNIVERSAL)
%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl(VMS|^perl(Win32

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=idslzGyF95a=cc_unsubscribe
--
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 1021855] New: perl-Shipwright-2.4.34 is available

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

Bug ID: 1021855
   Summary: perl-Shipwright-2.4.34 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Shipwright
  Keywords: FutureFeature, Triaged
  Assignee: robinlee.s...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com



Latest upstream release: 2.4.34
Current version/release in Fedora Rawhide: 2.4.33-4.fc20
URL: http://search.cpan.org/dist/Shipwright/

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.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=WuCgRttorma=cc_unsubscribe
--
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 1020809] Please simplify %perl_default_filter

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



--- Comment #5 from Petr Pisar ppi...@redhat.com ---
(In reply to Petr Pisar from comment #3)
 However I would like to sanity the filters too: To anchor the expressions
 and to append them instead of redefining:
 
And this works too. I'm going to push this version. I will create automated
tests and package them for Fedora to have a canary.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=Njsl5CeESya=cc_unsubscribe
--
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] Append and anchor filters

commit 0c4778d8b72569597beb026ed6974f2101ec03b2
Author: Petr Písař ppi...@redhat.com
Date:   Tue Oct 22 09:38:22 2013 +0200

Append and anchor filters

 macros.perl |8 
 perl.spec   |2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)
---
diff --git a/macros.perl b/macros.perl
index b490fe5..83d86fb 100644
--- a/macros.perl
+++ b/macros.perl
@@ -44,10 +44,10 @@ export PERL_MM_USE_DEFAULT=1
 # %{?perl_default_filter}, before any %description block.
 
 %perl_default_filter %{expand: \
-%global __provides_exclude_from %{_docdir}
-%global __requires_exclude_from %{_docdir}
-%global __provides_exclude 
perl(VMS|perl(Win32|perl(DB)|perl(UNIVERSAL)
-%global __requires_exclude perl(VMS|perl(Win32
+%global __provides_exclude_from 
%{?__provides_exclude_from:%__provides_exclude_from|}^%{_docdir}
+%global __requires_exclude_from 
%{?__requires_exclude_from:%__requires_exclude_from|}^%{_docdir}
+%global __provides_exclude 
%{?__provides_exclude:%__provides_exclude|}^perl(VMS|^perl(Win32|^perl(DB)|^perl(UNIVERSAL)
+%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}^perl(VMS|^perl(Win32
 }
 
 #
diff --git a/perl.spec b/perl.spec
index a4a1cf5..3a664f1 100644
--- a/perl.spec
+++ b/perl.spec
@@ -3628,6 +3628,8 @@ sed \
 * Tue Oct 22 2013 Petr Pisar ppi...@redhat.com - 4:5.18.1-289
 - perl_default_filter macro does not need to filter private libraries from
   provides (bug #1020809)
+- perl_default_filter anchors the filter regular expressions
+- perl_default_filter appends the filters instead of redefining them
 
 * Mon Sep 09 2013 Jitka Plesnikova jples...@redhat.com - 4:5.18.1-288
 - Fix rules for parsing numeric escapes in regexes (bug #978233)
--
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] perl_default_filter macro does not filter private libraries from provides

commit c954fb6e868302112aae1d375724d08d3d35cf20
Author: Petr Písař ppi...@redhat.com
Date:   Tue Oct 22 08:47:11 2013 +0200

perl_default_filter macro does not filter private libraries from provides

 macros.perl |8 +---
 perl.spec   |9 ++---
 2 files changed, 11 insertions(+), 6 deletions(-)
---
diff --git a/macros.perl b/macros.perl
index dc10c03..b490fe5 100644
--- a/macros.perl
+++ b/macros.perl
@@ -35,14 +35,16 @@ export PERL_MM_USE_DEFAULT=1
 %global __perl_requires /usr/lib/rpm/perl.req
 
 # By default, for perl packages we want to filter all files in _docdir from 
-# req/prov scanning, as well as filtering out any provides caused by private 
-# libs in vendorarch/archlib (vendor/core).
+# req/prov scanning.
+# Filtering out any provides caused by private libs in vendorarch/archlib
+# (vendor/core) is done by rpmbuild since Fedora 20
+# https://fedorahosted.org/fpc/ticket/353.
 #
 # Note that this must be invoked in the spec file, preferably as 
 # %{?perl_default_filter}, before any %description block.
 
 %perl_default_filter %{expand: \
-%global __provides_exclude_from 
%{perl_vendorarch}/auto/.*.so$|%{perl_archlib}/.*.so$|%{_docdir}
+%global __provides_exclude_from %{_docdir}
 %global __requires_exclude_from %{_docdir}
 %global __provides_exclude 
perl(VMS|perl(Win32|perl(DB)|perl(UNIVERSAL)
 %global __requires_exclude perl(VMS|perl(Win32
diff --git a/perl.spec b/perl.spec
index fa3974a..a4a1cf5 100644
--- a/perl.spec
+++ b/perl.spec
@@ -13,8 +13,7 @@
 # This overrides filters from build root (/etc/rpm/macros.perl)
 # intentionally (unversioned perl(DB) is removed and versioned one is kept)
 # Filter provides from *.pl files, bug #924938
-# Filter *.so file from auto subdir only to keep providing libperl.so
-%global __provides_exclude_from 
.*/auto/.*\\.so$|.*%{_docdir}|.*%{perl_archlib}/.*\\.pl$|.*%{perl_privlib}/.*\\.pl$
+%global __provides_exclude_from 
.*%{_docdir}|.*%{perl_archlib}/.*\\.pl$|.*%{perl_privlib}/.*\\.pl$
 %global __requires_exclude_from %{_docdir}
 %global __provides_exclude perl\\((VMS|Win32|BSD::|DB\\)$)
 # unicore::Name - it's needed by perl, maybe problem of rpm
@@ -31,7 +30,7 @@
 Name:   perl
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:288%{?dist}
+Release:289%{?dist}
 Epoch:  %{perl_epoch}
 Summary:Practical Extraction and Report Language
 Group:  Development/Languages
@@ -3626,6 +3625,10 @@ sed \
 
 # Old changelog entries are preserved in CVS.
 %changelog
+* Tue Oct 22 2013 Petr Pisar ppi...@redhat.com - 4:5.18.1-289
+- perl_default_filter macro does not need to filter private libraries from
+  provides (bug #1020809)
+
 * Mon Sep 09 2013 Jitka Plesnikova jples...@redhat.com - 4:5.18.1-288
 - Fix rules for parsing numeric escapes in regexes (bug #978233)
 - Fix crash with \$glob_copy (bug #989486)
--
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 1020809] Please simplify %perl_default_filter

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

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

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-5.18.1-289.fc21
 Resolution|--- |RAWHIDE
Last Closed||2013-10-22 07:11:34



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=S2CMoK1QIma=cc_unsubscribe
--
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_default_filter macro changes

Hello Perl packagers,

I've just changed `perl_default_filter' SPEC macro in Fedora 21, which many of
you use in your packages.

There are three changes:

(1) I have removed filtering non-system shared libraries because this is now
done by rpmbuild itself. See
https://bugzilla.redhat.com/show_bug.cgi?id=1020809 for more details.

(2) I've anchored the regular expressions to the beginning of a text. E.g.
/perl\(VMS/ changed to /^perl\(VMS/. This should make the filter more precise.

(3) The perl_default_filter appends the filters instead of replacing them now.
So you can use use perl_default_filter macro with other macros modyfing
__requires_exclude and similar symbols and in any order now. This will be
handy if your package builds more langague bindings and you would like to
apply all the filters specific for each language.

I did some tests, so I believe this change should not cause any harm.

-- Petr


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

Broken dependencies: perl-MIME-Lite-HTML



perl-MIME-Lite-HTML has broken dependencies in the rawhide tree:
On x86_64:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On i386:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
On armhfp:
perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires 
perl(:MODULE_COMPAT_5.16.0)
Please resolve this as soon as possible.


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

Broken dependencies: perl-Language-Expr



perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


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

[perl-Test-Output] Update to 1.02

commit 838477b345ea068cee10f1019ca984d95422f11c
Author: Paul Howarth p...@city-fan.org
Date:   Tue Oct 22 18:31:00 2013 +0100

Update to 1.02

- New upstream release 1.02
  - Re-do everything with Capture::Tiny rather than ties
- Make %files list more explicit

 .gitignore|4 +---
 perl-Test-Output.spec |   14 ++
 sources   |2 +-
 3 files changed, 12 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index bcf27fa..edc694c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1 @@
-Test-Output-0.12.tar.gz
-/Test-Output-0.16.tar.gz
-/Test-Output-1.01.tar.gz
+/Test-Output-[0-9.]*.tar.gz
diff --git a/perl-Test-Output.spec b/perl-Test-Output.spec
index 6bfb576..01612ea 100644
--- a/perl-Test-Output.spec
+++ b/perl-Test-Output.spec
@@ -1,12 +1,13 @@
 Name:   perl-Test-Output
-Version:1.01
-Release:9%{?dist}
+Version:1.02
+Release:1%{?dist}
 Summary:Utilities to test STDOUT and STDERR messages
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Test-Output/
 Source0:
http://www.cpan.org/authors/id/B/BD/BDFOY/Test-Output-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  perl(Capture::Tiny) = 0.17
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(File::Temp) = 0.17
@@ -42,10 +43,15 @@ make test
 
 %files
 %doc Changes LICENSE README TODO
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Test/
+%{_mandir}/man3/Test::Output.3pm*
 
 %changelog
+* Tue Oct 22 2013 Paul Howarth p...@city-fan.org - 1.02-1
+- Update to 1.02
+  - Re-do everything with Capture::Tiny rather than ties
+- Make %%files list more explicit
+
 * Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.01-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
diff --git a/sources b/sources
index 858cf0a..e6cfc2e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bea1fe88e8725a5b3f7b66e69fc83dd2  Test-Output-1.01.tar.gz
+d80890160737cdf4c3241d48428d33ab  Test-Output-1.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Test-Output/f20] Update to 1.02

Summary of changes:

  838477b... Update to 1.02 (*)

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

[perl-Test-Output] Created tag perl-Test-Output-1.02-1.fc21

The lightweight tag 'perl-Test-Output-1.02-1.fc21' was created pointing to:

 838477b... Update to 1.02
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Test-Output] Created tag perl-Test-Output-1.02-1.fc20

The lightweight tag 'perl-Test-Output-1.02-1.fc20' was created pointing to:

 838477b... Update to 1.02
--
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 TeX-Hyphen-1.01.tar.gz uploaded to lookaside cache by pghmcfc

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

8b185cc681e1352334acc9c7b1cabbca  TeX-Hyphen-1.01.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-TeX-Hyphen] Update to 1.01

commit 95dc4a66ab4824eeb09d2fbdd766d13d780b4cd0
Author: Paul Howarth p...@city-fan.org
Date:   Tue Oct 22 19:29:47 2013 +0100

Update to 1.01

- New upstream release 1.01
  - Updated the upstream URL to http://www.adelton.com/perl/TeX-Hyphen/
- Specify all dependencies
- Use %{_fixperms} macro rather than our own chmod incantation
- Don't need to remove empty directories from the buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't use macros for commands

 .gitignore   |2 +-
 perl-TeX-Hyphen.spec |   43 ---
 sources  |2 +-
 3 files changed, 30 insertions(+), 17 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5b351e8..177ad85 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-TeX-Hyphen-0.140.tar.gz
+/TeX-Hyphen-[0-9.]*.tar.gz
diff --git a/perl-TeX-Hyphen.spec b/perl-TeX-Hyphen.spec
index 2aa6c7a..46b5fd5 100644
--- a/perl-TeX-Hyphen.spec
+++ b/perl-TeX-Hyphen.spec
@@ -1,17 +1,19 @@
 Name:   perl-TeX-Hyphen
-Version:0.140
-Release:20%{?dist}
+Version:1.01
+Release:1%{?dist}
 Summary:Hyphenate words using TeX's patterns
-
 Group:  Development/Libraries
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/TeX-Hyphen/
+URL:http://www.adelton.com/perl/TeX-Hyphen/
 Source0:
http://www.cpan.org/authors/id/J/JA/JANPAZ/TeX-Hyphen-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
+BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch:  noarch
+BuildRequires:  perl(Benchmark)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
 
 %description
 %{summary}.
@@ -22,16 +24,15 @@ Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} 
-V:version`; echo $versi
 
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT
 
 
 %check
@@ -43,13 +44,25 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %files
-%defattr(-,root,root,-)
 %doc Changes README
 %{perl_vendorlib}/TeX/
-%{_mandir}/man3/*.3pm*
+%{_mandir}/man3/TeX::Hyphen.3pm*
+%{_mandir}/man3/TeX::Hyphen::czech.3pm*
+%{_mandir}/man3/TeX::Hyphen::german.3pm*
 
 
 %changelog
+* Tue Oct 22 2013 Paul Howarth p...@city-fan.org - 1.01-1
+- Update to 1.01
+  - Updated the upstream URL to http://www.adelton.com/perl/TeX-Hyphen/
+- Specify all dependencies
+- Use %%{_fixperms} macro rather than our own chmod incantation
+- Don't need to remove empty directories from the buildroot
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Drop %%defattr, redundant since rpm 4.4
+- Make %%files list more explicit
+- Don't use macros for commands
+
 * Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.140-20
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
@@ -75,7 +88,7 @@ rm -rf $RPM_BUILD_ROOT
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
 * Wed Dec 22 2010 Marcela Maslanova mmasl...@redhat.com - 0.140-12
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
 
 * Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.140-11
 - Mass rebuild with perl-5.12.0
@@ -108,7 +121,7 @@ rm -rf $RPM_BUILD_ROOT
 * Thu Dec 29 2005 Jose Pedro Oliveira jpo at di.uminho.pt - 0.140-3
 - Dist tag.
 
-* Fri Apr  7 2005 Michael Schwendt mschwendt[AT]users.sf.net - 0.140-2
+* Wed Apr  6 2005 Michael Schwendt mschwendt[AT]users.sf.net - 0.140-2
 - rebuilt
 
 * Fri Jun 11 2004 Jose Pedro Oliveira jpo at di.uminho.pt - 0:0.140-0.fdr.1
diff --git a/sources b/sources
index a018e15..d822049 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0ee75a22525461e72ceab8e82377d617  TeX-Hyphen-0.140.tar.gz
+8b185cc681e1352334acc9c7b1cabbca  TeX-Hyphen-1.01.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-TeX-Hyphen/f20] Update to 1.01

Summary of changes:

  95dc4a6... Update to 1.01 (*)

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

[perl-TeX-Hyphen] Created tag perl-TeX-Hyphen-1.01-1.fc21

The lightweight tag 'perl-TeX-Hyphen-1.01-1.fc21' was created pointing to:

 95dc4a6... Update to 1.01
--
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-TeX-Hyphen] Created tag perl-TeX-Hyphen-1.01-1.fc20

The lightweight tag 'perl-TeX-Hyphen-1.01-1.fc20' was created pointing to:

 95dc4a6... Update to 1.01
--
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 1016246] perl-Math-NumSeq-65 is available

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

Fedora Update System upda...@fedoraproject.org changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Math-NumSeq-65-1.fc18
 Resolution|--- |ERRATA
Last Closed||2013-10-22 23:38:01



--- Comment #5 from Fedora Update System upda...@fedoraproject.org ---
perl-Math-NumSeq-65-1.fc18 has been pushed to the Fedora 18 stable repository. 
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=JoPyxzWtCra=cc_unsubscribe
--
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 1016246] perl-Math-NumSeq-65 is available