I wrote small script to list FTBFS koji entries

2015-02-12 Thread Marcin Juszkiewicz 
Hi

As my work usually is around fixing packages which failed to build on
AArch64 I spend lot of time with Koji.

Today I started writing script which has to list all current FTBFS
entries from selected Koji instance - kind like [1] does but with few
extras:

- no packages which got built later
- no repeated entries

I plan to make something like Ubuntu has [2] which was great help when I
was working on fixing packages while working for Canonical.

No idea how far I will go with it but something like generator for such
page is on my to do list.

Current version of script is on [3]. My Python skills maybe are not the
greatest ones but script works for me.

Patches, ideas, bugs are welcome.


1. http://arm.koji.fedoraproject.org/koji/builds?state=3order=-build_id
2. http://qa.ubuntuwire.com/ftbfs/
3. https://github.com/hrw/fedora-koji-scripts
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Proposal] Ring-based Packaging Policies

2015-02-12 Thread Stephen Gallagher 
(Logistical note: please keep all replies to this thread on
devel@lists.fedoraproject.org)

tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?

== Premise ==

So, some time ago, we started talking about dividing up the Fedora
package set into a series of rings. One of the driving purposes behind
this idea was to re-evaluate our policies for packaging in each of these
rings. A fair amount of time has passed and no formal discussions have
taken place (that I have seen, at any rate), so I'm going to provide
here a simple starter proposal that we can work from and see where it
leads.

To begin, I'll try to identify some of the major advantages and
disadvantages in our current policies. (In no particular order...)

=== Advantages ===
* Consistency: every shared library, language-specific module and
application should have packaging consistent with others in its
category. This makes it easier for comaintainers and provenpackagers to
pick it up and work on it.

* The no-bundled-libraries policy means that when a library module
requires an update, it means that only one package needs to be modified
in order to enhance all applications on the system that consumes it.
This is a significant time-saver when it comes to dealing with
(increasingly common) security vulnerabilities.

* Package review front-loads the task of educating the packagers. It
guarantees that packages enter the collection by meeting a very high
standard. This does a great deal to accomplish the consistency
mentioned above.

* Legal review and the FPCA ensures that Fedora remains true to its
Freedom Foundation (as well as protecting Fedora contributors from the
perils of the international legal system).

=== Disadvantages ===
* Very strict policies often leads to potential packagers giving up.

* Package reviews for less-interesting packages (such as those for less
popular SIGs) often remain un-reviewed for weeks, months or even years.

* The package policies are only ever reviewed during the initial
creation of the package. Once that initial (high) hurdle is cleared, the
packager essentially has free reign to do whatever they want with their
package. This sometimes means that as time passes, the spec files
bit-rot or otherwise start accumulating other inconsistencies. (A
common example is the package whose upstream starts bundling a library
without the packager noticing).

* Many upstream projects do not concern themselves with being in any
particular distribution (with the notable example being the
Debian/Ubuntu flavors which have amassed a sufficient apparent userbase
that they sometimes get special treatment). For a variety of reasons,
this often leads directly to bundling the vast majority of their
dependencies. This is done for many reasons, but the two most common are
supportability and portability; it's impossible for many upstreams to
actually QA their package with every possible distro library. Instead,
if they ship everything they depend on, they can guarantee *that*
specific combination. This moves the responsibility from the
distribution to the upstream package to maintain their bundled
libraries.

* With many languages, there is no possibility of installing multiple
versions of the same library on the same system, so if an application
requires a newer or older version of the library than is in Fedora to
run, it fails. For those languages that *do* allow this, it still adds a
significant maintenance burden on the packagers to keep multiple
versions of the same package up-to-date (which gets particularly hard
when upstream abandons a version that something else in Fedora depends
on...)


== Analysis ==
First, I will make an assumption based on the First Foundation: We as
the Fedora Project want people to have access to the software that they
desire. We may disagree on how that is to be achieved, but I believe the
goal is the same.

Second, I will call attention to the fact that different Fedora users
have very different needs from the software. For example, those running
Fedora Server and Fedora Cloud are likely far more concerned with Fedora
as a *deployment* platform than they are as a *development* platform.
Folks running Fedora Workstation or the KDE spin are likely to be
somewhat more interested in the development side of things (though not
exclusively).

Packaging software for development and packaging it for real-world
deployment can be very different. I'm not going to attempt to identify
all the ways that this can be the case in this email. Others have done
so with great verbosity in the past and I will not attempt to re-hash
them.

Thirdly, I will note (again) that many upstream projects have moved away
from a distro-centric model. This is in part because unlike in the past,
there are a great many distributions out there now, all with individual
packaging requirements to be inside those distros. Taken in concert with
the behaviors of many of the

Re: 3 days without pushes ?

2015-02-12 Thread Sérgio Basto 
On Qui, 2015-02-12 at 14:41 -0500, Corey Sheldon wrote:
 Aka patience and to be totally honest and blunt, if you have a
 alpha/beta tester group and or a solid forum/mailing list with updates
 to status this should seriously not be a setback  3 weeks on the other
 hand might qualify.Appreciate the eagerness to partake in
 development /packaging but things happen from time to time learn to
 roll with the tides as they say

yeah, but we should have some regularity, I don't like waiting without
knowing the delay, in this case is pushing to stable, is just for my
organization, to see what is in stable and what let in testing, and I
have been patient. 
But when someone else send a package to testing and I want test it, if
we don't have a push to testing, force me download packages manually .  
The point here is push to testing should be more quickly than push to
stable .

Thanks , 
-- 
Sérgio M. B.

-- 
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: [Proposal] Ring-based Packaging Policies

2015-02-12 Thread Colin Walters 
On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:

 tl;dr Shall we consider requiring a lesser package review for packages
 that are not present on Product or Spin install media?

It's worth noting here that having two levels is not really going
to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
for quite a while:
https://help.ubuntu.com/community/Repositories/Ubuntu

I just have one question: You're defining this split at the *runtime*
level.  Last I saw the Base working group was trying to cut down BuildRequires
(but sadly I haven't seen them fighting Requires yet - I would love
 if someone did that for Perl)

If Ring 0 packages BuildRequire Ring 1 (or further)
packages, ultimately their quality is going to be somewhat contingent
on them.  Using bundling as a differentiator though, it does seem
like there's likely a lot less pressure to require quick security
updates for BuildRequires.

Anyways, something I think is missing from here is more
details on how this on the install media set distinction
is maintained over time.  If it isn't separate (yum) repositories
it seems like it's going to be hard to enforce.

(Who would notice if a package in 0 started depending on a ring
 1?  Would that imply the new dependency needed another
 review pass?)
-- 
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: Changing default configuration

2015-02-12 Thread Ryan S. Brown 
On 02/10/2015 09:16 AM, Alberto Ruiz wrote:
 On Tue, 2015-02-10 at 14:38 +0100, Marek Skalický wrote:
 Matthew Miller píše v Út 10. 02. 2015 v 06:19 -0500:
 On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote:
 does someone know what are Fedora Guidelines (or something similar)
 saying about this bug
 https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ?
 Is is possible to change default configuration file depending on
 available free space?

 Generally, making such a decision at install time is bad, because that
 might not reflect _runtime_. For example, in the cloud image, we use a
 / filesystem as small as Anaconda will allow, but that grows to fill
 available storage when the image is booted.

 Is there a way to make this decision when mongodb runs?


 It should be possible to code this into sysv init script. But I am not
 sure if it is possible to do the same in systemd service...?

 My question was also about whether this should be done by mongoDB? Or
 there should be default configuration and user can easily change it in
 configuration file?
 
 It should be done by MongoDB, I would get in touch with the upstream and
 discuss the problem with them.
 
 Marek

I don't think there should be run- *or* install-time determination on
this. Smallfiles is used for more than just free space reasons and only
the end operator knows whether they need it or not. There's a documented
upstream default, and it's the operator's job to change it if they need to.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
-- 
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: 3 days without pushes ?

2015-02-12 Thread Corey Sheldon 
Aka patience and to be totally honest and blunt, if you have a alpha/beta
tester group and or a solid forum/mailing list with updates to status this
should seriously not be a setback  3 weeks on the other hand might
qualify.Appreciate the eagerness to partake in development /packaging
but things happen from time to time learn to roll with the tides as they say

Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
(p) 310.909.7672
Google+: https://www.plus.google.com/+CoreySheldon
LinkedIn:https://www.linkedin.com/profile/view?id=70127804
Github: https://www.github.com/linux-modder

http://www.facebook.com/1stclassmobileshine

Tutoring in person or via any of the following platforms:
https://www.wizperts.com
https://www.hackhands.com
https://airpair.com
https:// https://helpouts.google.comfieldnation.com


{PayPal,Google Wallet/Play store, Apple Pay}
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1

mQSuBFSFm3MRDADMQUFvE2zeREEV2+mARfGttXR0HmamD3kJJMdRmGrtvHpEgTjK
cg8ylpkjRTBOl3pWzrEfoxREnS5Ej6BbGbEdGP8cRgpnACkzVirTDtb6JLatzPzh
4xqpuO6st8ATh7/RkLdsK8R5IzjqvkJ+Q99MGZxBr6w0AaP8KMKe32TU5CzQkSMH
hL+sZQlIVa5kiEbsvrYnYVrlvw9YFsHZQ38mxFyg0A4nmt3L+CBFS4LRdaQmsu07
Qr22aeOYdD4fWKkvEtGsy2MtxIOjqljdPk+lBqBiW3qK9J3DfGLQsVBholJFBMvY
S6aLj6ITDOezJ36hHNlpQmPMOQLShIkP3/dlq7Y2xhyLY/hXG83Pw6WF7kRzF7vG
bSqSDlMlmdnRzulnNtAaE4fzNtBR26oKSfMIwX9NUz4U1wFCVrzrOzEvvU2ZvU3k
ZlpyMdm1fCEdXJt/oOWBVa6PH31TTGaYKl8JH2gQ0Z9DixaTmPS56ch3mbRGMqyz
5PzEtzvaM5b3yzMBAN/guLOJVzGKSqHwEMjhfxwDweHiOS50FAXH8i9w8qyVC/sG
4iFlS/yjH6SBm5DEdAKwIbY5EuFexgyVoVDpCZ65VSspDwoiXaHubOfNYUAEkOFJ
o/YShNMInmajsB7kTlt5mlqsJlU/xAMGH6Zv+f5GIi2k8aDryZr+rHPHqs3lyCkb
7t7041z5mfy9/rJE+U20aVvBh/uUtSMm78CvmTcwdasskEpsiZR2ScuGUgc4ahlF
61dvEnCN+5mrTtPUQPISxtLGDUMhhrrw75z7LafPF6gFmMT/RLcnbrB1xPxPwxWR
m5QpfV6qUNmRoGKnGRlyYkBbLwWRsZRSEtgFHUqb8Y3ghG1rKkEh4paFyPOzbGFo
dZOHR4dsTStu41UE1MAdn41VhTjS/mQjI/CQPCIRPscjI64svBjQria3SV0iDqxb
+Z3ACGoHdKaUI5TiJhJkjEWUjOunUfSnhR124mf7uEIG/1sHJoYonPKTtYNy2mlB
ryZs7kZ3u7V3DV4TPMji3UC8sVV2+9HR2g0xxMEXyTA1AEoQeQIK05BthxX/auoM
AKrGRPvY96RfaO9rNSerJGH+7VGpr/O4UxRDytHzRRfDb9PzMjUSspS6DtSMhk1z
lB2+riyDwQ9HqgFk2PLgnj0LE/k9IxXDxtjjMAGAM1iBRJCsQZzoXfphOtZzU1bd
6teOAW2lsT+rp/+BwU7YxSLnEj0eFJgZTMAgNblLLzh3Cu53FNPauxdhacklYjj3
LO3d0CAkcHMA0ny+zXVoQupabgFLsgvVoSLqPqWVgrd5vS8gGWwvc+b4Q9YLWYpK
qwI9tD6Z5poSbQjJPKJLuJfhiQqMgvjeLZGFnTHe9O5s1+dKInW1DhUH6yq61Exj
0grDevF7vyBBEfxkGVeKPyOd7gy7dXMRUwuaQZZ/yd2vbPv8Vbe4ux5TaltFekYc
/F6bPWB2LwGAbxKchl5O9133C4VM6yO9bb0DiMMZFsJIUlIqnkDREgjMA30n2HZ4
Xzg+aho33VMRhzaE+YTZVfmNSZk7VlM4mprFKeBERycOyUNfU0B6hOwtrwrMp6gZ
47Q0Q29yZXkgU2hlbGRvbiAoRmVkb3JhIEtleSkgPHNoZWxkb24uY29yZXlAZ21h
aWwuY29tPoiABBMRCAAoBQJUhZtzAhsjBQkB4TOABgsJCAcDAgYVCAIJCgsEFgID
AQIeAQIXgAAKCRDpWMXWcYv1l0L9APwJ2famE03OlzpOMddQIxsGEnb6cgb4X8ZE
tXNnkfmPZwD9Gt8tXcaLOqiwKjQqyiLRP3SoIqwUAJHe7GciZDZ5A/S5BA0EVIWb
cxAQAK6uQCb9BZLnWUTXZAAKDK0qT2BVOzUBefB3YD5Eixtmdf7mqjxSfs2Mci5D
rGdNZowgA9HnEeIzqg78giit21UlXhqCOt22hj0eO+Q1F401Dr6RFkkN8yQdVI1D
1UePDZQ/zz/fD0miD9KPQxGr6mwGWbn8it5NFHt1EnZMIYkXfS/TJxaMsrGY6Q2F
RLjhQ3f69i0XjqPg1/IFx5C34ds0hw3K47yDTrgqR5pp309FjselYfLkC4z8R6ti
TRbaXMwOhGuk56rEYB7Y6uzdxuQvS1zM/qqqmff3VqjwyCpVgTuqUlpiD8k/e2nq
HB/ZvrOUWgSqT6NKWBn915DlVB5U95jxLFafopI4N12rsEGW7wIgPolXZ2yU8C4S
E5kE84T8ahdHGAP9lHbqPhnA7aO1zuAl6hJB+Dcpt1nbPdqfwWR0FffkUU9kL6Qh
CiV2ZiAx6Eqm8i5pM21aTlYo0RUosK4r0xFTDZ7SR7d7EGjmfO5k+YjoUSlqOvIb
2jNg6+ZD9EFzSEq5QHMViFnMsp1j+nEYiL44GIH4NPnQWCc3/p7vdxje3HTC4eBt
E4Dp4CkTjX4MpiNrUMw57kjahv/nfITsDUcu4WcMc9e0F8GtfIgy/p3XVsXTqdcm
CersMUgFZIbptI/bGwfj713QElkNiah1NGZc52YAmFWO9f4/AAMFD/4mjUWEaW/D
plbV2tyo7w4j9cHT89+uz5R/Q/OOUjY6PhoFfAzfRAiBlOVjGba/IiYig0HJoBW8
r1HDrfO8xHCHCA9NXiBrhCLFnGM+T6m5+5YpMz5jnhv+xvudm0Dg5VxLtcBjo0/j
OUxIHBEcvm0/H3MgABHJc/vTR5n/hNJ6kGRgfgg37qIruE4GOu7BeNABBW+8IIyP
1mXvQl/zIfokAPiDqW9Rmmuj5znOc+UvOX8CcJU/8YQYNIHtCzISkFGtkcz1spET
BL6Bu5WrGbdStHFzoUKpaHQumyaHBBDn0VpJCjiRwf7Gu+LlZ/Wlah4KVo4nhk3k
NsonNqOZjK16UZnrMrdK4VIDLxzCtlrmlmbGLuH8YUmmlxuw0Nt9EiYtpFTiNUQq
Iplu8Me9O9hZ8ZmzlgJ+0tSzlXELOUUOwIgiQs67c9bEn18pHIln4YyrfCvPlhyw
Ke+xXUeGGEXmIrKTjCQrFA9eWs3nPTfTG7xQmGkf93kUZHOJMohDJlpIHQza1uyt
lu2s+s8HXiAHOBh6ZbMloL+Rg4M+w5+eKU2abQCW8QC1v9u3OgKWcZ1jZbYyTCyI
8Y7NQyiE/akAXQiUb1MHIezN7QpzHEpGxDyVr3tEYF26deJ8sVBxzd+m2wSWyFlT
dPyuTxJJFIRCYtK5wpbPhrDlQfwL5riDzIhnBBgRCAAPBQJUhZtzAhsMBQkB4TOA
AAoJEOlYxdZxi/WXW8wA/jWWfofUPZYg3QOquXIR/QDTm/fsQwTx+2vO4nEXRKlq
AP0YOSlkGoCbaeFHgX+RU5lVfHzRyONK5T7RcDTcvJD83A==
=v6Cq
-END PGP PUBLIC KEY BLOCK-





On Thu, Feb 12, 2015 at 2:36 PM, Till Maas opensou...@till.name wrote:

 On Thu, Feb 12, 2015 at 06:52:11PM +, Sérgio Basto wrote:

  2015-02-09 20:13:21
  This update has been submitted for stable by sergiomb  .
 
  Today is 12 and still not pushed, how we can devel when have to wait 3
  days to a push ? , pushes should be regular and not random .
  What happened last 3 days ?  Seems that I'm not lucky when I push
  things , in weekends sometimes I have to wait 48 hours .

 Update pushes will be resumed as soon as possible. Because of branching
 and problems with the signing

Re: 3 days without pushes ?

2015-02-12 Thread Stephen John Smoogen 
On 12 February 2015 at 12:53, Sérgio Basto ser...@serjux.com wrote:

 On Qui, 2015-02-12 at 14:41 -0500, Corey Sheldon wrote:
  Aka patience and to be totally honest and blunt, if you have a
  alpha/beta tester group and or a solid forum/mailing list with updates
  to status this should seriously not be a setback  3 weeks on the other
  hand might qualify.Appreciate the eagerness to partake in
  development /packaging but things happen from time to time learn to
  roll with the tides as they say

 yeah, but we should have some regularity, I don't like waiting without
 knowing the delay, in this case is pushing to stable, is just for my
 organization, to see what is in stable and what let in testing, and I
 have been patient.


I realize we haven't have a branch in a while due to the long Fedora 20
cycle, but this is how things are done usually after a branch.. there can
be up to a week delay for pushes as various things get ironed out.



 But when someone else send a package to testing and I want test it, if
 we don't have a push to testing, force me download packages manually .
 The point here is push to testing should be more quickly than push to
 stable .

 Thanks ,
 --
 Sérgio M. B.

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




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

3 days without pushes ?

2015-02-12 Thread Sérgio Basto 
Hi, .

2015-02-09 20:13:21
This update has been submitted for stable by sergiomb  .

Today is 12 and still not pushed, how we can devel when have to wait 3
days to a push ? , pushes should be regular and not random . 
What happened last 3 days ?  Seems that I'm not lucky when I push
things , in weekends sometimes I have to wait 48 hours . 

Thanks, 
-- 
Sérgio M. B.

-- 
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: [Proposal] Ring-based Packaging Policies

2015-02-12 Thread Stephen Gallagher 



On Thu, 2015-02-12 at 14:01 -0500, Colin Walters wrote:
 On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:
 
  tl;dr Shall we consider requiring a lesser package review for packages
  that are not present on Product or Spin install media?
 
 It's worth noting here that having two levels is not really going
 to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
 for quite a while:
 https://help.ubuntu.com/community/Repositories/Ubuntu

 I just have one question: You're defining this split at the *runtime*
 level.  Last I saw the Base working group was trying to cut down BuildRequires
 (but sadly I haven't seen them fighting Requires yet - I would love
  if someone did that for Perl)
 
 If Ring 0 packages BuildRequire Ring 1 (or further)
 packages, ultimately their quality is going to be somewhat contingent
 on them.  Using bundling as a differentiator though, it does seem
 like there's likely a lot less pressure to require quick security
 updates for BuildRequires.
 
 Anyways, something I think is missing from here is more
 details on how this on the install media set distinction
 is maintained over time.  If it isn't separate (yum) repositories
 it seems like it's going to be hard to enforce.
 

Well, it already *is* a separate repository to create the build trees,
so we always have a clear picture of what's in them. (The Everything and
updates repos are always a superset).

 (Who would notice if a package in 0 started depending on a ring
  1?  Would that imply the new dependency needed another
  review pass?)

We'd have to be keeping an eye on the contents of the install trees and
yes, that would require a new review pass, in my current proposal. I'd
be willing to grant a blanket exception for packages that were in the
distro up to the acceptance of this proposal (rather than only those
that were on the install media) though.


signature.asc
Description: This is a digitally signed message part
-- 
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: [Proposal] Ring-based Packaging Policies

2015-02-12 Thread Alec Leamas 

On 12/02/15 19:32, Stephen Gallagher wrote:

(Logistical note: please keep all replies to this thread on
devel@lists.fedoraproject.org)

tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?



Thanks for bringing this up. We really need to do something about this, 
and the proposal is likely to get things rolling.


This is really about two things, right? A lighter review and a general 
bundling exception for packages not in the core (?)


As for the bundling exception I more or less just agree. One detail 
might be to add some text about not having bundled libraries in system 
locations, and not exporting (filtering) them.


As for the lighter review this is not so clear to me. I agree that we 
need to relax the review, but:


  - Wouldn't it feel a little more comfortable to list the exceptions 
we allow compared to a regular review rather than starting with just 
some broad statements what the review is?


  - Shouldn't we make a distinction between 'review' and 'pass'. E. g., 
even if we allow bundled libs, we should definitely review and locate 
them. Isn't the situation similar for other things: while we still 
review them, things that are blockers in ring 0 could pass in ring 1?


Colin walters wrote:


Anyways, something I think is missing from here is more
details on how this on the install media set distinction
is maintained over time.  If it isn't separate (yum) repositories
it seems like it's going to be hard to enforce.



A virtual provides in all ring 1 packages?


Cheers!

--alec
--
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: [Proposal] Ring-based Packaging Policies

2015-02-12 Thread Paul Howarth 
On Thu, 12 Feb 2015 14:01:43 -0500
Colin Walters walt...@verbum.org wrote:

 On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote:
 
  tl;dr Shall we consider requiring a lesser package review for
  packages that are not present on Product or Spin install media?
 
 It's worth noting here that having two levels is not really going
 to be new to the ecosystem; e.g. Ubuntu has had Main/Universe
 for quite a while:
 https://help.ubuntu.com/community/Repositories/Ubuntu
 
 I just have one question: You're defining this split at the *runtime*
 level.  Last I saw the Base working group was trying to cut down
 BuildRequires (but sadly I haven't seen them fighting Requires yet -
 I would love if someone did that for Perl)

We generally have requires for most optional functionality in Perl
packages at the moment, to avoid bugs being raised about missing
dependencies when people try to use that optional functionality.

If there was consensus about use of soft dependencies, that would
probably help a lot in the Perl world.

Paul.
-- 
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: 3 days without pushes ?

2015-02-12 Thread Till Maas 
On Thu, Feb 12, 2015 at 07:53:05PM +, Sérgio Basto wrote:

 yeah, but we should have some regularity, I don't like waiting without
 knowing the delay, in this case is pushing to stable, is just for my

Nobody is delaying pushes on purpose and everyone involved into it would
like it to happen faster. However, there is developer manpower missing
to fix and improve tools, that nobody can make magically appear.

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

[perl-Wx-Perl-DataWalker] Run X11 tests using xvfb-run

2015-02-12 Thread Jitka Plesnikova 
commit 039e0987bda366244807a972944ebe9c2fc8b8dd
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 13:07:31 2015 +0100

Run X11 tests using xvfb-run

 perl-Wx-Perl-DataWalker.spec |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)
---
diff --git a/perl-Wx-Perl-DataWalker.spec b/perl-Wx-Perl-DataWalker.spec
index 11cc8b8..a45456a 100644
--- a/perl-Wx-Perl-DataWalker.spec
+++ b/perl-Wx-Perl-DataWalker.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Wx-Perl-DataWalker
 Version:0.02
-Release:18%{?dist}
+Release:19%{?dist}
 Summary:Implement subclass that shows relatively simple structure
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -44,8 +44,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 
 %check
 %if %{use_x11_tests}
-xinit /bin/sh -c 'rm -f ok; make test  touch ok' -- /usr/bin/Xvfb :666
-test -e ok
+xvfb-run -a make test
 %endif
 
 %files
@@ -54,6 +53,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 12 2015 Jitka Plesnikova jples...@redhat.com - 0.02-19
+- Run X11 tests using xvfb-run (BZ#1179570)
+
 * Thu Sep 04 2014 Jitka Plesnikova jples...@redhat.com - 0.02-18
 - Perl 5.20 rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1189459] perl-Debug-Client-0.29-3.fc22 FTBFS: Dead-lock in mock environment

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189459



--- Comment #1 from Petr Pisar ppi...@redhat.com ---
This is caused by upgrading perl-Term-ReadLine-Gnu from 1.25 to 1.26. The
dead-lock is here:

$ prove -b -v t/07-initialize.t
t/07-initialize.t ..
1..4
ok 1 - initialize with prams
LOCK
ok 2 - quit with prams
ok 3 - initialize without prams
ok 4 - quit witout prams
ok

Either is a bug in the perl-Term-ReadLine-Gnu or it's a race in the test
because of suspicious sleep call:

ok( my $debugger = Debug::Client-new(
host   = $host,
port   = $port,
porto  = $porto,
listen = $listen,
reuse  = $reuse_addr
),
'initialize with prams'
);
$debugger-run;

sleep 1;

ok( $debugger-quit, 'quit with prams' );

-- 
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=72a5mpLJ82a=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

Re: Firefox addon signing

2015-02-12 Thread Nikos Roussos 
On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth m...@cchtml.com 
wrote:
I'm sure those that need to know, know, but for those that haven't 
heard[1]
Mozilla's official Firefox build will enforce addons to contain a 
Mozilla signature

without any runtime option to disable the check.

Initially this prevents Fedora packaged addons since they are 
unsigned. The Mozilla
signing process takes time and can't be part of a package building 
process.


Is Fedora going to get authorization to build Firefox with a runtime 
disable option?


If the only way is to completely disable this feature, I'd prefer we 
don't.

I wouldn't like for us to ship a less secure build of Firefox.
-- 
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 IO-AIO-4.32.tar.gz uploaded to lookaside cache by pghmcfc

2015-02-12 Thread Paul Howarth 
A file has been added to the lookaside cache for perl-IO-AIO:

9577f5be9d2ecf3980607462106df149  IO-AIO-4.32.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

Orphaned Packages in branched (2015-02-12)

2015-02-12 Thread opensource 
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

 Package(co)maintainersStatus Change 

bfgminerorphan, pwouters   0 weeks ago   
clc-intercalorphan, iarnell0 weeks ago   
coneorphan, steve  0 weeks ago   
dbus-tools  orphan, miminar0 weeks ago   
dircproxy   orphan, jwilson, kevin 0 weeks ago   
egtkorphan, cicku, odysseus, raphgro   0 weeks ago   
fldigi-doc  orphan, dp67   0 weeks ago   
ip6sic  orphan, davej  0 weeks ago   
isicorphan, davej  0 weeks ago   
javasqlite  orphan 0 weeks ago   
mate-user-share orphan, raveit65, vicodan  0 weeks ago   
maven-anno-plugin   orphan, goldmann   0 weeks ago   
mojomojoorphan, iarnell, perl-sig  0 weeks ago   
ninja   orphan, adrian 0 weeks ago   
pympdtouchgui   orphan, slankes0 weeks ago   
python-asyncmongo   orphan, silas  0 weeks ago   
python-gflags   orphan, silas  0 weeks ago   
umlgraphorphan, akurtakov, fabiand, raphgro0 weeks ago   
visualvmorphan, davidcl, dbhole, jerboaa, jvanek   0 weeks ago   
xnoise  orphan, salimma0 weeks ago   
zukini  orphan, odysseus   0 weeks ago   
zukiwi  orphan, odysseus   0 weeks ago   

The following packages require above mentioned packages:
Depending on: javasqlite (1), status change: 2015-02-10 (0 weeks ago)
weka (maintained by: mjakubicek)
weka-3.6.8-4.fc21.noarch requires javasqlite = 20140624-4.fc22


Depending on: python-gflags (1), status change: 2015-02-10 (0 weeks ago)
starcal (maintained by: hedayat)
starcal-2.4.0-2.fc22.noarch requires python-gflags = 
1.5.1-6.fc21


Affected (co)maintainers
adrian: ninja
akurtakov: umlgraph
cicku: egtk
davej: isic, ip6sic
davidcl: visualvm
dbhole: visualvm
dp67: fldigi-doc
fabiand: umlgraph
goldmann: maven-anno-plugin
hedayat: python-gflags
iarnell: mojomojo, clc-intercal
jerboaa: visualvm
jvanek: visualvm
jwilson: dircproxy
kevin: dircproxy
miminar: dbus-tools
mjakubicek: javasqlite
odysseus: zukiwi, egtk, zukini
perl-sig: mojomojo
pwouters: bfgminer
raphgro: umlgraph, egtk
raveit65: mate-user-share
salimma: xnoise
silas: python-gflags, python-asyncmongo
slankes: pympdtouchgui
steve: cone
vicodan: mate-user-share

Orphans (22): bfgminer clc-intercal cone dbus-tools dircproxy egtk
fldigi-doc ip6sic isic javasqlite mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
python-gflags umlgraph visualvm xnoise zukini zukiwi


Orphans (dependend on) (2): javasqlite python-gflags


Orphans (branched) for at least 6 weeks (dependend on) (0):


Orphans  (branched)(not depended on) (20): bfgminer clc-intercal cone
dbus-tools dircproxy egtk fldigi-doc ip6sic isic mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
umlgraph visualvm xnoise zukini zukiwi


Orphans (branched) for at least 6 weeks (not dependend on) (0):


Depending packages (branched) (2): starcal weka


Packages depending on packages orphaned (branched) for more than 6
weeks (0):

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
--
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

Orphaned Packages in rawhide (2015-02-12)

2015-02-12 Thread opensource 
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

 Package(co)maintainersStatus Change 

ale orphan, cicku, silfreed0 weeks ago   
bfgminerorphan, pwouters   2 weeks ago   
clc-intercalorphan, iarnell13 weeks ago  
coneorphan, steve  13 weeks ago  
dbus-tools  orphan, miminar14 weeks ago  
dircproxy   orphan, jwilson, kevin 5 weeks ago   
egtkorphan, cicku, odysseus, raphgro   3 weeks ago   
fldigi-doc  orphan, dp67   12 weeks ago  
ip6sic  orphan, davej  5 weeks ago   
isicorphan, davej  5 weeks ago   
javasqlite  orphan 8 weeks ago   
mate-user-share orphan, raveit65, vicodan  1 weeks ago   
maven-anno-plugin   orphan, goldmann   8 weeks ago   
mojomojoorphan, iarnell, perl-sig  13 weeks ago  
ninja   orphan, adrian 1 weeks ago   
pympdtouchgui   orphan, slankes4 weeks ago   
python-asyncmongo   orphan, silas  9 weeks ago   
python-gflags   orphan, silas  9 weeks ago   
umlgraphorphan, akurtakov, fabiand, raphgro9 weeks ago   
visualvmorphan, davidcl, dbhole, jerboaa, jvanek   0 weeks ago   
xnoise  orphan, salimma5 weeks ago   
zukini  orphan, odysseus   3 weeks ago   
zukiwi  orphan, odysseus   3 weeks ago   

The following packages require above mentioned packages:
Depending on: javasqlite (1), status change: 2014-12-12 (8 weeks ago)
weka (maintained by: mjakubicek)
weka-3.6.8-4.fc21.noarch requires javasqlite = 20140624-4.fc22


Depending on: python-gflags (1), status change: 2014-12-09 (9 weeks ago)
starcal (maintained by: hedayat)
starcal-2.4.0-2.fc22.noarch requires python-gflags = 
1.5.1-6.fc21


Affected (co)maintainers
adrian: ninja
akurtakov: umlgraph
cicku: ale, egtk
davej: isic, ip6sic
davidcl: visualvm
dbhole: visualvm
dp67: fldigi-doc
fabiand: umlgraph
goldmann: maven-anno-plugin
hedayat: python-gflags
iarnell: mojomojo, clc-intercal
jerboaa: visualvm
jvanek: visualvm
jwilson: dircproxy
kevin: dircproxy
miminar: dbus-tools
mjakubicek: javasqlite
odysseus: zukiwi, egtk, zukini
perl-sig: mojomojo
pwouters: bfgminer
raphgro: umlgraph, egtk
raveit65: mate-user-share
salimma: xnoise
silas: python-gflags, python-asyncmongo
silfreed: ale
slankes: pympdtouchgui
steve: cone
vicodan: mate-user-share

Orphans (23): ale bfgminer clc-intercal cone dbus-tools dircproxy egtk
fldigi-doc ip6sic isic javasqlite mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
python-gflags umlgraph visualvm xnoise zukini zukiwi


Orphans (dependend on) (2): javasqlite python-gflags


Orphans (rawhide) for at least 6 weeks (dependend on) (2): javasqlite
python-gflags


Orphans  (rawhide)(not depended on) (21): ale bfgminer clc-intercal
cone dbus-tools dircproxy egtk fldigi-doc ip6sic isic
mate-user-share maven-anno-plugin mojomojo ninja pympdtouchgui
python-asyncmongo umlgraph visualvm xnoise zukini zukiwi


Orphans (rawhide) for at least 6 weeks (not dependend on) (8):
clc-intercal cone dbus-tools fldigi-doc maven-anno-plugin mojomojo
python-asyncmongo umlgraph


Depending packages (rawhide) (2): starcal weka


Packages depending on packages orphaned (rawhide) for more than 6
weeks (2): starcal weka

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:

Orphaned Packages in branched (2015-02-12)

2015-02-12 Thread opensource 
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

 Package(co)maintainersStatus Change 

bfgminerorphan, pwouters   0 weeks ago   
clc-intercalorphan, iarnell0 weeks ago   
coneorphan, steve  0 weeks ago   
dbus-tools  orphan, miminar0 weeks ago   
dircproxy   orphan, jwilson, kevin 0 weeks ago   
egtkorphan, cicku, odysseus, raphgro   0 weeks ago   
fldigi-doc  orphan, dp67   0 weeks ago   
ip6sic  orphan, davej  0 weeks ago   
isicorphan, davej  0 weeks ago   
javasqlite  orphan 0 weeks ago   
mate-user-share orphan, raveit65, vicodan  0 weeks ago   
maven-anno-plugin   orphan, goldmann   0 weeks ago   
mojomojoorphan, iarnell, perl-sig  0 weeks ago   
ninja   orphan, adrian 0 weeks ago   
pympdtouchgui   orphan, slankes0 weeks ago   
python-asyncmongo   orphan, silas  0 weeks ago   
python-gflags   orphan, silas  0 weeks ago   
umlgraphorphan, akurtakov, fabiand, raphgro0 weeks ago   
visualvmorphan, davidcl, dbhole, jerboaa, jvanek   0 weeks ago   
xnoise  orphan, salimma0 weeks ago   
zukini  orphan, odysseus   0 weeks ago   
zukiwi  orphan, odysseus   0 weeks ago   

The following packages require above mentioned packages:
Depending on: javasqlite (1), status change: 2015-02-10 (0 weeks ago)
weka (maintained by: mjakubicek)
weka-3.6.8-4.fc21.noarch requires javasqlite = 20140624-4.fc22


Depending on: python-gflags (1), status change: 2015-02-10 (0 weeks ago)
starcal (maintained by: hedayat)
starcal-2.4.0-2.fc22.noarch requires python-gflags = 
1.5.1-6.fc21


Affected (co)maintainers
adrian: ninja
akurtakov: umlgraph
cicku: egtk
davej: isic, ip6sic
davidcl: visualvm
dbhole: visualvm
dp67: fldigi-doc
fabiand: umlgraph
goldmann: maven-anno-plugin
hedayat: python-gflags
iarnell: mojomojo, clc-intercal
jerboaa: visualvm
jvanek: visualvm
jwilson: dircproxy
kevin: dircproxy
miminar: dbus-tools
mjakubicek: javasqlite
odysseus: zukiwi, egtk, zukini
perl-sig: mojomojo
pwouters: bfgminer
raphgro: umlgraph, egtk
raveit65: mate-user-share
salimma: xnoise
silas: python-gflags, python-asyncmongo
slankes: pympdtouchgui
steve: cone
vicodan: mate-user-share

Orphans (22): bfgminer clc-intercal cone dbus-tools dircproxy egtk
fldigi-doc ip6sic isic javasqlite mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
python-gflags umlgraph visualvm xnoise zukini zukiwi


Orphans (dependend on) (2): javasqlite python-gflags


Orphans (branched) for at least 6 weeks (dependend on) (0):


Orphans  (branched)(not depended on) (20): bfgminer clc-intercal cone
dbus-tools dircproxy egtk fldigi-doc ip6sic isic mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
umlgraph visualvm xnoise zukini zukiwi


Orphans (branched) for at least 6 weeks (not dependend on) (0):


Depending packages (branched) (2): starcal weka


Packages depending on packages orphaned (branched) for more than 6
weeks (0):

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaned Packages in rawhide (2015-02-12)

2015-02-12 Thread opensource 
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

 Package(co)maintainersStatus Change 

ale orphan, cicku, silfreed0 weeks ago   
bfgminerorphan, pwouters   2 weeks ago   
clc-intercalorphan, iarnell13 weeks ago  
coneorphan, steve  13 weeks ago  
dbus-tools  orphan, miminar14 weeks ago  
dircproxy   orphan, jwilson, kevin 5 weeks ago   
egtkorphan, cicku, odysseus, raphgro   3 weeks ago   
fldigi-doc  orphan, dp67   12 weeks ago  
ip6sic  orphan, davej  5 weeks ago   
isicorphan, davej  5 weeks ago   
javasqlite  orphan 8 weeks ago   
mate-user-share orphan, raveit65, vicodan  1 weeks ago   
maven-anno-plugin   orphan, goldmann   8 weeks ago   
mojomojoorphan, iarnell, perl-sig  13 weeks ago  
ninja   orphan, adrian 1 weeks ago   
pympdtouchgui   orphan, slankes4 weeks ago   
python-asyncmongo   orphan, silas  9 weeks ago   
python-gflags   orphan, silas  9 weeks ago   
umlgraphorphan, akurtakov, fabiand, raphgro9 weeks ago   
visualvmorphan, davidcl, dbhole, jerboaa, jvanek   0 weeks ago   
xnoise  orphan, salimma5 weeks ago   
zukini  orphan, odysseus   3 weeks ago   
zukiwi  orphan, odysseus   3 weeks ago   

The following packages require above mentioned packages:
Depending on: javasqlite (1), status change: 2014-12-12 (8 weeks ago)
weka (maintained by: mjakubicek)
weka-3.6.8-4.fc21.noarch requires javasqlite = 20140624-4.fc22


Depending on: python-gflags (1), status change: 2014-12-09 (9 weeks ago)
starcal (maintained by: hedayat)
starcal-2.4.0-2.fc22.noarch requires python-gflags = 
1.5.1-6.fc21


Affected (co)maintainers
adrian: ninja
akurtakov: umlgraph
cicku: ale, egtk
davej: isic, ip6sic
davidcl: visualvm
dbhole: visualvm
dp67: fldigi-doc
fabiand: umlgraph
goldmann: maven-anno-plugin
hedayat: python-gflags
iarnell: mojomojo, clc-intercal
jerboaa: visualvm
jvanek: visualvm
jwilson: dircproxy
kevin: dircproxy
miminar: dbus-tools
mjakubicek: javasqlite
odysseus: zukiwi, egtk, zukini
perl-sig: mojomojo
pwouters: bfgminer
raphgro: umlgraph, egtk
raveit65: mate-user-share
salimma: xnoise
silas: python-gflags, python-asyncmongo
silfreed: ale
slankes: pympdtouchgui
steve: cone
vicodan: mate-user-share

Orphans (23): ale bfgminer clc-intercal cone dbus-tools dircproxy egtk
fldigi-doc ip6sic isic javasqlite mate-user-share
maven-anno-plugin mojomojo ninja pympdtouchgui python-asyncmongo
python-gflags umlgraph visualvm xnoise zukini zukiwi


Orphans (dependend on) (2): javasqlite python-gflags


Orphans (rawhide) for at least 6 weeks (dependend on) (2): javasqlite
python-gflags


Orphans  (rawhide)(not depended on) (21): ale bfgminer clc-intercal
cone dbus-tools dircproxy egtk fldigi-doc ip6sic isic
mate-user-share maven-anno-plugin mojomojo ninja pympdtouchgui
python-asyncmongo umlgraph visualvm xnoise zukini zukiwi


Orphans (rawhide) for at least 6 weeks (not dependend on) (8):
clc-intercal cone dbus-tools fldigi-doc maven-anno-plugin mojomojo
python-asyncmongo umlgraph


Depending packages (rawhide) (2): starcal weka


Packages depending on packages orphaned (rawhide) for more than 6
weeks (2): starcal weka

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://git.fedorahosted.org/cgit/releng/tree/scripts/find_unblocked_orphans.py
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org

[perl-IO-AIO] Update to 4.32

2015-02-12 Thread Paul Howarth 
commit a723cf7b31b1b70239d0f67f1e9f18b8b00b1f9a
Author: Paul Howarth p...@city-fan.org
Date:   Thu Feb 12 11:12:06 2015 +

Update to 4.32

- New upstream release 4.32
  - Replace off_t by STRLEN where appropriate; should not result in
user-visible changes
  - Update ecb.h for C11 compatibility
- Classify buildreqs by usage
- Use %license where possible

 perl-IO-AIO.spec |   36 +++-
 sources  |2 +-
 2 files changed, 32 insertions(+), 6 deletions(-)
---
diff --git a/perl-IO-AIO.spec b/perl-IO-AIO.spec
index eaac1a0..c785c36 100644
--- a/perl-IO-AIO.spec
+++ b/perl-IO-AIO.spec
@@ -1,5 +1,5 @@
 # work around upstream versioning being decimal rather than v-string
-%global upstream_version 4.31
+%global upstream_version 4.32
 %global extraversion %{nil}
 %if %{upstream_version}%{extraversion} != %{upstream_version}
 Provides:  perl(IO::AIO) = %{upstream_version}%{extraversion}
@@ -7,20 +7,33 @@ Provides: perl(IO::AIO) = 
%{upstream_version}%{extraversion}
 
 Name:  perl-IO-AIO
 Version:   %{upstream_version}%{extraversion}
-Release:   3%{?dist}
+Release:   1%{?dist}
 Summary:   Asynchronous Input/Output
 License:   GPL+ or Artistic
 Group: Development/Libraries
 URL:   http://search.cpan.org/dist/IO-AIO/
 Source0:   
http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/IO-AIO-%{upstream_version}.tar.gz
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+# Module Build
 BuildRequires: perl = 3:5.8.2
+BuildRequires: perl(Config)
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Module Runtime
 BuildRequires: perl(base)
 BuildRequires: perl(Carp)
 BuildRequires: perl(common::sense)
 BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker)
 BuildRequires: perl(XSLoader)
+# Test Suite
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(lib)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test)
+BuildRequires: perl(vars)
+# Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 Requires:  perl(XSLoader)
 
@@ -54,12 +67,25 @@ make test
 rm -rf %{buildroot}
 
 %files
-%doc Changes COPYING README
+%if 0%{?_licensedir:1}
+%license COPYING
+%else
+%doc COPYING
+%endif
+%doc Changes README
 %{perl_vendorarch}/auto/IO/
 %{perl_vendorarch}/IO/
-%{_mandir}/man3/IO::AIO.3pm*
+%{_mandir}/man3/IO::AIO.3*
 
 %changelog
+* Thu Feb 12 2015 Paul Howarth p...@city-fan.org - 4.32-1
+- Update to 4.32
+  - Replace off_t by STRLEN where appropriate; should not result in
+user-visible changes
+  - Update ecb.h for C11 compatibility
+- Classify buildreqs by usage
+- Use %%license where possible
+
 * Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 4.31-3
 - Perl 5.20 rebuild
 
diff --git a/sources b/sources
index 45a9581..26d8cb9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-de33075400968c2c23a861d05f92a979  IO-AIO-4.31.tar.gz
+9577f5be9d2ecf3980607462106df149  IO-AIO-4.32.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

Re: Firefox addon signing

2015-02-12 Thread drago01 
On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos
comzer...@fedoraproject.org wrote:
 On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth m...@cchtml.com
 wrote:

 I'm sure those that need to know, know, but for those that haven't heard[1]
 Mozilla's official Firefox build will enforce addons to contain a Mozilla
 signature without any runtime option to disable the check. Initially this
 prevents Fedora packaged addons since they are unsigned. The Mozilla signing
 process takes time and can't be part of a package building process. Is
 Fedora going to get authorization to build Firefox with a runtime disable
 option?


 If the only way is to completely disable this feature, I'd prefer we don't.
 I wouldn't like for us to ship a less secure build of Firefox.

A better way would be to add a Fedora Signature in addition to
mozilla's and use that for packaged extensions.
But that would require work on the build system (koji) side.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-IO-AIO] Created tag perl-IO-AIO-4.32-1.fc23

2015-02-12 Thread Paul Howarth 
The lightweight tag 'perl-IO-AIO-4.32-1.fc23' was created pointing to:

 a723cf7... Update to 4.32
--
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-IO-AIO/f22] Update to 4.32

2015-02-12 Thread Paul Howarth 
Summary of changes:

  a723cf7... Update to 4.32 (*)

(*) 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-IO-AIO] Created tag perl-IO-AIO-4.32-1.fc22

2015-02-12 Thread Paul Howarth 
The lightweight tag 'perl-IO-AIO-4.32-1.fc22' was created pointing to:

 a723cf7... Update to 4.32
--
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-Wx-Perl-DataWalker/f22] Run X11 tests using xvfb-run

2015-02-12 Thread Jitka Plesnikova 
commit b11122d3686c8c28ba21a46bd9c9baa3ba25acd6
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 13:07:31 2015 +0100

Run X11 tests using xvfb-run

(cherry picked from commit 039e0987bda366244807a972944ebe9c2fc8b8dd)

 perl-Wx-Perl-DataWalker.spec |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)
---
diff --git a/perl-Wx-Perl-DataWalker.spec b/perl-Wx-Perl-DataWalker.spec
index 11cc8b8..a45456a 100644
--- a/perl-Wx-Perl-DataWalker.spec
+++ b/perl-Wx-Perl-DataWalker.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Wx-Perl-DataWalker
 Version:0.02
-Release:18%{?dist}
+Release:19%{?dist}
 Summary:Implement subclass that shows relatively simple structure
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -44,8 +44,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 
 %check
 %if %{use_x11_tests}
-xinit /bin/sh -c 'rm -f ok; make test  touch ok' -- /usr/bin/Xvfb :666
-test -e ok
+xvfb-run -a make test
 %endif
 
 %files
@@ -54,6 +53,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 12 2015 Jitka Plesnikova jples...@redhat.com - 0.02-19
+- Run X11 tests using xvfb-run (BZ#1179570)
+
 * Thu Sep 04 2014 Jitka Plesnikova jples...@redhat.com - 0.02-18
 - Perl 5.20 rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Error/f22] Update to 0.17023

2015-02-12 Thread Paul Howarth 
Summary of changes:

  f8d3bc3... Update to 0.17023 (*)

(*) 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

Re: Orphaned Packages in rawhide (2015-02-10)

2015-02-12 Thread Kevin Kofler 
Richard W.M. Jones wrote:
 I did a test build of SDL without the audiofile + arts + esound
 dependencies (arts + esound also seem to need audiofile), and it
 builds fine, so that is one route out of this.

Audiofile is bound to stay, and SDL should remain built against it, as 
removing it would disable some features that some applications/games using 
SDL need.

Feel free, however, to build SDL without aRts and esound support. The only 
reason aRts is still in Fedora at all is for things that support ONLY aRts 
for sound output (in particular, the knotify in kdelibs3 and the kdelibs3 
game taxipilot). There is nothing using aRts as its native sound server 
anymore, and there hasn't been since Fedora 9 (!). What will happen if you 
try to use aRts output is that an instance of aRts will be spawned, talking 
to ALSA, and terminated once the aRts-using application exits. In the 
default setup, that means you're running aRts on top of PulseAudio through 
the ALSA PulseAudio plugin, not a very interesting setup. (Better use 
PulseAudio directly.) And using aRts INSTEAD of PulseAudio is clearly not 
something we can or should support anymore, as most applications no longer 
support aRts, if they ever did. Esound support is similarly obsolete, it is 
only emulated by PulseAudio (we haven't been shipping the real ESD for a 
long time, I think since Fedora 8 (!)), so it is better to use native 
PulseAudio output.

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: Bootstrapping build-time circular dependent packages

2015-02-12 Thread Itamar Reis Peixoto 
On Thu, Feb 12, 2015 at 6:43 PM, Vladimir Stackov amigo.el...@gmail.com wrote:
 Say we have two packages:

 Name: a
 Requires: b

drop this one and build A, then build b, and rebuild A adding the
dependencie back
--- BuildRequires: b


 and

 Name: b
 Requires: a
 BuildRequires: a



-- 


Itamar Reis Peixoto
-- 
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 Error-0.17023.tar.gz uploaded to lookaside cache by pghmcfc

2015-02-12 Thread Paul Howarth 
A file has been added to the lookaside cache for perl-Error:

98524ffbd268013e00697a5826a83d37  Error-0.17023.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-Error] Update to 0.17023

2015-02-12 Thread Paul Howarth 
commit f8d3bc3500590dce9c9493582ef08082a14497d9
Author: Paul Howarth p...@city-fan.org
Date:   Thu Feb 12 20:35:41 2015 +

Update to 0.17023

- New upstream release 0.17023
  - Minimal version of Module-Build reduced to 0.280801 (CPAN RT#102062)
- Use %license where possible

 perl-Error.spec |   24 +---
 sources |2 +-
 2 files changed, 18 insertions(+), 8 deletions(-)
---
diff --git a/perl-Error.spec b/perl-Error.spec
index c98409e..e5d3f17 100644
--- a/perl-Error.spec
+++ b/perl-Error.spec
@@ -1,7 +1,7 @@
 Name:   perl-Error
 Epoch:  1
-Version:0.17022
-Release:4%{?dist}
+Version:0.17023
+Release:1%{?dist}
 Summary:Error/exception handling in an OO-ish way
 License:(GPL+ or Artistic) and MIT
 Group:  Development/Libraries
@@ -43,12 +43,12 @@ can simply be recorded.
 %setup -q -n Error-%{version}
 
 %build
-perl Build.PL installdirs=vendor
+perl Build.PL --installdirs=vendor
 ./Build
 
 %install
 rm -rf $RPM_BUILD_ROOT
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+./Build install --destdir=$RPM_BUILD_ROOT --create_packlist=0
 %{_fixperms} $RPM_BUILD_ROOT
 
 %check
@@ -58,15 +58,25 @@ rm -rf $RPM_BUILD_ROOT
 rm -rf $RPM_BUILD_ROOT
 
 %files
+%if 0%{?_licensedir:1}
+%license LICENSE
+%else
+%doc LICENSE
+%endif
 # GPL+ or Artistic
-%doc ChangeLog README LICENSE examples/
+%doc ChangeLog README examples/
 %{perl_vendorlib}/Error.pm
-%{_mandir}/man3/Error.3pm*
+%{_mandir}/man3/Error.3*
 # MIT
 %{perl_vendorlib}/Error/
-%{_mandir}/man3/Error::Simple.3pm*
+%{_mandir}/man3/Error::Simple.3*
 
 %changelog
+* Thu Feb 12 2015 Paul Howarth p...@city-fan.org - 1:0.17023-1
+- Update to 0.17023
+  - Minimal version of Module-Build reduced to 0.280801 (CPAN RT#102062)
+- Use %%license where possible
+
 * Mon Sep 08 2014 Jitka Plesnikova jples...@redhat.com - 1:0.17022-4
 - Perl 5.20 re-rebuild of bootstrapped packages
 
diff --git a/sources b/sources
index 3ab25d2..b60758f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f4d825f4be915ae90bf2e0d66734956b  Error-0.17022.tar.gz
+98524ffbd268013e00697a5826a83d37  Error-0.17023.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

Re: Firefox addon signing

2015-02-12 Thread Kevin Kofler 
Nikos Roussos wrote:
 If the only way is to completely disable this feature, I'd prefer we
 don't.
 I wouldn't like for us to ship a less secure build of Firefox.

After Restricted Boot, now Restricted Browser? No thanks! This feature 
needs to be disabled no matter whether it affects our packaged plugins or 
not.

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

[perl-Error] Created tag perl-Error-0.17023-1.fc23

2015-02-12 Thread Paul Howarth 
The lightweight tag 'perl-Error-0.17023-1.fc23' was created pointing to:

 f8d3bc3... Update to 0.17023
--
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-Error] Created tag perl-Error-0.17023-1.fc22

2015-02-12 Thread Paul Howarth 
The lightweight tag 'perl-Error-0.17023-1.fc22' was created pointing to:

 f8d3bc3... Update to 0.17023
--
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

Bootstrapping build-time circular dependent packages

2015-02-12 Thread Vladimir Stackov 
Say we have two packages:

Name: a
Requires: b
BuildRequires: b

and

Name: b
Requires: a
BuildRequires: a

I can bootstrap them by building and installing manually before
rpmbuild but how should I do that with koji?
Thanks for any advices!

-- 
Kind regards,
Vladimir.
-- 
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: [Proposal] Ring-based Packaging Policies

2015-02-12 Thread Björn Persson 
Stephen Gallagher wrote:
* The package *MAY* contain bundled libraries or other projects, but if
it does so, it *MUST* contain a Provides: bundled(pkg) = version for
each such bundling. This is done so that we can use the meta-data to
identify which packages may be vulnerable in the event of a security
issue.

Before (and if) this becomes policy, it must be defined exactly what
pkg shall be. In some cases it's obvious. In other cases a name
exists in multiple variants. If we end up with one package bundling
gpg, another gnupg and a third gpg2, then the policy hasn't
fulfilled its purpose of making it easy to find all packages that
bundle a particular piece of software.

Shall it be the name of the RPM package in Fedora? Or the source RPM
package? But what if there isn't a Fedora package of the bundled
software? Shall it be the name of the upstream source tarball? Some
projects don't even release tarballs. The soname? That works only for
compiled libraries. The project name on Sourceforge/Github/Savannah/...?
The domain name of its website? But one project can distribute multiple
packages, and some projects use multiple websites and nothing enforces
that the name is the same everywhere. Could the name of the root
directory of its source code tree be used? Some source packages
(especially those that are packaged in zip files instead of tarballs)
contain multiple files and directories without a common root directory.

-- 
Björn Persson


pgp6ongLGAOLp.pgp
Description: OpenPGP digital signatur
-- 
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: [Proposal] Ring-based Packaging Policies

2015-02-12 Thread Zbigniew Jędrzejewski-Szmek 
On Thu, Feb 12, 2015 at 01:32:04PM -0500, Stephen Gallagher wrote:
 (Logistical note: please keep all replies to this thread on
 devel@lists.fedoraproject.org)
 
 tl;dr Shall we consider requiring a lesser package review for packages
 that are not present on Product or Spin install media?
Despite the title, and the tl;dr summary, what you are proposing boils
down to a blanket exception on bundling. This is both not enough and
dangerous. I agree that we could relax the rules in some places, where
the effort of conforming to Guidelines is just too big for the real
gain. But I think the way this is done should be much more subtle,
based on an analysis of individual tradeoffs.

In your proposal the ring of the package is the important thing. But
the dependency tree is a very well connected graph, and various fringe
packages are used by core packages, so there's no way to develop
anything using just the core, and any real-life server is also going
to include packages from all rings. Security bugs in fringe
web-facing services are more important than bugs in core tools
which are purely local. For example, recent XSS vulnerability in
jquery [1] nicely cuts through all rings. Unbundling jquery here would
give a huge benefit, and does not become less important the farther a
package is from the core.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1166041

 == Premise ==
 
 So, some time ago, we started talking about dividing up the Fedora
 package set into a series of rings. One of the driving purposes behind
 this idea was to re-evaluate our policies for packaging in each of these
 rings. A fair amount of time has passed and no formal discussions have
 taken place (that I have seen, at any rate), so I'm going to provide
 here a simple starter proposal that we can work from and see where it
 leads.
 
 To begin, I'll try to identify some of the major advantages and
 disadvantages in our current policies. (In no particular order...)
 
 === Advantages ===
 * Consistency: every shared library, language-specific module and
 application should have packaging consistent with others in its
 category. This makes it easier for comaintainers and provenpackagers to
 pick it up and work on it.
 
 * The no-bundled-libraries policy means that when a library module
 requires an update, it means that only one package needs to be modified
 in order to enhance all applications on the system that consumes it.
 This is a significant time-saver when it comes to dealing with
 (increasingly common) security vulnerabilities.
 
 * Package review front-loads the task of educating the packagers. It
 guarantees that packages enter the collection by meeting a very high
 standard. This does a great deal to accomplish the consistency
 mentioned above.
 
 * Legal review and the FPCA ensures that Fedora remains true to its
 Freedom Foundation (as well as protecting Fedora contributors from the
 perils of the international legal system).
 
 === Disadvantages ===
 * Very strict policies often leads to potential packagers giving up.
True. But packagers often give up for many other reasons, including
unresolved legal problems with the software, many different packaging
problems other than bundling, lack of sponsors, etc.

 * Package reviews for less-interestingackages (such as those for less
 popular SIGs) often remain un-reviewed for weeks, months or even years.
 
 * The package policies are only ever reviewed during the initial
 creation of the package. Once that initial (high) hurdle is cleared, the
 packager essentially has free reign to do whatever they want with their
 package. This sometimes means that as time passes, the spec files
 bit-rot or otherwise start accumulating other inconsistencies. (A
 common example is the package whose upstream starts bundling a library
 without the packager noticing).
Your proposal would only worsen, not fix that.

 * Many upstream projects do not concern themselves with being in any
 particular distribution (with the notable example being the
 Debian/Ubuntu flavors which have amassed a sufficient apparent userbase
 that they sometimes get special treatment). For a variety of reasons,
 this often leads directly to bundling the vast majority of their
 dependencies. This is done for many reasons, but the two most common are
 supportability and portability; it's impossible for many upstreams to
 actually QA their package with every possible distro library. Instead,
 if they ship everything they depend on, they can guarantee *that*
 specific combination. This moves the responsibility from the
 distribution to the upstream package to maintain their bundled
 libraries.
I think this responsibility is an illusion. Most upstreams only care
that the bundled versions allow their package to continue to work, and
are not at all capable of fixing vulnerabilities or even other bugs.

I think that it is also very unlikely that packages would be properly
reviewed when they move to an inner ring. Look at how well the merge

[perl] Fix regressions with GCC 5.0

2015-02-12 Thread Petr Pisar 
commit 59e25a21638574fd097336f46de7a6b88696d2b7
Author: Petr Písař ppi...@redhat.com
Date:   Thu Feb 12 09:37:39 2015 +0100

Fix regressions with GCC 5.0

Upstream proposed different fix for the Errno by modifying global CPP
flags. I think this an overkill preventing people from using the new
GCC features. So I roll in now the fix local to the Errno module for
now.

 20.1-Fix-Errno.pm-generation-for-gcc-5.0.patch |   80 
 ...t-handling-of-hex-constants-for-the-pream.patch |   47 
 perl.spec  |   15 -
 3 files changed, 141 insertions(+), 1 deletions(-)
---
diff --git a/perl-5.20.1-Fix-Errno.pm-generation-for-gcc-5.0.patch 
b/perl-5.20.1-Fix-Errno.pm-generation-for-gcc-5.0.patch
new file mode 100644
index 000..c800bf8
--- /dev/null
+++ b/perl-5.20.1-Fix-Errno.pm-generation-for-gcc-5.0.patch
@@ -0,0 +1,80 @@
+From 93d77ec43f0de26bc9ead97d204a680a902d59e1 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Wed, 11 Feb 2015 15:46:37 +0100
+Subject: [PATCH] Fix Errno.pm generation for gcc-5.0
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+gcc-5.0 -E interleaves now line numbers with expended macros, so that
+the generated errno.c will be preprocessed to
+
+EBFONT = [[
+   59
+]]
+
+which is hard to parse in in line-based reader.
+
+So use -P option with gcc = 5.0. Global -P usage would break makedepend,
+global -ftrack-macro-expansion=0 would break lib/h2ph.t.
+
+RT#123784
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ ext/Errno/Errno_pm.PL | 23 +--
+ 1 file changed, 17 insertions(+), 6 deletions(-)
+
+diff --git a/ext/Errno/Errno_pm.PL b/ext/Errno/Errno_pm.PL
+index 55ad01a..63b5916 100644
+--- a/ext/Errno/Errno_pm.PL
 b/ext/Errno/Errno_pm.PL
+@@ -2,7 +2,7 @@ use ExtUtils::MakeMaker;
+ use Config;
+ use strict;
+ 
+-our $VERSION = 1.20_03;
++our $VERSION = 1.20_04;
+ 
+ my %err = ();
+ 
+@@ -225,20 +225,31 @@ sub write_errno_pm {
+ { # BeOS (support now removed) did not enter this block
+ # invoke CPP and read the output
+ 
++  my $inhibit_linemarkers = '';
++  if ($Config{gccversion} =~ /\A(\d+)\./ and $1 = 5) {
++  # GCC 5.0 interleaves expanded macros with line numbers breaking
++  # each line into multiple lines. RT#123784
++  $inhibit_linemarkers = ' -P';
++  }
++
+   if ($^O eq 'VMS') {
+-  my $cpp = $Config{cppstdin} $Config{cppflags} $Config{cppminus};
++  my $cpp = $Config{cppstdin} $Config{cppflags} .
++  $inhibit_linemarkers .  $Config{cppminus};
+   $cpp =~ s/sys\$input//i;
+   open(CPPO,$cpp  errno.c |) or
+   die Cannot exec $Config{cppstdin};
+   } elsif ($IsMSWin32 || $^O eq 'NetWare') {
+-  open(CPPO,$Config{cpprun} $Config{cppflags} errno.c |) or
+-  die Cannot run '$Config{cpprun} $Config{cppflags} errno.c';
++  my $cpp = $Config{cpprun} $Config{cppflags} .
++  $inhibit_linemarkers;
++  open(CPPO,$cpp errno.c |) or
++  die Cannot run '$cpp errno.c';
+   } elsif ($IsSymbian) {
+-my $cpp = gcc -E -I$ENV{SDK}\\epoc32\\include\\libc -;
++my $cpp = gcc -E -I$ENV{SDK}\\epoc32\\include\\libc .
++  $inhibit_linemarkers . -;
+   open(CPPO,$cpp  errno.c |)
+   or die Cannot exec $cpp;
+ } else {
+-  my $cpp = default_cpp();
++  my $cpp = default_cpp() . $inhibit_linemarkers;
+   open(CPPO,$cpp  errno.c |)
+   or die Cannot exec $cpp;
+   }
+-- 
+1.9.3
+
diff --git 
a/perl-5.21.8-h2ph-correct-handling-of-hex-constants-for-the-pream.patch 
b/perl-5.21.8-h2ph-correct-handling-of-hex-constants-for-the-pream.patch
new file mode 100644
index 000..00cda19
--- /dev/null
+++ b/perl-5.21.8-h2ph-correct-handling-of-hex-constants-for-the-pream.patch
@@ -0,0 +1,47 @@
+From 6b8383472e2f75b4bbbfe8d80f036c8a3ee6b439 Mon Sep 17 00:00:00 2001
+From: Tony Cook t...@develop-help.com
+Date: Thu, 12 Feb 2015 14:10:36 +1100
+Subject: [PATCH 2/2] h2ph: correct handling of hex constants for the preamble
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ utils/h2ph.PL | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/utils/h2ph.PL b/utils/h2ph.PL
+index 9a8b14d..c46d423 100644
+--- a/utils/h2ph.PL
 b/utils/h2ph.PL
+@@ -769,7 +769,7 @@ sub inc_dirs
+ sub build_preamble_if_necessary
+ {
+ # Increment $VERSION every time this function is modified:
+-my $VERSION = 3;
++my $VERSION = 4;
+ my $preamble= $Dest_dir/_h2ph_pre.ph;
+ 
+ # Can we skip building the preamble file?
+@@ -788,6 +788,8 @@ sub build_preamble_if_necessary
+ 
+ open  PREAMBLE,

Re: resultsdb roadmap

2015-02-12 Thread Kamil Paral 
 Hi,
 
 I've already tried to ask on #fedora-qa, but I think the mailing list is
 the better medium to discuss this. Thanks to jskladen for answering.
 
 We've been looking into Taskotron and Resultsdb for a while and would
 like to deploy an instance running RPMGrill[1] and become contributors.
 
 I assume, running rpmgrill in Taskotron could mean, that each rpmgrill
 test result translates to an entry in Resultsdb as an outcome (PASSED,
 FAILED). 

If you are interested, we support more outcome keywords, like INFO or 
NEEDS_INSPECTION:
https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/library.html#module-libtaskotron.check

 Yet the question for the developer as to why it failed is
 important.
 
 I have mainly three main questions around Taskatron and specifically
 Resultsdb:
 
 1. Ed Santiago is currently running RPMGrill here:
 
 http://rpmgrill-fc20.edsantiago.com:5000/recent
 
   which in terms of presenting results to the user provides a different
   experience. The results are grouped by test and provide more insight
   as to why a test failed. Test results in Resultsdb currently seem to
   have only one outcome and technical details are left on the build
   master.
 
   How does a representation like RPMGrill translate into Resultsdb? Are
   there plans/ideas on how to provide a more diversified result
   representation in Resultsdb (e.g. error reason, hint on how to solve
   an error).

At the moment, each result contains a link to the task log, which you can 
inspect, e.g.:
https://taskotron.fedoraproject.org/resultsdb/results?job_id=45746
points to
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/36226/steps/runtask/logs/stdio

That log contains both taskotron execution info and above statements and task 
output. If you know an undocumented trick, you can also strip down the path a 
bit arrive to the buildbot job info page:
https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/36226/
and there you have access to taskotron.log, which contains full debug info, 
which we use for debugging libtaskotron issues. This is usually not needed by 
package maintainers, so we don't advertise this too much yet.

I agree it would be great if taskotron could execute rpmgrill, and then upload 
the results to your special application and nicely display them. Or 
alternatively generate the html report locally. Unfortunately we don't have a 
support for storing and displaying artifacts (e.g. a html page) at the moment 
-- but we plan to do it in the future.

If you want to have something working right now, I see several ways to go:

1. You could print out a text representation of the rpmgrill results into the 
log. You could also post the results into your web applications, and then 
include a hyperlink in the log in order to point people to a better 
visualization.

2. I guess we could change the Log → hyperlink in resultsdb to point to your 
web application directly, rather than into our buildbot log. However, I see two 
concerns with that, one is that accessing the task log itself would be 
non-trivial, and second that displaying any results at all would be relying on 
your web app availability. If it went down, nobody could see any results at all.

In the future, generating the html result locally and then showing it from 
resultsdb interface is probably the way to go.

 
 2. Are there plans/ideas about implementing a (fulltext-) search over
   results?

I'll let others to respond to this, I have no idea.

 
 3. Are there plans/ideas on implementing a waiver mechanism?

We will definitely need this, for most of the checks. But we haven't started 
yet designing that feature, so it won't be available any time soon.


BTW, I talked to Miroslav Vadkerti on DevConf about rpmgrill. We should meet up 
again in the following weeks and try to cook some actionable plan for rpmgrill 
in Taskotron.

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

Re: resultsdb roadmap

2015-02-12 Thread Tim Flink 
On Mon, 9 Feb 2015 15:48:45 +1000
Róman Joost rjo...@redhat.com wrote:

 Hi,
 
 I've already tried to ask on #fedora-qa, but I think the mailing list
 is the better medium to discuss this. Thanks to jskladen for
 answering.
 
 We've been looking into Taskotron and Resultsdb for a while and would
 like to deploy an instance running RPMGrill[1] and become
 contributors.
 
 I assume, running rpmgrill in Taskotron could mean, that each rpmgrill
 test result translates to an entry in Resultsdb as an outcome (PASSED,
 FAILED). Yet the question for the developer as to why it failed is
 important.

I don't think that desire is unique to rpmgrill and something that we
decided to leave out of the initial Taskotron system.

My initial thought is that that a discrete state (PASS, FAIL,
NEEDS_INSPECTION etc.) a one-line-or-so summary and link to output
from rpmgrill would work well. Are there other things that you'd like
to see in terms of output?

 I have mainly three main questions around Taskatron and specifically
 Resultsdb:
 
 1. Ed Santiago is currently running RPMGrill here:
 
 http://rpmgrill-fc20.edsantiago.com:5000/recent
 
   which in terms of presenting results to the user provides a
 different experience. The results are grouped by test and provide
 more insight as to why a test failed. Test results in Resultsdb
 currently seem to have only one outcome and technical details are
 left on the build master.

This was less of a desired final outcome for us than it was the easiest
way to get started.

I think that our current method of having gigantic text-only log files
is far from optimal (and something that we did years ago in AutoQA
before making the logs more easily accessible) but we haven't improved
the log accessibility/readability in taskotron yet.

   How does a representation like RPMGrill translate into Resultsdb?
 Are there plans/ideas on how to provide a more diversified result
   representation in Resultsdb (e.g. error reason, hint on how to solve
   an error).

I think that having rpmgrill output static html would likely be the
best approach here unless you're planning to continue supporting the
webapp that you linked to (and from previous conversations, I'm under
the impression that was never intended to be a long-term thing).

 2. Are there plans/ideas about implementing a (fulltext-) search over
   results?

Nothing written down, no but that's been on my wishlist since before
Taskotron really got started. Unless there's more demand for the
fulltext indexing than I think there is, we'd probably start with
something less complicated like indexing the summary statements.

I'm open to other ideas, though. Just concerned about what fulltext
indexing of all logs might entail.

 3. Are there plans/ideas on implementing a waiver mechanism?

Yeah, it'll have to happen before we start gating any
rawhide/branched/stable builds or updates for Fedora. We don't have a
design yet but it'll happen at some point.


 [1] - https://git.fedorahosted.org/git/rpmgrill.git
 
 PS: Yes - I'm aware that there is already a bitbucket repository of
 rpmgrill for Taskotron, but have only had a quick glimpse at it.

Someone was planning to work on getting rpmgrill working in taskotron
and that bitbucket repo was meant to hold the task that's executed in
taskotron.

From our end, that is being tracked as:

https://phab.qadevel.cloud.fedoraproject.org/T281

Let us know if you have any other questions or concerns.

Tim
 Thanks and Kind Regards,



pgp1gn8KbhsVb.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Fedora 22 Mass Branching

2015-02-12 Thread Peter Robinson 
h Hi All,

 Fedora 22 has been branched, please be sure to do a git pull --rebase to
 pick up the new branch, as an additional reminder rawhide/f23 has had
 inheritance cut off from previous releases,  so this means that
 anything you do for f22 you also have to do in the master branch and do
 a build there. This is the same as we did for previous Fedora releases


 Is the koji rawhide repo not pointing to the new F23 builds/repo somehow?
 My otf2-1.5.1-1.fc23 build doesn't appear to be showing up.

 http://koji.fedoraproject.org/koji/taskinfo?taskID=8902498

It's pointed to f-23 just fine
http://koji.fedoraproject.org/koji/buildtargetinfo?name=rawhide
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl/f22] Fix regressions with GCC 5.0

2015-02-12 Thread Petr Pisar 
Summary of changes:

  59e25a2... Fix regressions with GCC 5.0 (*)

(*) 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

Re: rawhide report: 20150212 changes

2015-02-12 Thread Orion Poplawski 

On 02/12/2015 07:54 AM, Fedora Rawhide Report wrote:

Compose started at Thu Feb 12 10:59:03 UTC 2015



xorg-x11-server-1.17.1-1.fc22


Shouldn't we be seeing fc23 builds now in rawhide?

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.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: rawhide report: 20150212 changes

2015-02-12 Thread Parag Nemade 
On Fri, Feb 13, 2015 at 9:09 AM, Orion Poplawski or...@cora.nwra.com wrote:
 On 02/12/2015 07:54 AM, Fedora Rawhide Report wrote:

 Compose started at Thu Feb 12 10:59:03 UTC 2015


 xorg-x11-server-1.17.1-1.fc22


 Shouldn't we be seeing fc23 builds now in rawhide?

I too can't see my fc23 builds in this rawhide report.

Regards,
Parag.
-- 
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 1183576] perl-Filter-1.54 is available

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1183576

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

   What|Removed |Added

   Fixed In Version|perl-Filter-1.54-1.fc21 |perl-Filter-1.54-1.fc20



--- Comment #5 from Fedora Update System upda...@fedoraproject.org ---
perl-Filter-1.54-1.fc20 has been pushed to the Fedora 20 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=8GtyVwmkDna=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 1183576] perl-Filter-1.54 is available

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1183576

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

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Filter-1.54-1.fc22 |perl-Filter-1.54-1.fc21
 Resolution|--- |ERRATA
Last Closed||2015-02-12 21:22:52



--- Comment #4 from Fedora Update System upda...@fedoraproject.org ---
perl-Filter-1.54-1.fc21 has been pushed to the Fedora 21 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=aps3aupBaxa=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

Re: Bootstrapping build-time circular dependent packages

2015-02-12 Thread Orion Poplawski 

On 02/12/2015 01:43 PM, Vladimir Stackov wrote:

Say we have two packages:

Name: a
Requires: b
BuildRequires: b

and

Name: b
Requires: a
BuildRequires: a

I can bootstrap them by building and installing manually before
rpmbuild but how should I do that with koji?
Thanks for any advices!



See also: http://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.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: Fedora 22 Mass Branching

2015-02-12 Thread Orion Poplawski 

On 02/12/2015 02:40 AM, Peter Robinson wrote:

h Hi All,


Fedora 22 has been branched, please be sure to do a git pull --rebase to
pick up the new branch, as an additional reminder rawhide/f23 has had
inheritance cut off from previous releases,  so this means that
anything you do for f22 you also have to do in the master branch and do
a build there. This is the same as we did for previous Fedora releases



Is the koji rawhide repo not pointing to the new F23 builds/repo somehow?
My otf2-1.5.1-1.fc23 build doesn't appear to be showing up.

http://koji.fedoraproject.org/koji/taskinfo?taskID=8902498


It's pointed to f-23 just fine
http://koji.fedoraproject.org/koji/buildtargetinfo?name=rawhide



Yeah, that looks good.  But I don't see fc23 builds showing up in:

http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/

but I do see it in:

http://kojipkgs.fedoraproject.org/repos/f23-build/latest/x86_64/

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.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

sorting yum/dnf metadata and metadata diffs

2015-02-12 Thread Casey Jao 
How feasible would it be to keep the listings in primary.xml and
filelists.xml sorted by package name and arch? Doing so could open the door
to simple and efficient diffs of repository metadata.

I recently ran some quick tests using python and elementtree. While the F21
primary.xml files from 2/7 and 2/9 both weigh around 2.6M compressed and
~18M uncompressed, sorting them and running a simple line-by-line
comparison revealed a diff of ~500K, which compressed down to ~70K. A
similar procedure on the 8M filelists.xml yielded a diff which compressed
to ~200K.

Those two are by far the largest metadata files. If the observed
improvements are typical, then keeping those files in order and hosting the
diffs between the present and the previous few days (and modifying dnf to
look for those diffs) could substantially reduce the amount of data that
users must download every time a repository is updated, which for a
fast-moving OS like Fedora could happen nearly every day.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-File-ShareDir-PAR/f22] Specify all dependencies; Modernize spec file

2015-02-12 Thread Jitka Plesnikova 
commit 16d5c9bdbd6c43f14d1883db2d5c64d0e0ff1e75
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 14:51:25 2015 +0100

Specify all dependencies; Modernize spec file

 perl-File-ShareDir-PAR.spec |   50 +-
 1 files changed, 30 insertions(+), 20 deletions(-)
---
diff --git a/perl-File-ShareDir-PAR.spec b/perl-File-ShareDir-PAR.spec
index 3262f5b..9607719 100644
--- a/perl-File-ShareDir-PAR.spec
+++ b/perl-File-ShareDir-PAR.spec
@@ -1,26 +1,35 @@
 Name:   perl-File-ShareDir-PAR
 Version:0.06
-Release:14%{?dist}
+Release:15%{?dist}
 Summary:File::ShareDir with PAR support
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/File-ShareDir-PAR/
 Source0:
http://www.cpan.org/authors/id/S/SM/SMUELLER/File-ShareDir-PAR-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
+BuildRequires:  perl(inc::Module::Install)
+# Run-time
+BuildRequires:  perl(base)
+BuildRequires:  perl(Carp)
 BuildRequires:  perl(Class::Inspector) = 1.12
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Config)
+BuildRequires:  perl(constant)
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::ShareDir) = 1.02
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(PAR) = 0.989
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+BuildRequires:  perl(warnings)
+# Test
+BuildRequires:  perl(Cwd)
+BuildRequires:  perl(PAR::Dist)
 BuildRequires:  perl(Test::More) = 0.47
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 Requires:   perl(File::ShareDir) = 1.02
 Requires:   perl(PAR) = 0.989
 
-# RPM 4.8 style:
-%filter_from_requires /perl(File::ShareDir)$/d
-%filter_setup
-# RPM 4.9 style
 %global __requires_exclude 
%{?__requires_exclude:__requires_exclude|}perl\\(File::ShareDir\\)$
 
 %description
@@ -29,36 +38,37 @@ tries hard to be compatible with PAR packaged applications.
 
 %prep
 %setup -q -n File-ShareDir-PAR-%{version}
+rm -r inc
+sed -i -e '/^inc\// d' MANIFEST
+find -type f -exec chmod -x {} +
 
 %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 -depth -type d -exec rmdir {} 2/dev/null \;
-rm -rf $RPM_BUILD_ROOT/blib/lib/auto/share/dist/File-ShareDir-PAR/
-rm -rf 
$RPM_BUILD_ROOT/blib/lib/auto/share/module/File-ShareDir-PAR/test_file.txt
+rm -rf $RPM_BUILD_ROOT/%{perl_vendorlib}/auto/share/dist/File-ShareDir-PAR
+rm -rf 
$RPM_BUILD_ROOT/%{perl_vendorlib}/auto/share/module/File-ShareDir-PAR/test_file.txt
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
 make test
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
 %files
-%defattr(-,root,root,-)
-%doc Changes LICENSE
+%license LICENSE
+%doc Changes
 %{perl_vendorlib}/File/ShareDir
 %{perl_vendorlib}/auto/share/*/File-ShareDir-PAR
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 12 2015 Jitka Plesnikova jples...@redhat.com - 0.06-15
+- Specify all dependencies (BZ#1190828) 
+- Modernize spec file
+
 * Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.06-14
 - Perl 5.20 rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1190828] perl-File-ShareDir-PAR-0.06-14.fc22 FTBFS: Dependency on PAR::Dist not declared

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1190828

Jitka Plesnikova jples...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-File-ShareDir-PAR-0.06
   ||-15.fc23



-- 
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=esVEO2Xm7ya=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-Wx] Rebuild for new GCC 5.0 C++ ABI signature (bug #1190971)

2015-02-12 Thread Petr Pisar 
commit f6eea2f719126ae1451b62223dda4d9ee5bb3762
Author: Petr Písař ppi...@redhat.com
Date:   Thu Feb 12 15:08:07 2015 +0100

Rebuild for new GCC 5.0 C++ ABI signature (bug #1190971)

 perl-Wx.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Wx.spec b/perl-Wx.spec
index 99d93c3..bcdabdc 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -12,7 +12,7 @@
 
 Name:   perl-Wx
 Version:0.9923
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Interface to the wxWidgets cross-platform GUI toolkit
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -719,6 +719,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
 %{_mandir}/man3/*.3pm*
 
 %changelog
+* Thu Feb 12 2015 Petr Pisar ppi...@redhat.com - 0.9923-2
+- Rebuild for new GCC 5.0 C++ ABI signature (bug #1190971)
+
 * Wed Feb  4 2015 Tom Callaway s...@fedoraproject.org - 0.9923-1
 - update to 0.9923
 - comment out pass_through option to Getopt-Long (not valid with )
--
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 1189459] perl-Debug-Client-0.29-3.fc22 FTBFS: Dead-lock in mock environment

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189459



--- Comment #4 from Petr Pisar ppi...@redhat.com ---
There still something fishy with the perl debuger: It does not emit DB1
prompt if the debugger is run from the t/07-initialize.t test. If the debugger
is run from another session, it emits the DB1. That explains why the
debugger does not process the c command. But I don't know why the behaviour
differs.

-- 
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=Up3Mk71hmua=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 1189459] perl-Debug-Client-0.29-3.fc22 FTBFS: Dead-lock in mock environment

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189459



--- Comment #5 from Petr Pisar ppi...@redhat.com ---
Please note upstream moved from Padre track to
https://github.com/PadreIDE/Debug-Client.

-- 
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=XoS0F2HwhDa=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 1190828] perl-File-ShareDir-PAR-0.06-14.fc22 FTBFS: Dependency on PAR::Dist not declared

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1190828



--- Comment #1 from Fedora Update System upda...@fedoraproject.org ---
perl-File-ShareDir-PAR-0.06-14.fc21 has been submitted as an update for Fedora
21.
https://admin.fedoraproject.org/updates/perl-File-ShareDir-PAR-0.06-14.fc21

-- 
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=iTgzjUvLkma=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 1189459] perl-Debug-Client-0.29-3.fc22 FTBFS: Dead-lock in mock environment

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189459

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

   What|Removed |Added

URL|http://koji.fedoraproject.o |https://github.com/PadreIDE
   |rg/koji/taskinfo?taskID=879 |/Debug-Client/issues/1
   |3846|



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

Re: Firefox addon signing

2015-02-12 Thread Miloslav Trmač 
 On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
  A better way would be to add a Fedora Signature in addition to
  mozilla's and use that for packaged extensions.
  But that would require work on the build system (koji) side.
 
 The RPMs deploying the packaged extension are already signed and those
 signatures are checked at time of package install. So it seems like
 firefox merely needs to be taught that the pre-packaged extensions
 deployed by RPM are pre-verified, so it can skip its verification
 for those, while still doing verification for stuff that is live
 downloaded

Yes, that does seem like the most practical way and reasonably secure way to 
handle this; it might make Mozilla unhappy anyway.

Firefox is really doing this to fight malware that has probably actually 
received (possibly unintended) permission from the user to install itself into 
the system, which often includes getting Administrator rights.  So, to mirror 
that Mozilla intent exactly, even RPM-deployed extensions should require a 
Mozilla signature.

OTOH, once you give malware root rights, it can in principle modify Firefox to 
skip the check, so this is only a hurdle, not a reliable feature.  Equally, 
verifying the RPM extension contents against the RPM database and checking the 
RPM signature would be useless because the malware can just add its key to the 
keys RPM uses for verification.

The Mozilla blog also mentions some “third option” for “extensions that will 
never be publicly distributed and will never leave an internal network”, 
presumably bypassing the need to have them signed by Mozilla.  Could that be 
used by Fedora?
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-File-ShareDir-PAR/f21] Specify all dependencies; Modernize spec file

2015-02-12 Thread Jitka Plesnikova 
commit df3f921891ead1994733ae89522e2ddfe4d8f0c7
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 14:51:25 2015 +0100

Specify all dependencies; Modernize spec file

 perl-File-ShareDir-PAR.spec |   50 +-
 1 files changed, 30 insertions(+), 20 deletions(-)
---
diff --git a/perl-File-ShareDir-PAR.spec b/perl-File-ShareDir-PAR.spec
index d17909f..406bd40 100644
--- a/perl-File-ShareDir-PAR.spec
+++ b/perl-File-ShareDir-PAR.spec
@@ -1,26 +1,35 @@
 Name:   perl-File-ShareDir-PAR
 Version:0.06
-Release:13%{?dist}
+Release:14%{?dist}
 Summary:File::ShareDir with PAR support
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/File-ShareDir-PAR/
 Source0:
http://www.cpan.org/authors/id/S/SM/SMUELLER/File-ShareDir-PAR-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
+BuildRequires:  perl(inc::Module::Install)
+# Run-time
+BuildRequires:  perl(base)
+BuildRequires:  perl(Carp)
 BuildRequires:  perl(Class::Inspector) = 1.12
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Config)
+BuildRequires:  perl(constant)
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::ShareDir) = 1.02
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(PAR) = 0.989
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+BuildRequires:  perl(warnings)
+# Test
+BuildRequires:  perl(Cwd)
+BuildRequires:  perl(PAR::Dist)
 BuildRequires:  perl(Test::More) = 0.47
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 Requires:   perl(File::ShareDir) = 1.02
 Requires:   perl(PAR) = 0.989
 
-# RPM 4.8 style:
-%filter_from_requires /perl(File::ShareDir)$/d
-%filter_setup
-# RPM 4.9 style
 %global __requires_exclude 
%{?__requires_exclude:__requires_exclude|}perl\\(File::ShareDir\\)$
 
 %description
@@ -29,36 +38,37 @@ tries hard to be compatible with PAR packaged applications.
 
 %prep
 %setup -q -n File-ShareDir-PAR-%{version}
+rm -r inc
+sed -i -e '/^inc\// d' MANIFEST
+find -type f -exec chmod -x {} +
 
 %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 -depth -type d -exec rmdir {} 2/dev/null \;
-rm -rf $RPM_BUILD_ROOT/blib/lib/auto/share/dist/File-ShareDir-PAR/
-rm -rf 
$RPM_BUILD_ROOT/blib/lib/auto/share/module/File-ShareDir-PAR/test_file.txt
+rm -rf $RPM_BUILD_ROOT/%{perl_vendorlib}/auto/share/dist/File-ShareDir-PAR
+rm -rf 
$RPM_BUILD_ROOT/%{perl_vendorlib}/auto/share/module/File-ShareDir-PAR/test_file.txt
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
 make test
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
 %files
-%defattr(-,root,root,-)
-%doc Changes LICENSE
+%license LICENSE
+%doc Changes
 %{perl_vendorlib}/File/ShareDir
 %{perl_vendorlib}/auto/share/*/File-ShareDir-PAR
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 12 2015 Jitka Plesnikova jples...@redhat.com - 0.06-14
+- Specify all dependencies (BZ#1190828) 
+- Modernize spec file
+
 * Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.06-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Firefox addon signing

2015-02-12 Thread Daniel P. Berrange 
On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
 On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos
 comzer...@fedoraproject.org wrote:
  On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth m...@cchtml.com
  wrote:
 
  I'm sure those that need to know, know, but for those that haven't heard[1]
  Mozilla's official Firefox build will enforce addons to contain a Mozilla
  signature without any runtime option to disable the check. Initially this
  prevents Fedora packaged addons since they are unsigned. The Mozilla signing
  process takes time and can't be part of a package building process. Is
  Fedora going to get authorization to build Firefox with a runtime disable
  option?
 
 
  If the only way is to completely disable this feature, I'd prefer we don't.
  I wouldn't like for us to ship a less secure build of Firefox.
 
 A better way would be to add a Fedora Signature in addition to
 mozilla's and use that for packaged extensions.
 But that would require work on the build system (koji) side.

The RPMs deploying the packaged extension are already signed and those
signatures are checked at time of package install. So it seems like
firefox merely needs to be taught that the pre-packaged extensions
deployed by RPM are pre-verified, so it can skip its verification
for those, while still doing verification for stuff that is live
downloaded

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Firefox addon signing

2015-02-12 Thread drago01 
On Thu, Feb 12, 2015 at 1:53 PM, Daniel P. Berrange berra...@redhat.com wrote:
 On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
 On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos
 comzer...@fedoraproject.org wrote:
  On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth m...@cchtml.com
  wrote:
 
  I'm sure those that need to know, know, but for those that haven't heard[1]
  Mozilla's official Firefox build will enforce addons to contain a Mozilla
  signature without any runtime option to disable the check. Initially this
  prevents Fedora packaged addons since they are unsigned. The Mozilla 
  signing
  process takes time and can't be part of a package building process. Is
  Fedora going to get authorization to build Firefox with a runtime disable
  option?
 
 
  If the only way is to completely disable this feature, I'd prefer we don't.
  I wouldn't like for us to ship a less secure build of Firefox.

 A better way would be to add a Fedora Signature in addition to
 mozilla's and use that for packaged extensions.
 But that would require work on the build system (koji) side.

 The RPMs deploying the packaged extension are already signed and those
 signatures are checked at time of package install. So it seems like
 firefox merely needs to be taught that the pre-packaged extensions
 deployed by RPM are pre-verified, so it can skip its verification
 for those, while still doing verification for stuff that is live
 downloaded

Oh indeed. It is probably sufficient to just check the signature of
non system wide extensions.
-- 
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 1189459] perl-Debug-Client-0.29-3.fc22 FTBFS: Dead-lock in mock environment

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189459



--- Comment #3 from Petr Pisar ppi...@redhat.com ---
Actualy the c command is flushed, but it's emitted before perl debugger is
ready to process input. Either the debugger should buffer the input, or the
Debug::Client should wait for debugger prompt. At the end, it's a race.

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

Re: Firefox addon signing

2015-02-12 Thread Florian Weimer 
On 02/12/2015 11:15 AM, Nikos Roussos wrote:
 On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth m...@cchtml.com
 wrote:
 Is Fedora going to get authorization to build Firefox with a runtime
 disable option?
 
 If the only way is to completely disable this feature, I'd prefer we don't.
 I wouldn't like for us to ship a less secure build of Firefox.

It's not the only way, you can also patch the Firefox binary on disk to
disable the check.  You can even run a copy in case you cannot modify
the original version due to file system permissions.

This is why I don't see how this can be a security improvement, at least
not on Fedora.  If it really cannot be disabled, it will also cause
problems for centrally managed Firefox deployments which need to
pre-install add-ons into user profiles.

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

[perl-File-ShareDir-PAR] Specify all dependencies; Modernize spec file

2015-02-12 Thread Jitka Plesnikova 
commit af1832198804fd4daf36c075433291d52f6eca4e
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 14:51:25 2015 +0100

Specify all dependencies; Modernize spec file

 perl-File-ShareDir-PAR.spec |   50 +-
 1 files changed, 30 insertions(+), 20 deletions(-)
---
diff --git a/perl-File-ShareDir-PAR.spec b/perl-File-ShareDir-PAR.spec
index 3262f5b..9607719 100644
--- a/perl-File-ShareDir-PAR.spec
+++ b/perl-File-ShareDir-PAR.spec
@@ -1,26 +1,35 @@
 Name:   perl-File-ShareDir-PAR
 Version:0.06
-Release:14%{?dist}
+Release:15%{?dist}
 Summary:File::ShareDir with PAR support
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/File-ShareDir-PAR/
 Source0:
http://www.cpan.org/authors/id/S/SM/SMUELLER/File-ShareDir-PAR-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
+BuildRequires:  perl(inc::Module::Install)
+# Run-time
+BuildRequires:  perl(base)
+BuildRequires:  perl(Carp)
 BuildRequires:  perl(Class::Inspector) = 1.12
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Config)
+BuildRequires:  perl(constant)
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::ShareDir) = 1.02
+BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(PAR) = 0.989
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+BuildRequires:  perl(warnings)
+# Test
+BuildRequires:  perl(Cwd)
+BuildRequires:  perl(PAR::Dist)
 BuildRequires:  perl(Test::More) = 0.47
-Requires:   perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
 Requires:   perl(File::ShareDir) = 1.02
 Requires:   perl(PAR) = 0.989
 
-# RPM 4.8 style:
-%filter_from_requires /perl(File::ShareDir)$/d
-%filter_setup
-# RPM 4.9 style
 %global __requires_exclude 
%{?__requires_exclude:__requires_exclude|}perl\\(File::ShareDir\\)$
 
 %description
@@ -29,36 +38,37 @@ tries hard to be compatible with PAR packaged applications.
 
 %prep
 %setup -q -n File-ShareDir-PAR-%{version}
+rm -r inc
+sed -i -e '/^inc\// d' MANIFEST
+find -type f -exec chmod -x {} +
 
 %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 -depth -type d -exec rmdir {} 2/dev/null \;
-rm -rf $RPM_BUILD_ROOT/blib/lib/auto/share/dist/File-ShareDir-PAR/
-rm -rf 
$RPM_BUILD_ROOT/blib/lib/auto/share/module/File-ShareDir-PAR/test_file.txt
+rm -rf $RPM_BUILD_ROOT/%{perl_vendorlib}/auto/share/dist/File-ShareDir-PAR
+rm -rf 
$RPM_BUILD_ROOT/%{perl_vendorlib}/auto/share/module/File-ShareDir-PAR/test_file.txt
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
 make test
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
 %files
-%defattr(-,root,root,-)
-%doc Changes LICENSE
+%license LICENSE
+%doc Changes
 %{perl_vendorlib}/File/ShareDir
 %{perl_vendorlib}/auto/share/*/File-ShareDir-PAR
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 12 2015 Jitka Plesnikova jples...@redhat.com - 0.06-15
+- Specify all dependencies (BZ#1190828) 
+- Modernize spec file
+
 * Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.06-14
 - Perl 5.20 rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1179570] perl-Wx-Perl-DataWalker-0.02-18.fc22 FTBFS: race in X server location

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1179570

Jitka Plesnikova jples...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Wx-Perl-DataWalker-0.0
   ||2-19.fc23
 Resolution|--- |RAWHIDE
Last Closed||2015-02-12 07:32:33



-- 
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=HOR3hMk3Fga=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 1189459] perl-Debug-Client-0.29-3.fc22 FTBFS: Dead-lock in mock environment

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189459



--- Comment #2 from Petr Pisar ppi...@redhat.com ---
It halts in the $debug-run on reading response from perl debugger.

The Debug::Client::run() sends c command to the debugger and waits for a
response. But no response comes because the c command is not flushed from
buffers to the TCP socket.

This is caused by Term-ReadLine-Gnu commit:

r481 | hayashi | 2015-01-31 13:07:49 +0100 (So, 31 led 2015) | 2 lines
make handling of iostreams simple (make _rl_store_iostream() return void and
remove _rl_fetch_iostream()) [rt.cpan.org #101078]

-- 
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=W5kFUgK8fTa=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-App-a2p/f22] Add a2p.y and regenerate a2p.c (BZ#1177672)

2015-02-12 Thread Jitka Plesnikova 
commit 9fd4f4354b8ee291c459bae1ef609c8a1f64b325
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 16:43:36 2015 +0100

Add a2p.y and regenerate a2p.c (BZ#1177672)

 App-a2p-1.007-a2p-y.patch |  436 +
 perl-App-a2p.spec |   17 ++-
 2 files changed, 451 insertions(+), 2 deletions(-)
---
diff --git a/App-a2p-1.007-a2p-y.patch b/App-a2p-1.007-a2p-y.patch
new file mode 100644
index 000..d355fba
--- /dev/null
+++ b/App-a2p-1.007-a2p-y.patch
@@ -0,0 +1,436 @@
+diff -Naur App-a2p-1.007.orig/a2p.y App-a2p-1.007.yacc/a2p.y
+--- App-a2p-1.007.orig/a2p.y   1970-01-01 01:00:00.0 +0100
 App-a2p-1.007.yacc/a2p.y   2015-01-03 08:06:54.249838926 +0100
+@@ -0,0 +1,432 @@
++%{
++/* $RCSfile: a2p.y,v $$Revision: 4.1 $$Date: 92/08/07 18:29:12 $
++ *
++ *Copyright (C) 1991, 1992, 1993, 1994, 1996, 1997, 1999, 2000,
++ *by Larry Wall and others
++ *
++ *You may distribute under the terms of either the GNU General Public
++ *License or the Artistic License, as specified in the README file.
++ *
++ * $Log:  a2p.y,v $
++ */
++
++#include INTERN.h
++#include a2p.h
++
++int root;
++int begins = Nullop;
++int ends = Nullop;
++
++%}
++%token BEGIN END
++%token REGEX
++%token SEMINEW NEWLINE COMMENT
++%token FUN1 FUNN GRGR
++%token PRINT PRINTF SPRINTF_OLD SPRINTF_NEW SPLIT
++%token IF ELSE WHILE FOR IN
++%token EXIT NEXT BREAK CONTINUE RET
++%token GETLINE DO SUB GSUB MATCH
++%token FUNCTION USERFUN DELETE
++
++%right ASGNOP
++%right '?' ':'
++%left OROR
++%left ANDAND
++%left IN
++%left NUMBER VAR SUBSTR INDEX
++%left MATCHOP
++%left RELOP '' ''
++%left OR
++%left STRING
++%left '+' '-'
++%left '*' '/' '%'
++%right UMINUS
++%left NOT
++%right '^'
++%left INCR DECR
++%left FIELD VFIELD SVFIELD
++
++%%
++
++program   : junk hunks
++  { root = oper4(OPROG,$1,begins,$2,ends); }
++  ;
++
++begin : BEGIN '{' maybe states '}' junk
++  { begins = oper4(OJUNK,begins,$3,$4,$6); in_begin = FALSE;
++  $$ = Nullop; }
++  ;
++
++end   : END '{' maybe states '}'
++  { ends = oper3(OJUNK,ends,$3,$4); $$ = Nullop; }
++  | end NEWLINE
++  { $$ = $1; }
++  ;
++
++hunks : hunks hunk junk
++  { $$ = oper3(OHUNKS,$1,$2,$3); }
++  | /* NULL */
++  { $$ = Nullop; }
++  ;
++
++hunk  : patpat
++  { $$ = oper1(OHUNK,$1); need_entire = TRUE; }
++  | patpat '{' maybe states '}'
++  { $$ = oper2(OHUNK,$1,oper2(OJUNK,$3,$4)); }
++  | FUNCTION USERFUN '(' arg_list ')' maybe '{' maybe states '}'
++  { fixfargs($2,$4,0); $$ = oper5(OUSERDEF,$2,$4,$6,$8,$9); }
++  | '{' maybe states '}'
++  { $$ = oper2(OHUNK,Nullop,oper2(OJUNK,$2,$3)); }
++  | begin
++  | end
++  ;
++
++arg_list: expr_list
++  { $$ = rememberargs($$); }
++  ;
++
++patpat: cond
++  { $$ = oper1(OPAT,$1); }
++  | cond ',' cond
++  { $$ = oper2(ORANGE,$1,$3); }
++  ;
++
++cond  : expr
++  | match
++  | rel
++  | compound_cond
++  | cond '?' expr ':' expr
++  { $$ = oper3(OCOND,$1,$3,$5); }
++  ;
++
++compound_cond
++  : '(' compound_cond ')'
++  { $$ = oper1(OCPAREN,$2); }
++  | cond ANDAND maybe cond
++  { $$ = oper3(OCANDAND,$1,$3,$4); }
++  | cond OROR maybe cond
++  { $$ = oper3(OCOROR,$1,$3,$4); }
++  | NOT cond
++  { $$ = oper1(OCNOT,$2); }
++  ;
++
++rel   : expr RELOP expr
++  { $$ = oper3(ORELOP,$2,$1,$3); }
++  | expr '' expr
++  { $$ = oper3(ORELOP,string(,1),$1,$3); }
++  | expr '' expr
++  { $$ = oper3(ORELOP,string(,1),$1,$3); }
++  | '(' rel ')'
++  { $$ = oper1(ORPAREN,$2); }
++  ;
++
++match : expr MATCHOP expr
++  { $$ = oper3(OMATCHOP,$2,$1,$3); }
++  | expr MATCHOP REGEX
++  { $$ = oper3(OMATCHOP,$2,$1,oper1(OREGEX,$3)); }
++  | REGEX %prec MATCHOP
++  { $$ = oper1(OREGEX,$1); }
++  | '(' match ')'
++  { $$ = oper1(OMPAREN,$2); }
++  ;
++
++expr  : term
++  { $$ = $1; }
++  | expr term
++  { $$ = oper2(OCONCAT,$1,$2); }
++  | expr '?' expr ':' expr
++  { $$ = oper3(OCOND,$1,$3,$5); }
++  | variable ASGNOP cond
++  {
++  $$ = oper3(OASSIGN,$2,$1,$3);
++  if ((ops[$1].ival  255) == OFLD)
++  lval_field = TRUE;
++  else if ((ops[$1].ival  255) == OVFLD)
++  lval_field = TRUE;
++  }
++  ;
++
++sprintf   : SPRINTF_NEW
++  | SPRINTF_OLD ;
++
++term  : variable
++  { $$ = $1; }
++  | NUMBER
++  { $$ = oper1(ONUM,$1); }
++  | STRING
++  { $$ = oper1(OSTR,$1); }
++  | term '+' term
++  { $$

Re: Koji build failure: noarch vs. arch?

2015-02-12 Thread gil 


Il 12/02/2015 16:50, Jerry James ha scritto:

Eek, sorry, got busy and forgot about this...

On Fri, Jan 30, 2015 at 10:49 AM, Kevin Fenzi ke...@scrye.com wrote:

I'm really not sure, but a scratch build here works fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=8784062

Is there any changes to your local koji client config?

as i wrote in my e-mail titled jni libraries fails in koji
i have the same problem
i haven't done any changes in koji client config
contains
[koji]

;configuration for koji cli tool

;url of XMLRPC server
server = http://koji.fedoraproject.org/kojihub

;url of web interface
weburl = http://koji.fedoraproject.org/koji

;url of package download site
topurl = https://kojipkgs.fedoraproject.org/

;path to the koji top directory
;topdir = /mnt/koji

;configuration for Kerberos authentication

;the service name of the principal being used by the hub
;krbservice = host

;configuration for SSL authentication

;client certificate
cert = ~/.fedora.cert

;certificate of the CA that issued the client certificate
ca = ~/.fedora-server-ca.cert

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert

As far as I can remember, the only change I have made is to add
anon_retry = yes.  This is what /etc/koji.conf currently contains:

[koji]

;configuration for koji cli tool

;url of XMLRPC server
server = http://koji.fedoraproject.org/kojihub

;url of web interface
weburl = http://koji.fedoraproject.org/koji

;url of package download site
topurl = https://kojipkgs.fedoraproject.org/

;path to the koji top directory
;topdir = /mnt/koji

;configuration for Kerberos authentication

;the service name of the principal being used by the hub
;krbservice = host

;configuration for SSL authentication

;client certificate
cert = ~/.fedora.cert

;certificate of the CA that issued the client certificate
ca = ~/.fedora-server-ca.cert

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert

anon_retry = yes


You are just doing a 'fedpkg build' ?

Yes.


Would you like me to try and re-run it from here?

No, the package doesn't build properly with gcc 5.0.  I need to figure
out why and fix it before we try another build.

Also, note that somebody else is now seeing this problem (see gil's
message from a few minutes ago), so something definitely needs to be
fixed somewhere.  It would be good to track down the actual source of
the problem.  I'll jump onto gil's thread and comment.


--
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 1189463] perl-Module-Starter-Plugin-CGIApp-0.42-8.fc22 FTBFS: tests fail: Can't create /builddir/build/BUILD/Module-Starter-Plugin-CGIApp-0.42/t/Example-Dist/test-app.t/#!/usr/bin/perl

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189463

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

   What|Removed |Added

External Bug ID||CPAN 101894



-- 
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=6MZNFPJHyOa=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 1179572] perl-XML-Twig-3.48-3.fc22 FTBFS: t/test_3_30.t test fails

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1179572

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

   What|Removed |Added

External Bug ID||CPAN 99098



--- Comment #1 from Petr Pisar ppi...@redhat.com ---
XML-Parser-2.44 reverted the faulty change.

-- 
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=PLp0IqEU1oa=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 1179572] perl-XML-Twig-3.48-3.fc22 FTBFS: t/test_3_30.t test fails

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1179572

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

   What|Removed |Added

External Bug ID||CPAN 101041



-- 
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=rw4AKHy2qva=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 1189459] perl-Debug-Client-0.29-3.fc22 FTBFS: Dead-lock in mock environment

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1189459

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

   What|Removed |Added

External Bug ID||CPAN 101078



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

Re: Firefox addon signing

2015-02-12 Thread Miloslav Trmač 
 or simply exempt signature checking if
 the extension is on disk. They should check on download only.

That would defeat the entire purpose; malware is very commonly sideloading 
extensions.
Mirek
-- 
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 1179572] perl-XML-Twig-3.48-3.fc22 FTBFS: t/test_3_30.t test fails

2015-02-12 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1179572

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

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-XML-Parser-2.44-1.fc22
 Resolution|--- |NEXTRELEASE
Last Closed||2015-02-12 10:20:31



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

jni libraries fails in koji

2015-02-12 Thread gil 

Hi
try to build leveldbjni but is mistakenly seen as a package noarch
any ideas?
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=8909564
--
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: Firefox addon signing

2015-02-12 Thread Florian Weimer 
On 02/12/2015 04:53 PM, Simo Sorce wrote:
 On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
 or simply exempt signature checking if
 the extension is on disk. They should check on download only.

 That would defeat the entire purpose; malware is very commonly sideloading 
 extensions.
 
 Malware can easily binary patch firefox to ignore verification,

Windows has Authenticode, which may change the equation somewhat.

 I do not
 think trying to defeat sideloading with this kind of verification makes
 much sense.

Maybe it is only about preventing people from bundling the official
Firefox version with dodgy add-ons.  Not downright malware, but things
users may not actually want without realizing it.  The signature
checking means that those who prepare the downloads can no longer use
the unmodified upstream binary.  Which in turn might force them not to
use Mozilla brands.

Maybe this is a bit far-fetched, but after hours of staring at other
people's code today, it seems pretty reasonable to me.

But what do add-on developers do?  Surely there is a way to disable this
somehow?

-- 
Florian Weimer / Red Hat Product Security
-- 
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: Firefox addon signing

2015-02-12 Thread Michael Catanzaro 

On Thu, Feb 12, 2015 at 9:53 AM, Simo Sorce s...@redhat.com wrote:
Malware can easily binary patch firefox to ignore verification, I do 
not
think trying to defeat sideloading with this kind of verification 
makes

much sense.


And if you've already installed malware with on your computer, don't 
you kind of have bigger things to worry about than whether or not it 
can be loaded as a Firefox extension?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-App-a2p] Add a2p.y and regenerate a2p.c (BZ#1177672)

2015-02-12 Thread Jitka Plesnikova 
commit 2262696171da82fb6a3898d1758ceb384b7645db
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 16:43:36 2015 +0100

Add a2p.y and regenerate a2p.c (BZ#1177672)

 App-a2p-1.007-a2p-y.patch |  436 +
 perl-App-a2p.spec |   17 ++-
 2 files changed, 451 insertions(+), 2 deletions(-)
---
diff --git a/App-a2p-1.007-a2p-y.patch b/App-a2p-1.007-a2p-y.patch
new file mode 100644
index 000..d355fba
--- /dev/null
+++ b/App-a2p-1.007-a2p-y.patch
@@ -0,0 +1,436 @@
+diff -Naur App-a2p-1.007.orig/a2p.y App-a2p-1.007.yacc/a2p.y
+--- App-a2p-1.007.orig/a2p.y   1970-01-01 01:00:00.0 +0100
 App-a2p-1.007.yacc/a2p.y   2015-01-03 08:06:54.249838926 +0100
+@@ -0,0 +1,432 @@
++%{
++/* $RCSfile: a2p.y,v $$Revision: 4.1 $$Date: 92/08/07 18:29:12 $
++ *
++ *Copyright (C) 1991, 1992, 1993, 1994, 1996, 1997, 1999, 2000,
++ *by Larry Wall and others
++ *
++ *You may distribute under the terms of either the GNU General Public
++ *License or the Artistic License, as specified in the README file.
++ *
++ * $Log:  a2p.y,v $
++ */
++
++#include INTERN.h
++#include a2p.h
++
++int root;
++int begins = Nullop;
++int ends = Nullop;
++
++%}
++%token BEGIN END
++%token REGEX
++%token SEMINEW NEWLINE COMMENT
++%token FUN1 FUNN GRGR
++%token PRINT PRINTF SPRINTF_OLD SPRINTF_NEW SPLIT
++%token IF ELSE WHILE FOR IN
++%token EXIT NEXT BREAK CONTINUE RET
++%token GETLINE DO SUB GSUB MATCH
++%token FUNCTION USERFUN DELETE
++
++%right ASGNOP
++%right '?' ':'
++%left OROR
++%left ANDAND
++%left IN
++%left NUMBER VAR SUBSTR INDEX
++%left MATCHOP
++%left RELOP '' ''
++%left OR
++%left STRING
++%left '+' '-'
++%left '*' '/' '%'
++%right UMINUS
++%left NOT
++%right '^'
++%left INCR DECR
++%left FIELD VFIELD SVFIELD
++
++%%
++
++program   : junk hunks
++  { root = oper4(OPROG,$1,begins,$2,ends); }
++  ;
++
++begin : BEGIN '{' maybe states '}' junk
++  { begins = oper4(OJUNK,begins,$3,$4,$6); in_begin = FALSE;
++  $$ = Nullop; }
++  ;
++
++end   : END '{' maybe states '}'
++  { ends = oper3(OJUNK,ends,$3,$4); $$ = Nullop; }
++  | end NEWLINE
++  { $$ = $1; }
++  ;
++
++hunks : hunks hunk junk
++  { $$ = oper3(OHUNKS,$1,$2,$3); }
++  | /* NULL */
++  { $$ = Nullop; }
++  ;
++
++hunk  : patpat
++  { $$ = oper1(OHUNK,$1); need_entire = TRUE; }
++  | patpat '{' maybe states '}'
++  { $$ = oper2(OHUNK,$1,oper2(OJUNK,$3,$4)); }
++  | FUNCTION USERFUN '(' arg_list ')' maybe '{' maybe states '}'
++  { fixfargs($2,$4,0); $$ = oper5(OUSERDEF,$2,$4,$6,$8,$9); }
++  | '{' maybe states '}'
++  { $$ = oper2(OHUNK,Nullop,oper2(OJUNK,$2,$3)); }
++  | begin
++  | end
++  ;
++
++arg_list: expr_list
++  { $$ = rememberargs($$); }
++  ;
++
++patpat: cond
++  { $$ = oper1(OPAT,$1); }
++  | cond ',' cond
++  { $$ = oper2(ORANGE,$1,$3); }
++  ;
++
++cond  : expr
++  | match
++  | rel
++  | compound_cond
++  | cond '?' expr ':' expr
++  { $$ = oper3(OCOND,$1,$3,$5); }
++  ;
++
++compound_cond
++  : '(' compound_cond ')'
++  { $$ = oper1(OCPAREN,$2); }
++  | cond ANDAND maybe cond
++  { $$ = oper3(OCANDAND,$1,$3,$4); }
++  | cond OROR maybe cond
++  { $$ = oper3(OCOROR,$1,$3,$4); }
++  | NOT cond
++  { $$ = oper1(OCNOT,$2); }
++  ;
++
++rel   : expr RELOP expr
++  { $$ = oper3(ORELOP,$2,$1,$3); }
++  | expr '' expr
++  { $$ = oper3(ORELOP,string(,1),$1,$3); }
++  | expr '' expr
++  { $$ = oper3(ORELOP,string(,1),$1,$3); }
++  | '(' rel ')'
++  { $$ = oper1(ORPAREN,$2); }
++  ;
++
++match : expr MATCHOP expr
++  { $$ = oper3(OMATCHOP,$2,$1,$3); }
++  | expr MATCHOP REGEX
++  { $$ = oper3(OMATCHOP,$2,$1,oper1(OREGEX,$3)); }
++  | REGEX %prec MATCHOP
++  { $$ = oper1(OREGEX,$1); }
++  | '(' match ')'
++  { $$ = oper1(OMPAREN,$2); }
++  ;
++
++expr  : term
++  { $$ = $1; }
++  | expr term
++  { $$ = oper2(OCONCAT,$1,$2); }
++  | expr '?' expr ':' expr
++  { $$ = oper3(OCOND,$1,$3,$5); }
++  | variable ASGNOP cond
++  {
++  $$ = oper3(OASSIGN,$2,$1,$3);
++  if ((ops[$1].ival  255) == OFLD)
++  lval_field = TRUE;
++  else if ((ops[$1].ival  255) == OVFLD)
++  lval_field = TRUE;
++  }
++  ;
++
++sprintf   : SPRINTF_NEW
++  | SPRINTF_OLD ;
++
++term  : variable
++  { $$ = $1; }
++  | NUMBER
++  { $$ = oper1(ONUM,$1); }
++  | STRING
++  { $$ = oper1(OSTR,$1); }
++  | term '+' term
++  { $$

Re: Koji build failure: noarch vs. arch?

2015-02-12 Thread Jerry James 
Eek, sorry, got busy and forgot about this...

On Fri, Jan 30, 2015 at 10:49 AM, Kevin Fenzi ke...@scrye.com wrote:
 I'm really not sure, but a scratch build here works fine:
 https://koji.fedoraproject.org/koji/taskinfo?taskID=8784062

 Is there any changes to your local koji client config?

As far as I can remember, the only change I have made is to add
anon_retry = yes.  This is what /etc/koji.conf currently contains:

[koji]

;configuration for koji cli tool

;url of XMLRPC server
server = http://koji.fedoraproject.org/kojihub

;url of web interface
weburl = http://koji.fedoraproject.org/koji

;url of package download site
topurl = https://kojipkgs.fedoraproject.org/

;path to the koji top directory
;topdir = /mnt/koji

;configuration for Kerberos authentication

;the service name of the principal being used by the hub
;krbservice = host

;configuration for SSL authentication

;client certificate
cert = ~/.fedora.cert

;certificate of the CA that issued the client certificate
ca = ~/.fedora-server-ca.cert

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.fedora-server-ca.cert

anon_retry = yes

 You are just doing a 'fedpkg build' ?

Yes.

 Would you like me to try and re-run it from here?

No, the package doesn't build properly with gcc 5.0.  I need to figure
out why and fix it before we try another build.

Also, note that somebody else is now seeing this problem (see gil's
message from a few minutes ago), so something definitely needs to be
fixed somewhere.  It would be good to track down the actual source of
the problem.  I'll jump onto gil's thread and comment.
-- 
Jerry James
http://www.jamezone.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: jni libraries fails in koji

2015-02-12 Thread Jerry James 
On Thu, Feb 12, 2015 at 8:29 AM, gil punto...@libero.it wrote:
 Hi
 try to build leveldbjni but is mistakenly seen as a package noarch
 any ideas?
 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=8909564

Possibly related to this thread:
https://lists.fedoraproject.org/pipermail/devel/2015-January/207322.html

Also, I just had another instance of this pop up, with an attempt to build csdp:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8909645

Does anybody have any clue as to what is going wrong?
-- 
Jerry James
http://www.jamezone.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: Firefox addon signing

2015-02-12 Thread Simo Sorce 
On Thu, 2015-02-12 at 09:54 -0500, Miloslav Trmač wrote:
  or simply exempt signature checking if
  the extension is on disk. They should check on download only.
 
 That would defeat the entire purpose; malware is very commonly sideloading 
 extensions.

Malware can easily binary patch firefox to ignore verification, I do not
think trying to defeat sideloading with this kind of verification makes
much sense.
Of course you may decide to exempt only extensions in non-user-writable
locations, if you are on Linux and the Firefox binary is read-only for
the user.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: Firefox addon signing

2015-02-12 Thread Alec Leamas 

On 12/02/15 16:53, Simo Sorce wrote:


Malware can easily binary patch firefox to ignore verification, I do not
think trying to defeat sideloading with this kind of verification makes
much sense.
Of course you may decide to exempt only extensions in non-user-writable
locations, if you are on Linux and the Firefox binary is read-only for
the user.


Besides the technical issues, what does upstream permit? Since we havn't 
re-branded firefox, are we free to modify this whatever way we want? I 
can see the argument for upstream to limit such modifications without 
re-branding.


Cheers!

--alec

--
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: Firefox addon signing

2015-02-12 Thread Daniel P. Berrange 
On Thu, Feb 12, 2015 at 09:54:16AM -0500, Miloslav Trmač wrote:
  or simply exempt signature checking if
  the extension is on disk. They should check on download only.
 
 That would defeat the entire purpose; malware is very commonly
 sideloading extensions.

If we only exempt extensions installed by RPM it is reasonable to assume
that our new package review process would have validated there is no
malware present. Our package review process is serving the same kind of
purpose as Mozilla's extension review  signing process.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-App-a2p/f21] Skip test on bootstrap because of non-core Devel::FindPerl

2015-02-12 Thread Jitka Plesnikova 
commit 9583ef9e0c5aa15a635d8972b7ff67a15f816cf0
Author: Petr Písař ppi...@redhat.com
Date:   Thu Jan 8 09:30:16 2015 +0100

Skip test on bootstrap because of non-core Devel::FindPerl

Conflicts:
perl-App-a2p.spec

 perl-App-a2p.spec |   18 +-
 1 files changed, 13 insertions(+), 5 deletions(-)
---
diff --git a/perl-App-a2p.spec b/perl-App-a2p.spec
index 154abec..410f07e 100644
--- a/perl-App-a2p.spec
+++ b/perl-App-a2p.spec
@@ -1,6 +1,6 @@
 Name:   perl-App-a2p
 Version:1.007
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Awk to Perl translator
 License:GPL+ or Artistic
 Group:  Development/Tools
@@ -11,16 +11,19 @@ Source0:
http://www.cpan.org/authors/id/L/LE/LEONT/App-a2p-%{version}.tar
 Patch0: App-a2p-1.007-Remove-alarm-call-from-test.patch
 BuildRequires:  perl
 BuildRequires:  perl(Config)
-BuildRequires:  perl(Devel::FindPerl)
 BuildRequires:  perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Devel::FindPerl is a non-core module
+%if !%{defined perl_bootstrap}
+# Tests:
+BuildRequires:  perl(Devel::FindPerl)
 BuildRequires:  perl(File::Spec::Functions)
 BuildRequires:  perl(File::Temp)
 BuildRequires:  perl(IPC::Open2)
-BuildRequires:  perl(strict)
 BuildRequires:  perl(Test::More) = 0.89
-BuildRequires:  perl(warnings)
+%endif
 Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-
 Conflicts:  perl  4:5.18.2-300
 
 %description
@@ -42,7 +45,9 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f 
{} \;
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
+%if !%{defined perl_bootstrap}
 make test
+%endif
 
 %files
 %doc Changes LICENSE README
@@ -51,6 +56,9 @@ make test
 %{_mandir}/man1/*
 
 %changelog
+* Thu Jan 08 2015 Petr Pisar ppi...@redhat.com - 1.007-3
+- Skip test on bootstrap because of non-core Devel::FindPerl
+
 * Sun Aug 17 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 1.007-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-App-a2p/f21] Add a2p.y and regenerate a2p.c (BZ#1177672)

2015-02-12 Thread Jitka Plesnikova 
commit b3d15115b5f69ab387fa22e78da66b18bd0e4852
Author: Jitka Plesnikova jples...@redhat.com
Date:   Thu Feb 12 16:43:36 2015 +0100

Add a2p.y and regenerate a2p.c (BZ#1177672)

Conflicts:
perl-App-a2p.spec

 App-a2p-1.007-a2p-y.patch |  436 +
 perl-App-a2p.spec |   17 ++-
 2 files changed, 451 insertions(+), 2 deletions(-)
---
diff --git a/App-a2p-1.007-a2p-y.patch b/App-a2p-1.007-a2p-y.patch
new file mode 100644
index 000..d355fba
--- /dev/null
+++ b/App-a2p-1.007-a2p-y.patch
@@ -0,0 +1,436 @@
+diff -Naur App-a2p-1.007.orig/a2p.y App-a2p-1.007.yacc/a2p.y
+--- App-a2p-1.007.orig/a2p.y   1970-01-01 01:00:00.0 +0100
 App-a2p-1.007.yacc/a2p.y   2015-01-03 08:06:54.249838926 +0100
+@@ -0,0 +1,432 @@
++%{
++/* $RCSfile: a2p.y,v $$Revision: 4.1 $$Date: 92/08/07 18:29:12 $
++ *
++ *Copyright (C) 1991, 1992, 1993, 1994, 1996, 1997, 1999, 2000,
++ *by Larry Wall and others
++ *
++ *You may distribute under the terms of either the GNU General Public
++ *License or the Artistic License, as specified in the README file.
++ *
++ * $Log:  a2p.y,v $
++ */
++
++#include INTERN.h
++#include a2p.h
++
++int root;
++int begins = Nullop;
++int ends = Nullop;
++
++%}
++%token BEGIN END
++%token REGEX
++%token SEMINEW NEWLINE COMMENT
++%token FUN1 FUNN GRGR
++%token PRINT PRINTF SPRINTF_OLD SPRINTF_NEW SPLIT
++%token IF ELSE WHILE FOR IN
++%token EXIT NEXT BREAK CONTINUE RET
++%token GETLINE DO SUB GSUB MATCH
++%token FUNCTION USERFUN DELETE
++
++%right ASGNOP
++%right '?' ':'
++%left OROR
++%left ANDAND
++%left IN
++%left NUMBER VAR SUBSTR INDEX
++%left MATCHOP
++%left RELOP '' ''
++%left OR
++%left STRING
++%left '+' '-'
++%left '*' '/' '%'
++%right UMINUS
++%left NOT
++%right '^'
++%left INCR DECR
++%left FIELD VFIELD SVFIELD
++
++%%
++
++program   : junk hunks
++  { root = oper4(OPROG,$1,begins,$2,ends); }
++  ;
++
++begin : BEGIN '{' maybe states '}' junk
++  { begins = oper4(OJUNK,begins,$3,$4,$6); in_begin = FALSE;
++  $$ = Nullop; }
++  ;
++
++end   : END '{' maybe states '}'
++  { ends = oper3(OJUNK,ends,$3,$4); $$ = Nullop; }
++  | end NEWLINE
++  { $$ = $1; }
++  ;
++
++hunks : hunks hunk junk
++  { $$ = oper3(OHUNKS,$1,$2,$3); }
++  | /* NULL */
++  { $$ = Nullop; }
++  ;
++
++hunk  : patpat
++  { $$ = oper1(OHUNK,$1); need_entire = TRUE; }
++  | patpat '{' maybe states '}'
++  { $$ = oper2(OHUNK,$1,oper2(OJUNK,$3,$4)); }
++  | FUNCTION USERFUN '(' arg_list ')' maybe '{' maybe states '}'
++  { fixfargs($2,$4,0); $$ = oper5(OUSERDEF,$2,$4,$6,$8,$9); }
++  | '{' maybe states '}'
++  { $$ = oper2(OHUNK,Nullop,oper2(OJUNK,$2,$3)); }
++  | begin
++  | end
++  ;
++
++arg_list: expr_list
++  { $$ = rememberargs($$); }
++  ;
++
++patpat: cond
++  { $$ = oper1(OPAT,$1); }
++  | cond ',' cond
++  { $$ = oper2(ORANGE,$1,$3); }
++  ;
++
++cond  : expr
++  | match
++  | rel
++  | compound_cond
++  | cond '?' expr ':' expr
++  { $$ = oper3(OCOND,$1,$3,$5); }
++  ;
++
++compound_cond
++  : '(' compound_cond ')'
++  { $$ = oper1(OCPAREN,$2); }
++  | cond ANDAND maybe cond
++  { $$ = oper3(OCANDAND,$1,$3,$4); }
++  | cond OROR maybe cond
++  { $$ = oper3(OCOROR,$1,$3,$4); }
++  | NOT cond
++  { $$ = oper1(OCNOT,$2); }
++  ;
++
++rel   : expr RELOP expr
++  { $$ = oper3(ORELOP,$2,$1,$3); }
++  | expr '' expr
++  { $$ = oper3(ORELOP,string(,1),$1,$3); }
++  | expr '' expr
++  { $$ = oper3(ORELOP,string(,1),$1,$3); }
++  | '(' rel ')'
++  { $$ = oper1(ORPAREN,$2); }
++  ;
++
++match : expr MATCHOP expr
++  { $$ = oper3(OMATCHOP,$2,$1,$3); }
++  | expr MATCHOP REGEX
++  { $$ = oper3(OMATCHOP,$2,$1,oper1(OREGEX,$3)); }
++  | REGEX %prec MATCHOP
++  { $$ = oper1(OREGEX,$1); }
++  | '(' match ')'
++  { $$ = oper1(OMPAREN,$2); }
++  ;
++
++expr  : term
++  { $$ = $1; }
++  | expr term
++  { $$ = oper2(OCONCAT,$1,$2); }
++  | expr '?' expr ':' expr
++  { $$ = oper3(OCOND,$1,$3,$5); }
++  | variable ASGNOP cond
++  {
++  $$ = oper3(OASSIGN,$2,$1,$3);
++  if ((ops[$1].ival  255) == OFLD)
++  lval_field = TRUE;
++  else if ((ops[$1].ival  255) == OVFLD)
++  lval_field = TRUE;
++  }
++  ;
++
++sprintf   : SPRINTF_NEW
++  | SPRINTF_OLD ;
++
++term  : variable
++  { $$ = $1; }
++  | NUMBER
++  { $$ = oper1(ONUM,$1); }
++  | STRING
++  { $$ = oper1(OSTR,$1);