greenisland license change

[Pier Luigi Fiorini]

Hi,

greenisland changed license from 'BSD and LGPLv2.1' to 'LGPLv3 or GPLv2 or
GPLv3'

Coming to a Fedora near you.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

[John Dulaney]

I can take lilypond, linode-cli, jwm, mopac7, and mscore 

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

Re: More prominent link to verification hashes

[Jens Lody]

Am Mon, 22 Feb 2016 09:29:37 -0700
schrieb Kevin Fenzi :

> On Sun, 21 Feb 2016 23:21:58 +0100
> Jens Lody  wrote:
> 
> > This can also be done before clicking the link-button, or the
> > download splash is also shown without javascript. This should not
> > be too hard to implement.  
> 
> https://fedorahosted.org/fedora-websites awaits your ticket. 
> 
> Bonus points for proposed patch also. ;) 
> 
> kevin

I just filed a ticket with a possible (quick) patch:

https://fedorahosted.org/fedora-websites/ticket/377

Jens


pgp4Yd0WhG6VM.pgp
Description: Digitale Signatur von OpenPGP
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 22, 2016 at 07:47:51PM +, Gregory Maxwell wrote:
> On Mon, Feb 22, 2016 at 7:42 PM, Kevin Fenzi  wrote:
> > My point was that you can get the signatures off the key from the
> > keyserver and see if any of them are someone you trust. If not, are
> > they connected to someone you trust (hey, look, web of trust). I think
> > expanding the web of trust on the signatories of the keys would help
> > more than just trying to distribute the key fingerprint "lots of
> > places".
> 
> They key itself should come with signatures. That it doesn't is weird
> and inconvenient. If it came with a single signature by a long lived
> key used for the purpose of authenticating keys, it would go a log
> way.

Some older Fedora signing keys were signed by prominent Fedora persons
(up to F12 or so). If one has been to at least one Fedora key signing
party and has a WOT connection to one of thos persons, using the WOT
is the best ways to verify the keys one downloads from the web. It
would be great if we could resurrect this practice and have one or
more RelEng members and the Fedora Project Leader sign the Fedora PGP
keys and upload their signatures to public keyservers.

Signature chaining (F24 key signed by F23, etc..) would also be helpful.

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

[EPEL-devel] Re: related question / off topic - EPEL Proposal #1: Rechartering

[~Stack~]

On 02/22/2016 09:06 PM, Peter wrote:
> On 19/02/16 15:16, ~Stack~ wrote:
>> Thanks for replying. Makes sense. But what would the harm be to move a
>> package into a separate "retired" repo? Community would know that it
>> isn't maintained and yet the package wouldn't just disappear completely.
>> I guess the difficult question would then be, how long is the package
>> kept till it needs to be pruned? 1yr? 6mo? Still, it would be nice to
>> give the user base the option to pull the packages they need out on a
>> long enough scale that they have time to discover it with new builds.
> 
> My suggestion would be for the life of the point release of the repos
> that's built against.  Since the package is not going to be built
> against newer point releases of RHEL it is less likely to continue to
> work after RHEL moves to a new point release (say from 7.2 to 7.3).  We
> could have an individual "retired" repo for each point release that
> would see the packages built against that release moved there.  We would
> not necessarily need get rid of older retired repos, but just maintain a
> symbolic link to the latest one.
> 
> So for example if package foo was last built against RHEL 7.2 before it
> was retired, we could move it to the repo "epel-retired-7.2" and there
> would be a symbolic link for "epel-retired" that points to
> epel-retired-7.2 until RHEL 7.3 is released.

In my opinion, that is a brilliant idea.

I like it! :-)

~Stack~






signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Joshua J Cogliati]

For what it is worth, not signing the key is bug 1043276:
https://bugzilla.redhat.com/show_bug.cgi?id=1043276

> Date: Mon, 22 Feb 2016 19:47:51 +
> From: Gregory Maxwell 
> Subject: Re: More prominent link to verification hashes
> To: Development discussions related to Fedora
>   
> Message-ID:
>   

[EPEL-devel] Re: related question / off topic - EPEL Proposal #1: Rechartering

[Peter]

On 19/02/16 15:16, ~Stack~ wrote:
> Thanks for replying. Makes sense. But what would the harm be to move a
> package into a separate "retired" repo? Community would know that it
> isn't maintained and yet the package wouldn't just disappear completely.
> I guess the difficult question would then be, how long is the package
> kept till it needs to be pruned? 1yr? 6mo? Still, it would be nice to
> give the user base the option to pull the packages they need out on a
> long enough scale that they have time to discover it with new builds.

My suggestion would be for the life of the point release of the repos
that's built against.  Since the package is not going to be built
against newer point releases of RHEL it is less likely to continue to
work after RHEL moves to a new point release (say from 7.2 to 7.3).  We
could have an individual "retired" repo for each point release that
would see the packages built against that release moved there.  We would
not necessarily need get rid of older retired repos, but just maintain a
symbolic link to the latest one.

So for example if package foo was last built against RHEL 7.2 before it
was retired, we could move it to the repo "epel-retired-7.2" and there
would be a symbolic link for "epel-retired" that points to
epel-retired-7.2 until RHEL 7.3 is released.


Peter
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[Bug 1310412] perl-Module-CoreList-5.20160121 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Module-CoreList-5.20160121-1.fc22 has been pushed to the Fedora 22 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-70f3e0e715

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

[Bug 1310479] perl-MooseX-App-1.34 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-MooseX-App-1.34-1.fc22 has been pushed to the Fedora 22 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-0cdd85b0db

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 351  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-2d8fa2e036   
firebird-2.5.5.26952.0-2.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23f4cb12a2   
php-horde-horde-5.2.9-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-50304d1e1f   
nodejs-0.10.42-4.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bc557a5441   
nghttp2-1.7.1-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-287d763bcd   
GraphicsMagick-1.3.23-4.el7 gdl-0.9.5-3.el7 octave-3.8.2-19.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5748740371   
qt-creator-3.5.1-2.el7 botan-1.10.12-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8c727601c5   
libebml-1.3.3-3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

0install-2.11-1.el7
fluxbox-1.3.6-4.el7
libinput-1.1.8-1.el7
pgadmin3-1.22.1-1.el7
php-nette-2.3.9-1.el7
php-nette-caching-2.3.5-1.el7
php-tracy-2.3.9-1.el7
rebase-helper-0.7.1-1.el7
salt-2015.5.9-4.el7
since-1.1-11.el7
yad-0.34.0-1.el7

Details about builds:



 0install-2.11-1.el7 (FEDORA-EPEL-2016-6e37f92d4b)
 A decentralized cross-distribution software installation system

Update Information:

- Upstream update to 2.11. - Exclude ppc64le and ppc




 fluxbox-1.3.6-4.el7 (FEDORA-EPEL-2016-e8ab4c99f9)
 Window Manager based on Blackbox

Update Information:

Initial import for EPEL7




 libinput-1.1.8-1.el7 (FEDORA-EPEL-2016-7f512b1888)
 Input device library

Update Information:

Upstream update to 1.1.8




 pgadmin3-1.22.1-1.el7 (FEDORA-EPEL-2016-d3d0c76e21)
 Graphical client for PostgreSQL

Update Information:

Update to 1.22.1




 php-nette-2.3.9-1.el7 (FEDORA-EPEL-2016-d9c8a9ad7f)
 Nette Framework

Update Information:

Nette Framework is a popular tool for PHP web development It is designed to be
as usable and as friendly as possible. It focuses on security and performance
and is definitely one of the safest PHP frameworks.  Nette Framework speaks your
language and helps you to easily build better websites. Cache accelerates your
application by storing data, once hardly retrieved, for future use.  To use this
library, you just have to add, in your project:  require_once
'/usr/share/php/Nette/autoload.php';

References:

  [ 1 ] Bug #1277484 - Review Request: php-nette - Nette Framework
https://bugzilla.redhat.com/show_bug.cgi?id=1277484




 php-nette-caching-2.3.5-1.el7 (FEDORA-EPEL-2016-a941e34e24)
 Nette Caching Component

Update Information:

**Released version 2.3.5**   *added NewMemcachedStorage using memcached
extension #38 *CacheMacro: better error message




 php-tracy-2.3.9-1.el7 (FEDORA-EPEL-2016-1f88459bd7)
 Tracy: useful PHP debugger

Update Information:

**Released version 2.3.9**  *bar.js: MouseEvent.buttons is not supported by
Safari #134 *Dumper: support for general object exporter which is called for
every object *Dumper: object exporters are called in order from most

[389-devel] Please Review: Nunc Stans fix abstraction increment with gcc 6.0

[William Brown]

https://fedorahosted.org/nunc-stans/ticket/46

https://fedorahosted.org/nunc-stans/attachment/ticket/46/0001-Ticket-46-undefined
-reference-to-abstraction-increme.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane



signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[Bug 1306245] perl-Business-CreditCard-0.35 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Business-CreditCard-0.35-1.fc23 has been pushed to the Fedora 23 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1305186] perl-Business-CreditCard-0.34 is available

[bugzilla]

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



--- Comment #14 from Fedora Update System  ---
perl-Business-CreditCard-0.35-1.fc23 has been pushed to the Fedora 23 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1308272] perl-Text-Levenshtein-Damerau-XS: additional builds

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Levenshtein-Damer |perl-Text-Levenshtein-Damer
   |au-XS-3.1-2.fc22|au-XS-3.1-2.fc22
   ||perl-Text-Levenshtein-Damer
   ||au-XS-3.1-2.fc23



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

[Bug 1308272] perl-Text-Levenshtein-Damerau-XS: additional builds

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Text-Levenshtein-Damerau-XS-3.1-2.fc23 has been pushed to the Fedora 23
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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1310917] perl-RPM2-1.2 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=13099978

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

[Bug 1310917] perl-RPM2-1.2 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1129573
  --> https://bugzilla.redhat.com/attachment.cgi?id=1129573=edit
[patch] Update to 1.2 (#1310917)

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

[Bug 1310917] New: perl-RPM2-1.2 is available

[bugzilla]

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

Bug ID: 1310917
   Summary: perl-RPM2-1.2 is available
   Product: Fedora
   Version: rawhide
 Component: perl-RPM2
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, lkund...@v3.sk,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.2
Current version/release in rawhide: 1.0-16.fc24
URL: http://search.cpan.org/dist/RPM2/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

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

[Bug 1305293] perl-Path-Tiny: please update package in epel7, f22, f23 branches

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Path-Tiny-0.076-1.el7 has been pushed to the Fedora EPEL 7 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1305293] perl-Path-Tiny: please update package in epel7, f22, f23 branches

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Path-Tiny-0.076-1.fc23 |perl-Path-Tiny-0.076-1.fc23
   |perl-Path-Tiny-0.076-1.fc22 |perl-Path-Tiny-0.076-1.fc22
   ||perl-Path-Tiny-0.076-1.el7



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

Re: More prominent link to verification hashes

[Stephen John Smoogen]

On 22 February 2016 at 13:00, Ralf Senderek  wrote:
>
>> The Fedora team could get a profile and verify the key(s) through
>> github, the Fedora and Red Hat web sites, the Fedora magazine twitter
>> account, and by having the Fedora team all sign publicly.
>
> Every little helps. The important step would be if the Fedora devs state the
> fingerprints in a visible way that risks their good reputation if the 
> information
> turned out to be incorrect. These statements would then be the foundation of
> trust in what the Fedora 24 key signs.
>

OK and how many people check to see what another person's reputation
is? And how many people have had gotten bad reputations from signing
bad things? It all sounds great on paper, but without actual methods
and regular checks.. it is as useless as a keysigning party where no
one does a full check of the passport and driver's license with the
issueing authority. [We all do the $200.00 background check on
everyone we sign don't we?]


>> Combined with having the key on getfedora.org, it at least provides a
>> measure of protection against our site being compromised. It also has
>> the benefit of, if someone knows of any Fedora devs on Twitter or
>> another service, they can follow the web of social-service trust. This
>> isn't as good as if they had a direct path to the Fedora WoT through
>> normal signatures, but it's much more likely to actually occur.
>
> Yes all of this, please.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei false positives?

[Christopher]

On Mon, Feb 22, 2016 at 4:28 PM, Ralph Bean  wrote:

> Good idea!  Can you open a ticket on the koschei issue tracker about it?
> https://github.com/msimacek/koschei/issues


Done, and thanks: https://github.com/msimacek/koschei/issues/73
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

[Pier Luigi Fiorini]

2016-02-19 19:09 GMT+01:00 Josh Boyer :

[cut]

As a heads up to the greater community, the packages are listed below.
> In the event that we have to go through with the orphaning, please
> review them for packages you may wish to take over as the primary
> point of contact.  Should Christopher respond, we would still
> encourage actively seeking out co-maintainers for all of these
> packages.
>
> Thank you.
>
> josh
>
>
> rpms/hawaii-icon-theme -- Icon themes for Hawaii desktop environment (
> master f23 f22 )
>

As a co-maintainer I can take this and be listed as main contact.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Koschei false positives?

[Ralph Bean]

On Mon, Feb 22, 2016 at 08:59:24PM +, Christopher wrote:
> I occasionally get notifications from Koschei about my packages failing to
> build. When I look (
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13071213), I see a
> python stack trace which looks like it has nothing to do with my package's
> build. Rather, it looks like Koschei itself failed. Usually these problems
> fix themselves on their own without me needing to touch my package(s) at
> all.
> 
> It'd be nice not to get package failure notifications from Koschei when
> Koschei itself is at fault and not my package. I realize this might be hard
> to tell sometimes... but perhaps there's something which can be done here?

Good idea!  Can you open a ticket on the koschei issue tracker about it?
https://github.com/msimacek/koschei/issues


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

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 247  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6828   
chicken-4.9.0.1-4.el6
 229  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 223  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 154  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8148   
optipng-0.7.5-5.el6
 154  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
  84  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb3b95bd2f   
firebird-2.5.5.26952.0-2.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8aee7a9340   
php-horde-horde-5.2.9-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-f61ec30f9f   
poco-1.4.2p1-3.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-791080c274   
nodejs-0.10.42-4.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-eb24bfea0d   
octave-3.4.3-2.el6 gdl-0.9.5-4.el6 GraphicsMagick-1.3.23-4.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-46c6b5e4d4   
botan-1.8.15-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-58b3766907   
libebml-1.2.2-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

libebml-1.2.2-1.el6
php-nette-2.3.9-1.el6
php-nette-caching-2.3.5-1.el6
php-tracy-2.3.9-1.el6
salt-2015.5.9-4.el6

Details about builds:



 libebml-1.2.2-1.el6 (FEDORA-EPEL-2016-58b3766907)
 Extensible Binary Meta Language library

Update Information:

New in 1.2.2 version:  * fix usage of the DEBUG #define (use LIBEBML_DEBUG
instead) * The EbmlCodeVersion variable now resides in the library instead of
being declared static in the header file. * only use the test element to read
once in the loop  Backported fixes for:  * CVE-2015-8789 libebml: Usa-after-free
vulnerability in EblMaster::Read() * CVE-2015-8790 CVE-2015-8791 libebml:
information leaks in two functions

References:

  [ 1 ] Bug #1276337 - CVE-2015-8789 libebml: Usa-after-free vulnerability in 
EblMaster::Read() [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1276337
  [ 2 ] Bug #1303854 - CVE-2015-8791 CVE-2015-8790 libebml: information leaks 
in two functions [epel-6]
https://bugzilla.redhat.com/show_bug.cgi?id=1303854




 php-nette-2.3.9-1.el6 (FEDORA-EPEL-2016-22d9369b13)
 Nette Framework

Update Information:

Nette Framework is a popular tool for PHP web development It is designed to be
as usable and as friendly as possible. It focuses on security and performance
and is definitely one of the safest PHP frameworks.  Nette Framework speaks your
language and helps you to easily build better websites. Cache accelerates your
application by storing data, once hardly retrieved, for future use.  To use this
library, you just have to add, in your project:  require_once
'/usr/share/php/Nette/autoload.php';

References:

  [ 1 ] Bug #1277484 - Review Request: php-nette - Nette Framework
https://bugzilla.redhat.com/show_bug.cgi?id=1277484




 php-nette-caching-2.3.5-1.el6 (FEDORA-EPEL-2016-4b45707f19)
 Nette Caching Component

Update Information:

**Released version 2.3.5**   *added NewMemcachedStorage using memcached
extension #38 *CacheMacro: better error message




 php-tracy-2.3.9-1.el6 (FEDORA-EPEL-2016-86402e2f37)
 Tracy: useful PHP debugger

Update Information:

**Released version 2.3.9**  *bar.js: MouseEvent.buttons is not supported by
Safari #134 *Dumper: support for general object exporter which is called for
every object *Dumper: object exporters are called in order from most
specific to general *Debugger: removes 

Koschei false positives?

[Christopher]

I occasionally get notifications from Koschei about my packages failing to
build. When I look (
http://koji.fedoraproject.org/koji/taskinfo?taskID=13071213), I see a
python stack trace which looks like it has nothing to do with my package's
build. Rather, it looks like Koschei itself failed. Usually these problems
fix themselves on their own without me needing to touch my package(s) at
all.

It'd be nice not to get package failure notifications from Koschei when
Koschei itself is at fault and not my package. I realize this might be hard
to tell sometimes... but perhaps there's something which can be done here?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1304359] perl-Lingua-Stem-Ru-0.02 is available

[bugzilla]

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



--- Comment #13 from Fedora Update System  ---
perl-Lingua-Stem-Ru-0.03-1.fc22 has been pushed to the Fedora 22 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1305186] perl-Business-CreditCard-0.34 is available

[bugzilla]

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



--- Comment #13 from Fedora Update System  ---
perl-Business-CreditCard-0.35-1.fc22 has been pushed to the Fedora 22 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1304913] perl-Lingua-Stem-Ru-0.03 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Lingua-Stem-Ru-0.03-1.fc22 has been pushed to the Fedora 22 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1306245] perl-Business-CreditCard-0.35 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Business-CreditCard-0.35-1.fc22 has been pushed to the Fedora 22 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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1308272] perl-Text-Levenshtein-Damerau-XS: additional builds

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Text-Levenshtein-Damerau-XS-3.1-2.fc22 has been pushed to the Fedora 22
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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1308272] perl-Text-Levenshtein-Damerau-XS: additional builds

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Text-Levenshtein-Damer
   ||au-XS-3.1-2.fc22
 Resolution|--- |ERRATA
Last Closed||2016-02-22 15:49:31



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

Re: Declining package maintenance requests? (Was Re: Large number of packages to be orphaned on Feb 26)

[Jason L Tibbitts III]

> "FAL" == Fabio Alessandro Locati  writes:

FAL> If a person is not able to make a click in 7 days (maybe vacation
FAL> periods could be excluded from the count), why should he be able to
FAL> do so in the following 21 days?

I think that a better question is:

If a maintainer is not able to deal with such things in a reasonable
time, why are they the only maintainer listed for a package?

We used to have a vacation page, but that's kind of weird privacy page.
I always try to let people I trust know when I'm going to be away.
Certainly if you are going to be away so long that you can't address a
comaintainership request in a reasonable time then that's exactly the
situation where you need comaintainers.

We really need to not be in the situation where a package has only one
maintainer.  And we really need to make sure that everyone knows that
provenpackagers are going to be touching your packages and people are
going to try and get involved.  They just are.  If you can't handle that
(and maybe having to do an occasional merge or revert) then you'd better
have something at the top of your spec explaining the situation.

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

Re: Fedora mass rebuild 2016

[Orion Poplawski]

On 02/22/2016 04:55 AM, Marek Polacek wrote:

In the past few days and weeks we did a mass rebuild of Fedora rawhide packages
in mock with GCC 6 (and corresponding libtool) and for those packages that
failed also rebuilt the same package with gcc-5.3.1-2.fc23.x86_64 to quickly
remove from the list packages that fail for non-GCC related reasons.

There were 17741 packages overall (last year we had 16230 packages).  16281
packages built fine, 883 packages failed to build with both gcc-6 and gcc-5
(ignored for this analysis, unlikely to be GCC 6 related).  This left us with
577 packages that had to be analyzed.  That is a lot -- last year we only had
to examine 236 packages.  So that's why it's taken so long.

As usually, there will be a "porting to" document to ease the transition to
the new GCC.  We already have https://gcc.gnu.org/gcc-6/porting_to.html, even
though this document is still somewhat in flux.

The biggest change hands-down this year is the change of the default standard
for g++ from -std=gnu++98 to -std=gnu++14; this has caused considerable churn,
as you might have noticed on this mailing list.  Unfortunately, many packages
weren't prepared to handle C++11.  Changes in libstdc++ often revealed very
poor programming practices.

Before I describe the results in more detail, I'd like to thank Jon Wakely and
Jakub Jelinek for their indispensable help.

Any mistakes, omissions, or mis-categorizations are solely mine.

GCC bugs

The following is a list of bugs we've found so far in the compiler and the
C++ library during the mass rebuild:

3Depict-0.0.18-3.fc24.src.rpm
C++ language linkage issue in cmath and cstdlib
http://gcc.gnu.org/PR69386
fixed upstream and in gcc-6 (not sure which exact release)


I'm still seeing build failures in 3Depict with gcc 6.0.0-0.12.fc24 that 
seem quite similar (though not exactly the same) to the original PR:


In file included from /usr/include/c++/6.0.0/tr1/random:46:0,
 from /usr/include/c++/6.0.0/parallel/random_number.h:36,
 from /usr/include/c++/6.0.0/parallel/partition.h:38,
 from /usr/include/c++/6.0.0/parallel/quicksort.h:36,
 from /usr/include/c++/6.0.0/parallel/sort.h:48,
 from /usr/include/c++/6.0.0/parallel/algo.h:45,
 from /usr/include/c++/6.0.0/parallel/algorithm:37,
 from /usr/include/c++/6.0.0/algorithm:65,
 from ./common/basics.h:65,
 from ./backend/APT/ionhit.h:22,
 from ./backend/filter.h:27,
 from ./backend/plot.h:23,
 from gui/dialogs/rangeEditDialog.h:22,
 from gui/dialogs/rangeEditDialog.cpp:19:
/usr/include/c++/6.0.0/tr1/cmath: In function 'float 
std::tr1::acosh(float)':
/usr/include/c++/6.0.0/tr1/cmath:424:18: error: 'float 
std::tr1::acosh(float)' conflicts with a previous declaration

   acosh(float __x)
  ^
In file included from /usr/include/c++/6.0.0/math.h:36:0,
 from /usr/include/wx-3.0/wx/math.h:18,
 from /usr/include/wx-3.0/wx/gdicmn.h:23,
 from /usr/include/wx-3.0/wx/event.h:20,
 from /usr/include/wx-3.0/wx/wx.h:24,
 from gui/dialogs/rangeEditDialog.h:5,
 from gui/dialogs/rangeEditDialog.cpp:19:
/usr/include/c++/6.0.0/cmath:1224:3: note: previous declaration 
'constexpr float std::acosh(float)'

   acosh(float __x)
   ^

https://koji.fedoraproject.org/koji/taskinfo?taskID=13097401



--
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ralf Senderek]

> The Fedora team could get a profile and verify the key(s) through 
> github, the Fedora and Red Hat web sites, the Fedora magazine twitter 
> account, and by having the Fedora team all sign publicly.

Every little helps. The important step would be if the Fedora devs state the
fingerprints in a visible way that risks their good reputation if the 
information
turned out to be incorrect. These statements would then be the foundation of
trust in what the Fedora 24 key signs.
 
> Combined with having the key on getfedora.org, it at least provides a 
> measure of protection against our site being compromised. It also has 
> the benefit of, if someone knows of any Fedora devs on Twitter or 
> another service, they can follow the web of social-service trust. This 
> isn't as good as if they had a direct path to the Fedora WoT through 
> normal signatures, but it's much more likely to actually occur.

Yes all of this, please.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Gregory Maxwell]

On Mon, Feb 22, 2016 at 7:42 PM, Kevin Fenzi  wrote:
> My point was that you can get the signatures off the key from the
> keyserver and see if any of them are someone you trust. If not, are
> they connected to someone you trust (hey, look, web of trust). I think
> expanding the web of trust on the signatories of the keys would help
> more than just trying to distribute the key fingerprint "lots of
> places".

They key itself should come with signatures. That it doesn't is weird
and inconvenient. If it came with a single signature by a long lived
key used for the purpose of authenticating keys, it would go a log
way.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Gregory Maxwell]

On Mon, Feb 22, 2016 at 6:35 PM, Kevin Fenzi  wrote:
> Well, I agree the instructions could do better, but how would that help
> if the site was compromised? The attackers would write their own
> instructions.
>
> In addition to the verify link, the https://getfedora.org/en/keys/faq/
> needs a good going over.

New users are stateless and little can be done there; at least not
right now when pre-textual security procedures' like Fedora's are
ubiquitous and thus can't be taken as a clear sign of compromise.

Existing users are another matter; "Hey, wasn't the last fedora key
signed by the fedora-keys-key that I already have?? Something smells
fishy here".   Doubly so if fedora included a fedora-downloader that
users use to get new images which automatically checked these things.

> Pointing people to the sks keyservers to download the key would be nice

I don't think there is any utility in pointing people to a keyserver here.

> and asking them to check the signatures for a web of trust link would
> be great, but I am not sure how many people would care to do that or
> have any links there.

It's useful if that even worked for the few who would do it-- so that
in untargeted replacement they could sound alarms. But I wasn't even
suggesting something so broad as WOT: I'm only suggesting that Fedora
should commit to signing every release key with a long lived, offline
stored, key-- or, alternatively, with prior releases release keys.  So
that people who somehow managed to get a faithful fedora keyring at
some point aren't exposed to compromise over and over again in the
future.

> If the site is compromised how would any of that help?

The compromised site could not sign their replacement keys-- they'd
have to just alter or drop the procedure that provides actual
security, and this disruption would catch the attention of some users.
(and better, if an automated mechanism is provided and gains wide
usage.)

> This is already done somewhat... the fedora-repos package has all the
> keys in it from the time it was last updated.

That's good. The last I had seen it didn't include key for future
releases.  If they're there now the instructions could simply tell the
user to skip the key download if they're already on an updated fedora
install.

The limitation there is that this need to have virtually no false
positives, and so the lack of updates to that package as versions go
EOL would still be problematic. "Oh, it didn't work. I guess I'll
blindly pull the keys from the site" would undo the security.

> So, if you have a fedora
> install you can check the key in fedora-repos. However, that still
> doesn't get around the fact that the anchor of trust here is the ca
> certificate system, or I suppose, best case it would be a web of trust
> link back to the gpg key, but the web of trust is not that expansive
> and random users who don't care about gpg likely wouldn't have any
> links into the Fedora web of trust.

"Trust anchor" is too narrow a concept-- If the user has to only
successfully get the real keys once and then will be protected after
if they're successful, that is win in and of itself. It also means
that more effort can be rationally expended on those few times
initialization (e.g. trying the WOT method, checking multiple sources,
etc.).
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Kevin Fenzi]

On Mon, 22 Feb 2016 19:22:24 -
"Ralf Senderek"  wrote:

> > If the site is compromised, most bets are off sadly.   
> 
> Yes, for people who look only in one place, the manipulated web
> server. But that is the reason why the fingerprint has to pop up in
> different places where it is hard to fake. Even if this one user can
> be tricked, others can discover that the site is compromised if the
> fingerprint is independently recorded many times elsewhere.

But how would anyone even know to look there? 
Or if someone told you: "you should check for this key fingerprint on
10 sites before you trust it", an intruder could just spin up 10 random
sites that mention their compromised key. 

I see what you are getting at, but it would only help people heavily
involved in the project any. 

> BTW, pointing to a key server is not the way to convince anyone. A
> key server is a convenient way to get keys, not a tool to assure
> their authenticity. So I don't think that there is much of an
> alternative other than someone stepping in and provide some
> first-hand knowledge about the key. --

My point was that you can get the signatures off the key from the
keyserver and see if any of them are someone you trust. If not, are
they connected to someone you trust (hey, look, web of trust). I think
expanding the web of trust on the signatories of the keys would help
more than just trying to distribute the key fingerprint "lots of
places".

kevin



pgplXMUYBTWV9.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ryan S. Brown]

On 02/22/2016 02:22 PM, Ralf Senderek wrote:



If the site is compromised, most bets are off sadly.


Yes, for people who look only in one place, the manipulated web server.
But that is the reason why the fingerprint has to pop up in different places
where it is hard to fake. Even if this one user can be tricked, others can
discover that the site is compromised if the fingerprint is independently 
recorded
many times elsewhere.

BTW, pointing to a key server is not the way to convince anyone. A key server
is a convenient way to get keys, not a tool to assure their authenticity.
So I don't think that there is much of an alternative other than someone 
stepping in
and provide some first-hand knowledge about the key.


Could an external service such as keybase.io be helpful here? It's not a 
FOSS service, but it's been doing good work on making GPG more 
accessible by tying into many services and putting them all in a sort of 
verification dashboard.


If keybase is new to you, here's my profile https://keybase.io/ryansb

The Fedora team could get a profile and verify the key(s) through 
github, the Fedora and Red Hat web sites, the Fedora magazine twitter 
account, and by having the Fedora team all sign publicly.


Combined with having the key on getfedora.org, it at least provides a 
measure of protection against our site being compromised. It also has 
the benefit of, if someone knows of any Fedora devs on Twitter or 
another service, they can follow the web of social-service trust. This 
isn't as good as if they had a direct path to the Fedora WoT through 
normal signatures, but it's much more likely to actually occur.


--
Ryan Brown / Senior Software Engineer, OpenStack / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pghmcfc pushed to perl-YAML-LibYAML (perl-YAML-LibYAML-0.62-1.fc24). "Update to 0.62 (..more)"

[notifications]

From c0847ec58b84136f59317be2fcd8db476fe229bf Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Mon, 22 Feb 2016 18:36:54 +
Subject: Update to 0.62
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- New upstream release 0.62
  - Fix for detecting filehandles (GH#42)
- This release by TINITA → update source URL
---
 perl-YAML-LibYAML.spec | 12 +---
 sources|  2 +-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/perl-YAML-LibYAML.spec b/perl-YAML-LibYAML.spec
index 8d435d8..828ae26 100644
--- a/perl-YAML-LibYAML.spec
+++ b/perl-YAML-LibYAML.spec
@@ -1,11 +1,11 @@
 Name:   perl-YAML-LibYAML
-Version:0.61
+Version:0.62
 Release:1%{?dist}
 Summary:Perl YAML Serialization using XS and libyaml
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/YAML-LibYAML/
-Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/YAML-LibYAML-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/T/TI/TINITA/YAML-LibYAML-%{version}.tar.gz
 
 # Install
 BuildRequires:  coreutils
@@ -22,6 +22,7 @@ BuildRequires:  perl(B::Deparse)
 BuildRequires:  perl(base)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(Exporter)
+BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
 BuildRequires:  perl(XSLoader)
@@ -38,7 +39,7 @@ BuildRequires:  perl(Filter::Util::Call)
 BuildRequires:  perl(IO::File)
 BuildRequires:  perl(IO::Pipe)
 BuildRequires:  perl(lib)
-BuildRequires:  perl(Scalar::Util)
+BuildRequires:  perl(Path::Class)
 BuildRequires:  perl(Test::Builder)
 BuildRequires:  perl(Test::More) >= 0.88
 BuildRequires:  perl(Tie::Array)
@@ -82,6 +83,11 @@ make test
 %{_mandir}/man3/YAML::XS::LibYAML.3*
 
 %changelog
+* Mon Feb 22 2016 Paul Howarth  - 0.62-1
+- Update to 0.62
+  - Fix for detecting filehandles (GH#42)
+- This release by TINITA → update source URL
+
 * Sun Feb 21 2016 Paul Howarth  - 0.61-1
 - Update to 0.61
   - Allow reading from and writing to IO::Handle (and derived) objects (GH#37)
diff --git a/sources b/sources
index 88e8e7d..9fe38db 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9667700a73e0a8653f3ffce297368bf2  YAML-LibYAML-0.61.tar.gz
+e8e0ba8c9f589c809ee04bb526ae03d7  YAML-LibYAML-0.62.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-YAML-LibYAML.git/commit/?h=perl-YAML-LibYAML-0.62-1.fc24=c0847ec58b84136f59317be2fcd8db476fe229bf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ralf Senderek]

> If the site is compromised, most bets are off sadly. 

Yes, for people who look only in one place, the manipulated web server.
But that is the reason why the fingerprint has to pop up in different places
where it is hard to fake. Even if this one user can be tricked, others can
discover that the site is compromised if the fingerprint is independently 
recorded
many times elsewhere.

BTW, pointing to a key server is not the way to convince anyone. A key server
is a convenient way to get keys, not a tool to assure their authenticity.
So I don't think that there is much of an alternative other than someone 
stepping in
and provide some first-hand knowledge about the key.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Richard W.M. Jones]

On Sun, Feb 21, 2016 at 11:31:05AM -0700, Chris Murphy wrote:
> On Sun, Feb 21, 2016 at 7:32 AM, Sam Varshavchik  
> wrote:
> > So, I see that someone hacked Linux Mint, and slipped in some trojaned ISO
> > download images.
> >
> 
> Since Fedora looks to be moving to Live USB Creator (maybe Fedora
> Media Writer, TBD) as the primary download for Fedora 24, I wonder if
> the new tool automatically verifies the GPG signed hash file, and
> compares that hash with a computed one from the downloaded file?

If we had virt-builder metadata, virt-builder will check the SHA256
[by default] hash of the downloaded cloud image.  The hash is
contained in the GPG signed metadata.  To do this, virt-builder ships
with (or would ship with, if we had virt-builder metadata) the Fedora
GPG pubkey.  Currently SUSE are doing exactly this for their cloud
images.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pghmcfc pushed to perl-YAML-LibYAML (master). "Update to 0.62 (..more)"

[notifications]

From c0847ec58b84136f59317be2fcd8db476fe229bf Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Mon, 22 Feb 2016 18:36:54 +
Subject: Update to 0.62
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- New upstream release 0.62
  - Fix for detecting filehandles (GH#42)
- This release by TINITA → update source URL
---
 perl-YAML-LibYAML.spec | 12 +---
 sources|  2 +-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/perl-YAML-LibYAML.spec b/perl-YAML-LibYAML.spec
index 8d435d8..828ae26 100644
--- a/perl-YAML-LibYAML.spec
+++ b/perl-YAML-LibYAML.spec
@@ -1,11 +1,11 @@
 Name:   perl-YAML-LibYAML
-Version:0.61
+Version:0.62
 Release:1%{?dist}
 Summary:Perl YAML Serialization using XS and libyaml
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/YAML-LibYAML/
-Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/YAML-LibYAML-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/T/TI/TINITA/YAML-LibYAML-%{version}.tar.gz
 
 # Install
 BuildRequires:  coreutils
@@ -22,6 +22,7 @@ BuildRequires:  perl(B::Deparse)
 BuildRequires:  perl(base)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(Exporter)
+BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
 BuildRequires:  perl(XSLoader)
@@ -38,7 +39,7 @@ BuildRequires:  perl(Filter::Util::Call)
 BuildRequires:  perl(IO::File)
 BuildRequires:  perl(IO::Pipe)
 BuildRequires:  perl(lib)
-BuildRequires:  perl(Scalar::Util)
+BuildRequires:  perl(Path::Class)
 BuildRequires:  perl(Test::Builder)
 BuildRequires:  perl(Test::More) >= 0.88
 BuildRequires:  perl(Tie::Array)
@@ -82,6 +83,11 @@ make test
 %{_mandir}/man3/YAML::XS::LibYAML.3*
 
 %changelog
+* Mon Feb 22 2016 Paul Howarth  - 0.62-1
+- Update to 0.62
+  - Fix for detecting filehandles (GH#42)
+- This release by TINITA → update source URL
+
 * Sun Feb 21 2016 Paul Howarth  - 0.61-1
 - Update to 0.61
   - Allow reading from and writing to IO::Handle (and derived) objects (GH#37)
diff --git a/sources b/sources
index 88e8e7d..9fe38db 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9667700a73e0a8653f3ffce297368bf2  YAML-LibYAML-0.61.tar.gz
+e8e0ba8c9f589c809ee04bb526ae03d7  YAML-LibYAML-0.62.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-YAML-LibYAML.git/commit/?h=master=c0847ec58b84136f59317be2fcd8db476fe229bf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc uploaded YAML-LibYAML-0.62.tar.gz for perl-YAML-LibYAML

[notifications]

e8e0ba8c9f589c809ee04bb526ae03d7  YAML-LibYAML-0.62.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-YAML-LibYAML/YAML-LibYAML-0.62.tar.gz/md5/e8e0ba8c9f589c809ee04bb526ae03d7/YAML-LibYAML-0.62.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Mat Booth]

On 22 February 2016 at 17:38, Corey Sheldon  wrote:
>
> Kevin, et al.
>
> I am willing to help with the re-write but admittedly some of it will
require a crash course for me.
>
>
> On 02/22/2016 11:31 AM, Kevin Fenzi wrote:
>
> On Mon, 22 Feb 2016 15:02:45 +
> Mat Booth  wrote:
>
> Wow, that "HOWTO" is a really old page -- not changed since being
> imported from the old moin moin wiki. My feeling is that page should
> be deleted and the "How to create an RPM package" page should be
> updated.
>
> Here is the official guideline:
> https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 --
> basically, we just got out of the business of keeping track of what
> the minimum buildroot contains.
>
> Should we just delete that HOWTO page?
>
> Really you should be using mock these days and it should tell you when
> you don't have the right buildrequires present by failing until you add
> them.
>
> kevin
>
>

Actually, I just went ahead and made the change:
https://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package=435832=432092

Now it links to a document that tells you how test package builds using
mock.


--
Mat Booth
http://fedoraproject.org/get-fedora
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Kevin Fenzi]

On Mon, 22 Feb 2016 18:21:04 -
"Ralf Senderek"  wrote:

> While signing new keys with old release keys would certainly help to
> make the attacker's job harder, it doesn't solve the trust problem. 

I don't think it even makes their job harder. 

> The one thing people would have to check is the fingerprint. That in
> itself would be sufficient even if the new key is not being signed by
> another one. The current download gives a fingerprint for the new
> Fedora 24 key:
> 
> Key fingerprint = 5048 BDBB A5E7 76E5 47B0  9CCC 73BD E983 81B4 6521
> 
> and this could as well be manipulated by the attacker who has access
> to the web server. Given that this fingerprint is actually correct,
> it would help if it was printed off-line in any publication
> authorized by Fedora. The use and distribution of the fingerprint to
> various places showing consistently the same information would make
> it near impossible to fake the key. If that had been done beforehand,
> all a new, ordinary user would have to do is to check this one
> fingerprint.

They would know that they should do this how? 

It is available on sks keyservers like keys.fedoraproject.org

> So please can someone convince me that the key above is really the
> right one? If so, using this fingerprint anywhere would help to build
> the trust that is not there yet.

In the end you are either trusting the https network or the gpg web of
trust. 

> Using HTTPS does not at all verify that the information you get is
> correct, it assures you of the correct origin, if https actually
> works as advertised, which in many cases it doesn't, But Red Had
> could publish the Fedora fingerprint as well on their servers. --

Sure, but who would know to look there?

If the site is compromised, most bets are off sadly. 

kevin



pgpMJjcnDPaiV.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Mat Booth]

On 22 February 2016 at 16:31, Kevin Fenzi  wrote:

> On Mon, 22 Feb 2016 15:02:45 +
> Mat Booth  wrote:
>
> > Wow, that "HOWTO" is a really old page -- not changed since being
> > imported from the old moin moin wiki. My feeling is that page should
> > be deleted and the "How to create an RPM package" page should be
> > updated.
> >
> > Here is the official guideline:
> > https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 --
> > basically, we just got out of the business of keeping track of what
> > the minimum buildroot contains.
>
> Should we just delete that HOWTO page?
>
> Really you should be using mock these days and it should tell you when
> you don't have the right buildrequires present by failing until you add
> them.
>
> kevin



Yeah, this is what I was suggesting. And the "How to create an RPM package"
page should be updated to tell users to use mock.

I think anyone can edit these pages (I don't believe they belong to the
FPC.)


-- 
Mat Booth
http://fedoraproject.org/get-fedora
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Kevin Fenzi]

On Mon, 22 Feb 2016 16:48:29 +
Gregory Maxwell  wrote:

> On Sun, Feb 21, 2016 at 2:32 PM, Sam Varshavchik
>  wrote:
> > One has to jump into the installation guide, in order to find a
> > buried link to https://getfedora.org/verify  
> 
> The instructions here have you download a set of PGP keys from the
> same https webserver which could have been compromised to give you bad
> download instructions.
> 
> The Fedora 24 key inside it is not signed by any other key. (And even
> if it were, no instruction is given to verify the key authenticity;
> nor to seek out signatures on the key elsewhere (there is one on the
> MIT key servers, but it does no good to users following these
> instructions)).
> 
> This is security theater

Well, I agree the instructions could do better, but how would that help
if the site was compromised? The attackers would write their own
instructions. 

In addition to the verify link, the https://getfedora.org/en/keys/faq/
needs a good going over. 

Pointing people to the sks keyservers to download the key would be nice
and asking them to check the signatures for a web of trust link would
be great, but I am not sure how many people would care to do that or
have any links there. 

> I've previously complained that Fedora PGP keys are unsigned,
> otherwise unauthenticated, and shipped in the same location as the
> potentially compromised binaries; and that the verification does
> nothing to improve security against compromise of the main download
> site, or MITM near enough to it on the network to get a https cert...
> to no effect before.

If the site is compromised how would any of that help?

> Authenticating keys is hard in general; but existing fedora users
> should at least be able to trust-on-first-use chain from earlier keys
> to later ones-- assuming the fedora keys are kept offline and not
> compromised-- and the instructions should have them verify
> accordingly.  But this would require the keys being shipped are signed
> with prior releases key (or some static key signing key), and existing
> users being told to check for that. It would also be preferable if the
> keys were distributed on a separate server on a different network, so
> that https would protect users that didn't/couldn't verify the
> authenticity of the downloaded keys.

This is already done somewhat... the fedora-repos package has all the
keys in it from the time it was last updated. So, if you have a fedora
install you can check the key in fedora-repos. However, that still
doesn't get around the fact that the anchor of trust here is the ca
certificate system, or I suppose, best case it would be a web of trust
link back to the gpg key, but the web of trust is not that expansive
and random users who don't care about gpg likely wouldn't have any
links into the Fedora web of trust. 

kevin


pgpQdT6DRlmzY.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Ralf Senderek]

> On Sun, Feb 21, Gregory Maxwell wrote:

> The Fedora 24 key inside it is not signed by any other key. 
... 
> Authenticating keys is hard in general; but existing fedora users
> should at least be able to trust-on-first-use chain from earlier keys
> to later ones-- assuming the fedora keys are kept offline and not
> compromised-- and the instructions should have them verify
> accordingly.  But this would require the keys being shipped are signed
> with prior releases key (or some static key signing key), and existing
> users being told to check for that. 

While signing new keys with old release keys would certainly help to make the
attacker's job harder, it doesn't solve the trust problem. 
The one thing people would have to check is the fingerprint. That in itself 
would be
sufficient even if the new key is not being signed by another one.
The current download gives a fingerprint for the new Fedora 24 key:

Key fingerprint = 5048 BDBB A5E7 76E5 47B0  9CCC 73BD E983 81B4 6521

and this could as well be manipulated by the attacker who has access to the web 
server.
Given that this fingerprint is actually correct, it would help if it was 
printed off-line in any
publication authorized by Fedora. The use and distribution of the fingerprint 
to various places
showing consistently the same information would make it near impossible to fake 
the key.
If that had been done beforehand, all a new, ordinary user would have to do is 
to check this one
fingerprint.

So please can someone convince me that the key above is really the right one?
If so, using this fingerprint anywhere would help to build the trust that is 
not there yet.


> It would also be preferable if the
> keys were distributed on a separate server on a different network, so
> that https would protect users that didn't/couldn't verify the
> authenticity of the downloaded keys.

Using HTTPS does not at all verify that the information you get is correct, it 
assures you of the
correct origin, if https actually works as advertised, which in many cases it 
doesn't,
But Red Had could publish the Fedora fingerprint as well on their servers.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Minimizing the fedora docker base image footprint

[Daniel J Walsh]

On Mon, 2016-02-22 at 11:26 -0500, Bill Nottingham wrote:
> Courtney Pacheco (cpach...@redhat.com) said: 
> > 
> > Hi everyone,
> > 
> > I've spent some time trying to minimize the footprint of the Fedora
> > docker
> > base image. Overall, I managed to reduce its size by 39.9%.
> > 
> > A summary of the work I did can be found here:
> > https://gist.github.com/iamcourtney/1a4af7c4289014f57080
> > 
> > If you're interested, you can find a more detailed version of the
> > above work
> > here: https://gist.github.com/iamcourtney/b8709ed897b7ecc9ac0f
> May be a dumb question...
> 
> If we're excluding DNF, RPM, etc. for a slimmer base image during
> runtime,
> how are we describing the best practices for build? Is the intention
> that
> you should always be pulling in a separate tool container to assist
> with
> the build process?
> 
> Bill
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org
> 
> 

I have no problem removing dnf, but removing rpm is going to far.  For
now we still need rpm for looking at the contents of a container.
 While external rpm would probably work, I don't think we are redy for
this, nor is the benefit enough.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Self Introduction: Paulo Henrique Rodrigues Pinheiro

[Paulo Henrique Rodrigues Pinheiro]

Hi!


My name is Paulo, I am a developer and administrator of Linux systems.

Ago many years I worked (for a short time) in a Brazilian Linux 
distribution (Conectiva Linux), and after that I did not contribute more 
with open source projects.


Finally I found a project that encouraged me, and the opportunity to put 
it available for Fedora.


I began the work of building a new package for http://unqlite.org in Fedora:

> UnQLite is an embedded NoSQL (Key/Value store and Document-store)
> database engine. Unlike most other NoSQL databases, UnQLite does not
> have a separate server process. UnQLite reads and writes directly to
> ordinary disk files. A complete database with multiple collections,
> is contained in a single disk file. The database file format is cross-
> platform


Here's the ticket:

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

Thank you.

--
Paulo Henrique Rodrigues Pinheiro
pa...@sysincloud.it
http://www.sysincloud.it
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Corey Sheldon]

Kevin, et al.

I am willing to help with the re-write but admittedly some of it will
require a crash course for me.

On 02/22/2016 11:31 AM, Kevin Fenzi wrote:
> On Mon, 22 Feb 2016 15:02:45 +
> Mat Booth  wrote:
>
>> Wow, that "HOWTO" is a really old page -- not changed since being
>> imported from the old moin moin wiki. My feeling is that page should
>> be deleted and the "How to create an RPM package" page should be
>> updated.
>>
>> Here is the official guideline:
>> https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 --
>> basically, we just got out of the business of keeping track of what
>> the minimum buildroot contains.
> Should we just delete that HOWTO page?
>
> Really you should be using mock these days and it should tell you when
> you don't have the right buildrequires present by failing until you add
> them. 
>
> kevin
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

-- 
Corey W. Sheldon
Freelance IT Tutor
Security Researcher | Fedora Ambassador, North America
sheldon.co...@gmail.com | cshel...@ameridea.net | core...@fedoraproject.org
ph: (11)+1.310.909.7672 skype: cwwsheldon
Securely:
PGP: 

<>

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

orion pushed to perl-PDL (master). "Rebuild for gsl 2.1"

[notifications]

From db17ae3f21d738a41ab2ac74672e8025a0ff7f89 Mon Sep 17 00:00:00 2001
From: Orion Poplawski 
Date: Mon, 22 Feb 2016 10:07:03 -0700
Subject: Rebuild for gsl 2.1

---
 perl-PDL.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-PDL.spec b/perl-PDL.spec
index 991d139..668c709 100644
--- a/perl-PDL.spec
+++ b/perl-PDL.spec
@@ -11,7 +11,7 @@
 Name:   perl-PDL
 %global cpan_version 2.015
 Version:2.15.0
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:The Perl Data Language
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -214,6 +214,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Feb 22 2016 Orion Poplawski  - 2.15.0-4
+- Rebuild for gsl 2.1
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.15.0-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-PDL.git/commit/?h=master=db17ae3f21d738a41ab2ac74672e8025a0ff7f89
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Gregory Maxwell]

On Sun, Feb 21, 2016 at 2:32 PM, Sam Varshavchik  wrote:
> One has to jump into the installation guide, in order to find a buried link
> to https://getfedora.org/verify

The instructions here have you download a set of PGP keys from the
same https webserver which could have been compromised to give you bad
download instructions.

The Fedora 24 key inside it is not signed by any other key. (And even
if it were, no instruction is given to verify the key authenticity;
nor to seek out signatures on the key elsewhere (there is one on the
MIT key servers, but it does no good to users following these
instructions)).

This is security theater.

I've previously complained that Fedora PGP keys are unsigned,
otherwise unauthenticated, and shipped in the same location as the
potentially compromised binaries; and that the verification does
nothing to improve security against compromise of the main download
site, or MITM near enough to it on the network to get a https cert...
to no effect before.

Authenticating keys is hard in general; but existing fedora users
should at least be able to trust-on-first-use chain from earlier keys
to later ones-- assuming the fedora keys are kept offline and not
compromised-- and the instructions should have them verify
accordingly.  But this would require the keys being shipped are signed
with prior releases key (or some static key signing key), and existing
users being told to check for that. It would also be preferable if the
keys were distributed on a separate server on a different network, so
that https would protect users that didn't/couldn't verify the
authenticity of the downloaded keys.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1169647] perl-OpenOffice-UNO-0.07-15.fc22 FTBFS: No Package found for libreoffice-headless

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1169647
Bug 1169647 depends on bug 1303619, which changed state.

Bug 1303619 Summary: Cannot install libreoffice-sdk: nothing provides 
java-devel(x86-64)
https://bugzilla.redhat.com/show_bug.cgi?id=1303619

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE



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

[Bug 1305212] perl-OpenOffice-UNO: FTBFS in rawhide

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1305212
Bug 1305212 depends on bug 1303619, which changed state.

Bug 1303619 Summary: Cannot install libreoffice-sdk: nothing provides 
java-devel(x86-64)
https://bugzilla.redhat.com/show_bug.cgi?id=1303619

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE



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

Re: Minimizing the fedora docker base image footprint

[Courtney Pacheco]

On 02/22/2016 11:26 AM, Bill Nottingham wrote:

Courtney Pacheco (cpach...@redhat.com) said:

Hi everyone,

I've spent some time trying to minimize the footprint of the Fedora docker
base image. Overall, I managed to reduce its size by 39.9%.

A summary of the work I did can be found here:
https://gist.github.com/iamcourtney/1a4af7c4289014f57080

If you're interested, you can find a more detailed version of the above work
here: https://gist.github.com/iamcourtney/b8709ed897b7ecc9ac0f

May be a dumb question...

If we're excluding DNF, RPM, etc. for a slimmer base image during runtime,
how are we describing the best practices for build? Is the intention that
you should always be pulling in a separate tool container to assist with
the build process?

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

Hi Bill,

Ideally, we'd like to remove dnf and other tools that build the image 
because it's like shipping the "BuildRequires" fields as part of a 
binary rpm.


In place of dnf, rpm, etc., we'd like to have a "builder tool" that 
volume mounts dnf or other tools during the build, or builds and 
produces an image using outside tools. So yes, the intention would be to 
pull in a separate tool container to assist with the build process.


Hope that helps

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

Re: [Guidelines change] Changes to the packaging guidelines

[Kevin Fenzi]

On Mon, 22 Feb 2016 15:02:45 +
Mat Booth  wrote:

> Wow, that "HOWTO" is a really old page -- not changed since being
> imported from the old moin moin wiki. My feeling is that page should
> be deleted and the "How to create an RPM package" page should be
> updated.
> 
> Here is the official guideline:
> https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 --
> basically, we just got out of the business of keeping track of what
> the minimum buildroot contains.

Should we just delete that HOWTO page?

Really you should be using mock these days and it should tell you when
you don't have the right buildrequires present by failing until you add
them. 

kevin



pgpwPrqXwdlTk.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: More prominent link to verification hashes

[Kevin Fenzi]

On Sun, 21 Feb 2016 23:21:58 +0100
Jens Lody  wrote:

> This can also be done before clicking the link-button, or the download
> splash is also shown without javascript. This should not be too hard
> to implement.

https://fedorahosted.org/fedora-websites awaits your ticket. 

Bonus points for proposed patch also. ;) 

kevin


pgp2H0cGaCoS7.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Minimizing the fedora docker base image footprint

[David Cantrell]

On Mon, Feb 22, 2016 at 11:04:40AM -0500, Adam Jackson wrote:
> On Mon, 2016-02-22 at 09:54 -0500, Courtney Pacheco wrote:
> 
> > If possible, I'd like some feedback on the work I did. Comments and 
> > criticism are more than welcomed! I realize there may be some 
> > controversy in terms of what I chose to remove and what I chose to turn 
> > into weak dependencies, but I would like to hear your thoughts either way.
> 
> Removing tzdata seems like a bad idea. I think a small amount of code
> change could make the cost of keeping tzdata much lower. Virtually all
> of the tzdata files are less than 4 kilobytes, so most of the on-disk
> storage cost is block size overhead:
> 
> dmt:~% du -s --apparent-size /usr/share/zoneinfo
> 1720  /usr/share/zoneinfo
> dmt:~% du -s /usr/share/zoneinfo
> 4780  /usr/share/zoneinfo
> 
> Possible options include:
> 
> a) Glue all the compiled zone info together in a single file, teach
> glibc and friends about it
> b) Glue the zone info together in a romfs image, mount it from a
> systemd unit
> c) Both of the above: glue them all together in a romfs, add a
> fuse/overlay fs to expose the individual files
> d) Mount a zoneinfo fs exported from the host

The 'posix' and 'right' subdirectories in /usr/share/zoneinfo could be
dumped and then whichever one we want could just be installed as
/usr/share/zoneinfo.  The 'posix' collection are the zones without counting
leap seconds normally, the 'right' collection are the zones with leap
seconds counted normally.

-- 
David Cantrell 
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Minimizing the fedora docker base image footprint

[Josh Boyer]

On Mon, Feb 22, 2016 at 9:54 AM, Courtney Pacheco  wrote:
> Hi everyone,
>
> I've spent some time trying to minimize the footprint of the Fedora docker
> base image. Overall, I managed to reduce its size by 39.9%.

Thanks for doing this.  It is great to see someone working on minimization.

> A summary of the work I did can be found here:
> https://gist.github.com/iamcourtney/1a4af7c4289014f57080
>
> If you're interested, you can find a more detailed version of the above work
> here: https://gist.github.com/iamcourtney/b8709ed897b7ecc9ac0f
>
> I essentially looked at which packages were being installed to the base
> image and tried to determine which of those packages could be turned into
> weak dependencies and which of those packages we could possibly break up.
>
> If possible, I'd like some feedback on the work I did. Comments and
> criticism are more than welcomed! I realize there may be some controversy in
> terms of what I chose to remove and what I chose to turn into weak
> dependencies, but I would like to hear your thoughts either way.

On the "Kernel Packages" section, I tend to agree that kmod and
kmod-libs likely don't make sense in a docker container.  However,
libseccomp should likely remain.  The library is there to make use of
the in-kernel seccomp functionality, and systemd and other
applications use it to limit their syscall interface to the kernel.
This reduces the potential attack surface, and in essence at least
helps containers actually contain.

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

Re: Minimizing the fedora docker base image footprint

[Bill Nottingham]

Courtney Pacheco (cpach...@redhat.com) said: 
> Hi everyone,
> 
> I've spent some time trying to minimize the footprint of the Fedora docker
> base image. Overall, I managed to reduce its size by 39.9%.
> 
> A summary of the work I did can be found here:
> https://gist.github.com/iamcourtney/1a4af7c4289014f57080
> 
> If you're interested, you can find a more detailed version of the above work
> here: https://gist.github.com/iamcourtney/b8709ed897b7ecc9ac0f

May be a dumb question...

If we're excluding DNF, RPM, etc. for a slimmer base image during runtime,
how are we describing the best practices for build? Is the intention that
you should always be pulling in a separate tool container to assist with
the build process?

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

Re: Large number of packages to be orphaned on Feb 26

[Jitka Plesníková]

On 02/22/2016 10:02 AM, Paul Howarth wrote:

On 21/02/16 11:34, Emmanuel Seyman wrote:


Hi, folks.

It's been announced that Christoper Mang's packages will be orphaned
next Friday unless he speaks up. A number of Perl packages are involved
and I figured it would be nice to figure who's interested in maintaining
which package by Friday.

The packages involved:

* perl-AnyEvent-I3
* perl-Async-MergePoint
* perl-CPAN-FindDependencies
* perl-CPANPLUS-Dist-Fedora
* perl-Catalyst-Authentication-Store-DBIx-Class
* perl-Catalyst-Plugin-Authorization-ACL
* perl-Class-Throwable
* perl-Class-XSAccessor
* perl-Data-MessagePack
* perl-Digest-CRC
* perl-Event-ExecFlow
* perl-ExtUtils-CChecker
* perl-File-Find-Object
* perl-File-Find-Object-Rule
* perl-Geo-METAR
* perl-HTML-Entities-Interpolate
* perl-Log-Handler
* perl-Net-Random
* perl-PDL-Graphics-PLplot
* perl-Perl6-Slurp
* perl-Proc-Queue
* perl-Set-Array
* perl-Storm
* perl-Tapper
* perl-Test-TrailingSpace
* perl-Text-Xslate
* perl-Tie-Function
* perl-Time-timegm
* perl-WebService-Linode
* perl-X11-Protocol
* perl-XML-Bare
* perl-XML-Tiny

I know I'll be picking up the two Catalyst packages,
perl-HTML-Entities-Interpolate and probably the two XML ones.


I'll take:

> * perl-Class-XSAccessor
> * perl-Digest-CRC
> * perl-ExtUtils-CChecker
> * perl-File-Find-Object
> * perl-File-Find-Object-Rule
> * perl-Perl6-Slurp
> * perl-Set-Array
> * perl-Test-TrailingSpace

Cheers, Paul.


I'll take these packages:

* perl-AnyEvent-I3
* perl-Async-MergePoint
* perl-CPAN-FindDependencies
* perl-CPANPLUS-Dist-Fedora
* perl-Class-Throwable
* perl-Data-MessagePack
* perl-Event-ExecFlow
* perl-Log-Handler
* perl-Net-Random
* perl-Proc-Queue
* perl-Storm
* perl-Tapper
* perl-Text-Xslate
* perl-Tie-Function
* perl-Time-timegm
* perl-X11-Protocol

Regards,
Jitka
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Fedora Rawhide 20160222 compose check report

[Fedora compose checker]

No missing expected images.

Images in this compose but not Rawhide 20160221:

Cloud_atomic disk raw x86_64
Games live x86_64
Design_suite live x86_64
Games live i386
Kde disk raw armhfp
Kde live i386
Scientific_kde live x86_64
Cloud_atomic disk qcow x86_64
Scientific_kde live i386
Design_suite live i386
Kde live x86_64

Images in Rawhide 20160221 but not this:

Cloud docker x86_64
Server disk raw armhfp

Failed openQA tests: 11 of 69

ID: 5789Test: x86_64 workstation_live default_install
URL: https://openqa.fedoraproject.org/tests/5789
ID: 5794Test: i386 workstation_live default_install
URL: https://openqa.fedoraproject.org/tests/5794
ID: 5790Test: x86_64 workstation_live default_install@uefi
URL: https://openqa.fedoraproject.org/tests/5790
ID: 5785Test: x86_64 kde_live default_install@uefi
URL: https://openqa.fedoraproject.org/tests/5785
ID: 5783Test: i386 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/5783
ID: 5784Test: x86_64 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/5784
ID: 5759Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/5759
ID: 5774Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/5774
ID: 5776Test: i386 universal package_set_kde
URL: https://openqa.fedoraproject.org/tests/5776
ID: 5761Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/5761
ID: 5775Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/5775

Passed openQA tests: 52 of 69
6 openQA tests may be still running or broken!
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Minimizing the fedora docker base image footprint

[Adam Jackson]

On Mon, 2016-02-22 at 09:54 -0500, Courtney Pacheco wrote:

> If possible, I'd like some feedback on the work I did. Comments and 
> criticism are more than welcomed! I realize there may be some 
> controversy in terms of what I chose to remove and what I chose to turn 
> into weak dependencies, but I would like to hear your thoughts either way.

Removing tzdata seems like a bad idea. I think a small amount of code
change could make the cost of keeping tzdata much lower. Virtually all
of the tzdata files are less than 4 kilobytes, so most of the on-disk
storage cost is block size overhead:

dmt:~% du -s --apparent-size /usr/share/zoneinfo
1720/usr/share/zoneinfo
dmt:~% du -s /usr/share/zoneinfo
4780/usr/share/zoneinfo

Possible options include:

a) Glue all the compiled zone info together in a single file, teach
glibc and friends about it
b) Glue the zone info together in a romfs image, mount it from a
systemd unit
c) Both of the above: glue them all together in a romfs, add a
fuse/overlay fs to expose the individual files
d) Mount a zoneinfo fs exported from the host

A somewhat similar criticism applies to removing gconv. Pretending that
applications don't have to deal with multiple character encodings is
likely to be wrong, and we don't currently have any metadata to track
whether a binary calls iconv() so there's no way to express the need
for the gconv modules. Here again, most of these libraries are
relatively small, and gluing them all together would be a decent size
win:

dmt:/usr/lib64/gconv% du -c *.so | tail -1
7352total
dmt:/usr/lib64/gconv% du --apparent-size -c *.so | tail -1
6448total
dmt:/usr/lib64/gconv% size -t *.so | tail -1
4778516  161368    2016 4941900  4b684c 
(TOTALS)

Both things are possible here: we could teach rpm's find-requires to
know about iconv, _and_ link all the gconv modules together.

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

Re: Fedora mass rebuild 2016

[Jonathan Wakely]

On 22/02/16 08:35 -0700, Jerry James wrote:

polymake-2.14r1-4.fc24.src.rpm.log


I already added -std=gnu++98 to this package, but the build still
fails.  I don't understand the gcc error.  GCC appears to be producing
non-const temporaries, and then complaining that the temporaries are
non-const.  I asked for help with this about a week ago, and Jonathan
Wakely said he would take a look.  I have not heard back from him yet:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3HQ5JV4NNDZN7YMGMBSS5FCYBITSTEXM/#3HQ5JV4NNDZN7YMGMBSS5FCYBITSTEXM

Any ideas on what is going on there would be much appreciated.


I did look, but wasn't able to figure out the problem. My attempts to
reduce it to a small example didn't produce the same failure. I'll
come back to it ASAP and spend more time on it.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora mass rebuild 2016

[Jerry James]

On Mon, Feb 22, 2016 at 4:55 AM, Marek Polacek  wrote:
> Macaulay2-1.6-22.fc24.src.rpm
> bogus errors with static data member template
> http://gcc.gnu.org/PR69098
> fixed upstream and in gcc-6.0.0-0.11.fc24

I don't think this has been fixed.  I updated ntl over the weekend,
and rebuilt Macaulay2 as part of that work.  Macaulay2 still failed
with this same error, using gcc-6.0.0-0.11.fc24, so I added a patch to
workaround the issue, so as not to leave Macaulay2 with broken deps in
Rawhide.  Indeed, the gcc-6.0.0-0.11.fc24 changelog says:

- temporarily revert PR c++/10200 fix

The fix must have caused other issues, I guess.  I don't see anything
about that PR in the gcc-6.0.0-0.12.fc24 changelog, so I believe this
issue is still outstanding.

> Now, this is a list of packages that very likely contain invalid C++14 code.
> Some of them worked in the past, but only by luck and were just ill-fated.
> Please try to fix the issues rather than adding workaround flags like
> -fpermissive, -Wno-unused-but-set-variable etc.
>
> Most of the issues should be described in porting_to, so I won't repeat it
> here.  Especially, if something fails, try using 
> -fno-delete-null-pointer-checks
> or -fno-lifetime-dse before opening a PR.  However, it's certainly possible
> that a compiler bug might crept it, and the code is valid.  It's not feasible
> for me to try to fix all these packages.

[snip]

> polymake-2.14r1-4.fc24.src.rpm.log

I already added -std=gnu++98 to this package, but the build still
fails.  I don't understand the gcc error.  GCC appears to be producing
non-const temporaries, and then complaining that the temporaries are
non-const.  I asked for help with this about a week ago, and Jonathan
Wakely said he would take a look.  I have not heard back from him yet:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3HQ5JV4NNDZN7YMGMBSS5FCYBITSTEXM/#3HQ5JV4NNDZN7YMGMBSS5FCYBITSTEXM

Any ideas on what is going on there would be much appreciated.

The maddening thing is that upstream polymake has released a new
version, and the release notes say this new version brings "full C++11
compatibility".  But I can't update to it, because it needs Singular
4.x and normaliz 3.x, and updating those 2 packages will break both
Macaulay2 and sagemath.  Sigh.
-- 
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora mass rebuild 2016

[Jakub Jelinek]

On Mon, Feb 22, 2016 at 08:35:34AM -0700, Jerry James wrote:
> I don't think this has been fixed.  I updated ntl over the weekend,
> and rebuilt Macaulay2 as part of that work.  Macaulay2 still failed
> with this same error, using gcc-6.0.0-0.11.fc24, so I added a patch to
> workaround the issue, so as not to leave Macaulay2 with broken deps in
> Rawhide.  Indeed, the gcc-6.0.0-0.11.fc24 changelog says:
> 
> - temporarily revert PR c++/10200 fix
> 
> The fix must have caused other issues, I guess.  I don't see anything
> about that PR in the gcc-6.0.0-0.12.fc24 changelog, so I believe this
> issue is still outstanding.

-0.12.fc24 has the reversion removed, is in sync with what latest gcc does.
So, if you have some issue with -0.12.fc24 and you are convinced it is a g++
bug rather than package bug, please file it with small self-contained
reproducer.

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

Re: kmods and Fedora

[Frank Ch. Eigler]

Bastien Nocera  writes:

>> > If you are creating a cert to sign the out-of-tree modules and expect
>> > it to be accepted by the kernel, it cannot be ephemeral.  A user would
>> > need someway to import it into their kernel or have it passed from
>> > grub.  [...]
>> 
>> That just proves that Restricted Boot and especially our implementation of
>> it (requiring kernel modules to be signed) is a very bad thing.
>
> How do you expect to be able to ensure that the kernel only loads "known good"
> modules if you can insert random modules that might subvert SecureBoot and
> all that it allows to secure?

For systemtap on secureboot systems, we rely on Machine Owner Keys.
These keys are generated once.  The public half is put into UEFI via
mokutil and a reboot.  The private half held at another trusted
machine.  Then that machine can sign modules with the MOK key and have
normal Fedora kernels/shims accept them.

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

Re: Fedora mass rebuild 2016

[Michael Schwendt]

On Mon, 22 Feb 2016 12:55:56 +0100, Marek Polacek wrote:
 
> audiofile-0.3.6-9.fc24.src.rpm

This one was left-shifting a negative integer and also triggered
narrowing-conversion errors.

Fixed in Rawhide already.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


22 packages were orphaned
-
backintime [el6, epel7] was orphaned by kevin
 Simple backup tool inspired from the Flyback project and TimeVault
 https://admin.fedoraproject.org/pkgdb/package/backintime
devtodo2 [f23, f22, el6, master, el5] was orphaned by puiterwijk
 Manage a prioritized list of to do items organized by directory
 https://admin.fedoraproject.org/pkgdb/package/devtodo2
dx-samples [master] was orphaned by rathann
 OpenDX Examples
 https://admin.fedoraproject.org/pkgdb/package/dx-samples
eigen2 [master] was orphaned by rdieter
 A lightweight C++ template library for vector and matrix math
 https://admin.fedoraproject.org/pkgdb/package/eigen2
libx86 [el6, epel7, el5] was orphaned by remi
 Library for making real-mode x86 calls
 https://admin.fedoraproject.org/pkgdb/package/libx86
mhddfs [f23, f22, master] was orphaned by kevin
 Fuse-based file system for unifying several mount points into one
 https://admin.fedoraproject.org/pkgdb/package/mhddfs
monitor-edid [f23, f22, master, el6, epel7, el5] was orphaned by remi
 Tool for probing and parsing monitor EDID
 https://admin.fedoraproject.org/pkgdb/package/monitor-edid
ocsinventory [f23, f22, master, el6, epel7, el5] was orphaned by remi
 Open Computer and Software Inventory Next Generation
 https://admin.fedoraproject.org/pkgdb/package/ocsinventory
ocsinventory-agent [f23, f22, master, el6, epel7, el5] was orphaned by remi
 Open Computer and Software Inventory Next Generation client
 https://admin.fedoraproject.org/pkgdb/package/ocsinventory-agent
ocsinventory-ipdiscover [f23, f22, master, epel7] was orphaned by remi
 Open Computer and Software Inventory Next Generation client
 https://admin.fedoraproject.org/pkgdb/package/ocsinventory-ipdiscover
perl-Apache-DBI [el6, epel7, el5] was orphaned by remi
 Persistent database connections with Apache/mod_perl
 https://admin.fedoraproject.org/pkgdb/package/perl-Apache-DBI
perl-Apache2-SOAP [el6, epel7, el5] was orphaned by remi
 A replacement for Apache::SOAP designed to work with mod_perl 2
 https://admin.fedoraproject.org/pkgdb/package/perl-Apache2-SOAP
perl-FusionInventory-Agent-Task-ESX [el6] was orphaned by remi
 vCenter/ESX/ESXi remote inventory for FusionInventory Agent
 
https://admin.fedoraproject.org/pkgdb/package/perl-FusionInventory-Agent-Task-ESX
perl-FusionInventory-Agent-Task-NetDiscovery [el6] was orphaned by remi
 Network discovery support for FusionInventory Agent
 
https://admin.fedoraproject.org/pkgdb/package/perl-FusionInventory-Agent-Task-NetDiscovery
perl-FusionInventory-Agent-Task-OcsDeploy [el6] was orphaned by remi
 OCS Inventory NG Software deployment support for FusionInventory Agent
 
https://admin.fedoraproject.org/pkgdb/package/perl-FusionInventory-Agent-Task-OcsDeploy
perl-FusionInventory-Agent-Task-SNMPQuery [el6] was orphaned by remi
 SNMP Query support for FusionInventory Agent
 
https://admin.fedoraproject.org/pkgdb/package/perl-FusionInventory-Agent-Task-SNMPQuery
perl-Net-CUPS [el6, epel7, el5] was orphaned by remi
 Perl bindings to the CUPS C API Interface
 https://admin.fedoraproject.org/pkgdb/package/perl-Net-CUPS
perl-Net-NBName [el6, epel7] was orphaned by remi
 NetBIOS Name Service Requests
 https://admin.fedoraproject.org/pkgdb/package/perl-Net-NBName
perl-Proc-Daemon [el6, epel7, el5] was orphaned by remi
 Run Perl program as a daemon process
 https://admin.fedoraproject.org/pkgdb/package/perl-Proc-Daemon
python-livereload [f23, f22] was orphaned by suanand
 An awesome tool for web developers
 https://admin.fedoraproject.org/pkgdb/package/python-livereload
python-storm [f23, f22, master] was orphaned by abompard
 An object-relational mapper (ORM) for Python
 https://admin.fedoraproject.org/pkgdb/package/python-storm
virtuoso-opensource [master] was orphaned by rdieter
 A high-performance object-relational SQL database
 https://admin.fedoraproject.org/pkgdb/package/virtuoso-opensource

47 packages were retired
-
ahc-tools [master, epel7] was retired by trown
 Tools for RDO-Manager automatic health checks
 https://admin.fedoraproject.org/pkgdb/package/ahc-tools
bangarang [master] was retired by jreznik
 Media player with nepomuk support
 https://admin.fedoraproject.org/pkgdb/package/bangarang
contour [master] was retired by jreznik
 A context sensitive user interface for Plasma Active
 https://admin.fedoraproject.org/pkgdb/package/contour
docker-registry [master, el6] was retired by lsm5
 Registry server for Docker
 https://admin.fedoraproject.org/pkgdb/package/docker-registry
kde-artwork-active [master] was retired by jreznik
 Artwork for Plasma Active
 

Re: bash completion dirs

[Neal Gompa]

On Mon, Feb 22, 2016 at 10:16 AM, Andrew Lutomirski  wrote:
>
> On Feb 22, 2016 7:14 AM, "Neal Gompa"  wrote:
>>
>> On Mon, Feb 22, 2016 at 10:11 AM, Ondřej Vašík  wrote:
>> > Ville Skyttä píše v Po 22. 02. 2016 v 14:12 +0200:
>> >> On Mon, Feb 22, 2016 at 2:04 PM, Thomas Moschny
>> >>  wrote:
>> >> > However, for the same reasons, shouldn't the filesystem package also
>> >> > own the "new" /usr/share/bash-completion/completions location?
>> >>
>> >> Why not. Note however that if going this route, the dirs
>> >> /usr/share/bash-completion and /usr/share/bash-completion/helpers
>> >> should be owned by it as well.
>> >
>> > Hmmms, makes sense... will add the ownerships in next rawhide filesystem
>> > package build.
>> >
>> > Regards,
>> > Ondrej
>> >
>>
>> If you're doing that, you might as well do the same for the other
>> shells we support completions for (zsh, fish, etc.).
>
> Fish is slightly in flux here, so maybe wait a little bit on that one?  I'll
> file a bug when the dust settles.
>

Okay, wait a bit on fish, but afaik, zsh and ksh have completion
directories. I'm a bit hazy on ksh, but I know zsh does.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora mass rebuild 2016

[Mark Wielaard]

On Mon, 2016-02-22 at 12:55 +0100, Marek Polacek wrote:
> blktap-3.0.0-4.fc24.git0.9.2.src.rpm
> crda-3.18_2015.10.22-1.fc24.src.rpm
> dahdi-tools-2.10.0-6.fc24.src.rpm
> gmqcc-0.3.5-8.fc23.src.rpm
> gstreamer1-plugins-good-1.7.1-1.fc24.src.rpm
> ipv6calc-0.99.1-13.fc24.src.rpm
> libpfm-4.6.0-3.fc23.src.rpm

At least this one has already been fixed upstream:
https://sourceforge.net/p/perfmon2/libpfm4/ci/85081d81b4020679a5d44790e249cfd56259baae/

> libreswan-3.16-1.fc24.src.rpm
> lldpad-1.0.1-2.git986eb2e.fc24.src.rpm
> loudmouth-1.5.1-1.fc24.src.rpm
> memkind-0.3.0-1.fc24.src.rpm
> nemo-2.8.6-1.fc24.src.rpm
> nfs-ganesha-2.3.0-2.fc24.src.rpm
> ocaml-libvirt-0.6.1.4-10.fc24.src.rpm
> pesign-0.111-7.fc24.src.rpm
> rstp-04012009git-14.fc23.src.rpm
> xneur-0.17.0-5.fc23.src.rpm
> -Wunused-const-variable
> debate whether this is a good idea is still ongoing

The discussion is in this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
But it could really use some concrete examples instead of handwaving
about hypotheticals. There is also a slight tweak to what is/isn't
considered "unused" patch under review here:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01433.html
If people could test that out to see if that makes them happy/sad that
would also be appreciated.

Cheers,

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

Re: kmods and Fedora

[Andrew Lutomirski]

On Feb 22, 2016 6:33 AM, "Bastien Nocera"  wrote:
>
>
>
> - Original Message -
> > Josh Boyer wrote:
> > > If you are creating a cert to sign the out-of-tree modules and expect
> > > it to be accepted by the kernel, it cannot be ephemeral.  A user would
> > > need someway to import it into their kernel or have it passed from
> > > grub.  The only way to do so is to have it embedded in shim or the
> > > kernel during the build of those binaries.  I do not foresee Fedora
> > > creating yet another persistent key to sign things with, which means
> > > you would need another tool that can use the existing key in the
> > > kernel builders.
> >
> > That just proves that Restricted Boot and especially our implementation
of
> > it (requiring kernel modules to be signed) is a very bad thing.
>
> How do you expect to be able to ensure that the kernel only loads "known
good"
> modules if you can insert random modules that might subvert SecureBoot and
> all that it allows to secure?

I still find it confusing that Fedora will let you do anything you want in
userspace but will not let you load your own kernel module.  This may or
may not be required by MS and/or UEFI Forum rules (I honestly have no idea,
and I recall that jejb was going to discuss this at some point but I don't
think it ever happened).  Regardless, I don't see a credible
widely-applicable threat model under which this is useful.

Would Fedora be permitted to simply drop the signed module requirement?

ISTM a genuinely useful approach might be to forcibly extend some PCR and
maybe blank out some keyrings if an unsigned module is loaded.

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

Re: bash completion dirs

[Andrew Lutomirski]

On Feb 22, 2016 7:14 AM, "Neal Gompa"  wrote:
>
> On Mon, Feb 22, 2016 at 10:11 AM, Ondřej Vašík  wrote:
> > Ville Skyttä píše v Po 22. 02. 2016 v 14:12 +0200:
> >> On Mon, Feb 22, 2016 at 2:04 PM, Thomas Moschny
> >>  wrote:
> >> > However, for the same reasons, shouldn't the filesystem package also
> >> > own the "new" /usr/share/bash-completion/completions location?
> >>
> >> Why not. Note however that if going this route, the dirs
> >> /usr/share/bash-completion and /usr/share/bash-completion/helpers
> >> should be owned by it as well.
> >
> > Hmmms, makes sense... will add the ownerships in next rawhide filesystem
> > package build.
> >
> > Regards,
> > Ondrej
> >
>
> If you're doing that, you might as well do the same for the other
> shells we support completions for (zsh, fish, etc.).

Fish is slightly in flux here, so maybe wait a little bit on that one?
I'll file a bug when the dust settles.

--Andy

>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: bash completion dirs

[Neal Gompa]

On Mon, Feb 22, 2016 at 10:11 AM, Ondřej Vašík  wrote:
> Ville Skyttä píše v Po 22. 02. 2016 v 14:12 +0200:
>> On Mon, Feb 22, 2016 at 2:04 PM, Thomas Moschny
>>  wrote:
>> > However, for the same reasons, shouldn't the filesystem package also
>> > own the "new" /usr/share/bash-completion/completions location?
>>
>> Why not. Note however that if going this route, the dirs
>> /usr/share/bash-completion and /usr/share/bash-completion/helpers
>> should be owned by it as well.
>
> Hmmms, makes sense... will add the ownerships in next rawhide filesystem
> package build.
>
> Regards,
> Ondrej
>

If you're doing that, you might as well do the same for the other
shells we support completions for (zsh, fish, etc.).



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: bash completion dirs

[Ondřej Vašík]

Ville Skyttä píše v Po 22. 02. 2016 v 14:12 +0200:
> On Mon, Feb 22, 2016 at 2:04 PM, Thomas Moschny
>  wrote:
> > However, for the same reasons, shouldn't the filesystem package also
> > own the "new" /usr/share/bash-completion/completions location?
> 
> Why not. Note however that if going this route, the dirs
> /usr/share/bash-completion and /usr/share/bash-completion/helpers
> should be owned by it as well.

Hmmms, makes sense... will add the ownerships in next rawhide filesystem
package build.

Regards,
Ondrej

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

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

Re: [ANNOUNCE] Fedora support for Vulkan

[Richard Shaw]

On Mon, Feb 22, 2016 at 8:52 AM, Adam Jackson  wrote:

> On Wed, 2016-02-17 at 14:30 -0600, Richard Shaw wrote:
> > I read the readme in the Vulkan branch on the mesa git but how do you
> > tell if your chipset is specifically supported?
>
> The driver emits a warning chirp if the chipset isn't fully supported,
> and will refuse to initialize on devices that are not supported at all:
>
> dmt:~/fedora/anvil/anvil% grep -A13 -- '->is_haswell'
> src/vulkan/anv_device.c
>if (device->info->is_haswell) {
>   fprintf(stderr, "WARNING: Haswell Vulkan support is incomplete\n");
>} else if (device->info->gen == 7 && !device->info->is_baytrail) {
>   fprintf(stderr, "WARNING: Ivy Bridge Vulkan support is
> incomplete\n");
>} else if (device->info->gen == 7 && device->info->is_baytrail) {
>   fprintf(stderr, "WARNING: Bay Trail Vulkan support is incomplete\n");
>} else if (device->info->gen >= 8) {
>   /* Broadwell, Cherryview, Skylake, Broxton, Kabylake is as fully
>* supported as anything */
>} else {
>   result = vk_errorf(VK_ERROR_INCOMPATIBLE_DRIVER,
>  "Vulkan not yet supported on %s", device->name);
>   goto fail;
>}
>
> As far as earlier chipsets are concerned, Ironlake and earlier are
> almost certainly never going to be supported. I don't know about Sandy
> Bridge, but I doubt it. If you're unsure which Intel GPU you have:
>
> % lspci -n -s 0:2
> 00:02.0 0300: 8086:0166 (rev 09)
>
> and then match the device ID (here 0166) to the architecture code name
> here:
>
> https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units


That got me close enough, mine is Ironlake.

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Mat Booth]

On 22 February 2016 at 10:54, Kamil Paral  wrote:

> > RWMJ> Is that new?
> >
> > Not really.  The change relating to what's in the buildroot was made
> > about nine months ago: https://fedorahosted.org/fpc/ticket/497
>
> I created my first COPR over this weekend. I worked according to:
> https://fedoraproject.org/wiki/How_to_create_an_RPM_package
> because that is linked heavily from other pages and also was the first
> google result for fedora rpm packaging.
>
> However, under
> https://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview
> it says:
> > BuildRequires: ... Some common packages can be omitted, such as gcc.
> and links to here:
> https://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires#Exceptions
>
> If that's no longer true, somebody who knows what he's doing should adjust
> that, because that wiki page is likely the most visible rpm tutorial for
> Fedora.
>

Wow, that "HOWTO" is a really old page -- not changed since being imported
from the old moin moin wiki. My feeling is that page should be deleted and
the "How to create an RPM package" page should be updated.

Here is the official guideline:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 --
basically, we just got out of the business of keeping track of what the
minimum buildroot contains.


-- 
Mat Booth
http://fedoraproject.org/get-fedora
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Minimizing the fedora docker base image footprint

[Courtney Pacheco]

Hi everyone,

I've spent some time trying to minimize the footprint of the Fedora 
docker base image. Overall, I managed to reduce its size by 39.9%.


A summary of the work I did can be found here: 
https://gist.github.com/iamcourtney/1a4af7c4289014f57080


If you're interested, you can find a more detailed version of the above 
work here: https://gist.github.com/iamcourtney/b8709ed897b7ecc9ac0f


I essentially looked at which packages were being installed to the base 
image and tried to determine which of those packages could be turned 
into weak dependencies and which of those packages we could possibly 
break up.


If possible, I'd like some feedback on the work I did. Comments and 
criticism are more than welcomed! I realize there may be some 
controversy in terms of what I chose to remove and what I chose to turn 
into weak dependencies, but I would like to hear your thoughts either way.


As a side note, I originally posted my preliminary results to 
atomic-devel list a few weeks ago, but I used some of the feedback I got 
to make improvements. I also was able to reduce glibc with the help of 
Carlos O'Donell.


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

Re: Proposal: spins-kickstarts workflow changes

[Adam Miller]

On Fri, Feb 19, 2016 at 1:37 PM, Kevin Fenzi  wrote:
> Greetings.
>
> I am sending this to the devel and spins lists. Feel free to forward to
> other places people who might be affected by it should see it.
>
> Some history:
>
> We setup the spin-kickstart project on fedorahosted a long time ago.
> At the start it was just the various spins and it's trac instance was
> used in the new spins workflow. Then, it was a handy place to put the
> dvd iso kickstart that releng made also. Then over time we added cloud
> and docker and everything else that used a kickstart to it. In the
> start we added some bugzilla components for the various spins for end
> user bugs, and used the trac for workflow things. Over time due to
> all the images there lots of people have been given commit access to
> the repo. Then the spins sig went quiet and we have sort of been limping
> along since then with trac tickets not getting to anyone who cares,
> etc.
>
> I'd like to propose the following plan of action:
>
> * Setup a new project at pagure.io called just kickstarts or
>   releng-kickstarts or something. (Bikeshed alert).
>
> * Setup tags for all the various groups that have kickstarts. ie,
>   'xfce' 'docker' 'cloud' 'atomic' 'workstation' etc. And get someone
>   from each of those groups to actually watch the tags or someone to CC
>   on who will actually look at those tagged issues.
>
> * Reduce the number of commiters a bunch and ask people to submit PR's
>   when they want a change. This will allow releng/qa to control changes
>   when in freeze. ie, we can require a freeze break and point to the
>   PR/bug with the exact change and merge it when it's approved.
>
> * Copy the git repo over to it from fedorahosted. Close that repo.
>
> * Mass close all the fedorahosted trac tickets and close trac to new
>   ones with a note to file new issues in pagure. ( 21 tickets
>   currently): https://fedorahosted.org/spin-kickstarts/report/1
>
> * Close the "LiveCD*" components in bugzilla to new bugs and close any
>   existing ones with a note to refile at pagure. (18 bugs currently):
>   
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=LiveCD=LiveCD%20-%20FEL=LiveCD%20-%20Games=LiveCD%20-%20KDE=LiveCD%20-%20LXDE=LiveCD%20-%20Xfce_id=4654195=Fedora_format=advanced
>
> * Adjust koji config to pull from pagure.io instead of fedorahosted.
>
> Thoughts? Additional steps? Better plans?

Seems like a logical plan that would offer us a lot of improvements
over the current workflow. Sounds great! +1

-AdamM

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

Re: [ANNOUNCE] Fedora support for Vulkan

[Adam Jackson]

On Wed, 2016-02-17 at 14:30 -0600, Richard Shaw wrote:
> I read the readme in the Vulkan branch on the mesa git but how do you
> tell if your chipset is specifically supported?

The driver emits a warning chirp if the chipset isn't fully supported,
and will refuse to initialize on devices that are not supported at all:

dmt:~/fedora/anvil/anvil% grep -A13 -- '->is_haswell' src/vulkan/anv_device.c
   if (device->info->is_haswell) {
  fprintf(stderr, "WARNING: Haswell Vulkan support is incomplete\n");
   } else if (device->info->gen == 7 && !device->info->is_baytrail) {
  fprintf(stderr, "WARNING: Ivy Bridge Vulkan support is incomplete\n");
   } else if (device->info->gen == 7 && device->info->is_baytrail) {
  fprintf(stderr, "WARNING: Bay Trail Vulkan support is incomplete\n");
   } else if (device->info->gen >= 8) {
  /* Broadwell, Cherryview, Skylake, Broxton, Kabylake is as fully
   * supported as anything */
   } else {
  result = vk_errorf(VK_ERROR_INCOMPATIBLE_DRIVER,
 "Vulkan not yet supported on %s", device->name);
  goto fail;
   }

As far as earlier chipsets are concerned, Ironlake and earlier are
almost certainly never going to be supported. I don't know about Sandy
Bridge, but I doubt it. If you're unsure which Intel GPU you have:

% lspci -n -s 0:2
00:02.0 0300: 8086:0166 (rev 09)

and then match the device ID (here 0166) to the architecture code name
here:

https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units

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

Re: kmods and Fedora

[Bastien Nocera]

- Original Message -
> Josh Boyer wrote:
> > If you are creating a cert to sign the out-of-tree modules and expect
> > it to be accepted by the kernel, it cannot be ephemeral.  A user would
> > need someway to import it into their kernel or have it passed from
> > grub.  The only way to do so is to have it embedded in shim or the
> > kernel during the build of those binaries.  I do not foresee Fedora
> > creating yet another persistent key to sign things with, which means
> > you would need another tool that can use the existing key in the
> > kernel builders.
> 
> That just proves that Restricted Boot and especially our implementation of
> it (requiring kernel modules to be signed) is a very bad thing.

How do you expect to be able to ensure that the kernel only loads "known good"
modules if you can insert random modules that might subvert SecureBoot and
all that it allows to secure?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1310479] perl-MooseX-App-1.34 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-MooseX-App-1.34-1.fc22 has been submitted as an update to Fedora 22.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-0cdd85b0db

--- Comment #4 from Fedora Update System  ---
perl-MooseX-App-1.34-1.fc23 has been submitted as an update to Fedora 23.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-ff70e06a4c

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

[Bug 1310479] perl-MooseX-App-1.34 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-MooseX-App-1.34-1.fc22 has been submitted as an update to Fedora 22.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-0cdd85b0db

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

psabata pushed to perl-MooseX-App (f22). "1.34 bump"

[notifications]

From d5ef0deac03fc4455f59261ba3fcd1a52364a337 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Mon, 22 Feb 2016 14:49:53 +0100
Subject: 1.34 bump

---
 .gitignore   | 1 +
 perl-MooseX-App.spec | 8 ++--
 sources  | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 25cd1df..c83d57d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /MooseX-App-1.31.tar.gz
 /MooseX-App-1.32.tar.gz
 /MooseX-App-1.33.tar.gz
+/MooseX-App-1.34.tar.gz
diff --git a/perl-MooseX-App.spec b/perl-MooseX-App.spec
index 22cba7e..38f50c6 100644
--- a/perl-MooseX-App.spec
+++ b/perl-MooseX-App.spec
@@ -1,12 +1,13 @@
 Name:   perl-MooseX-App
-Version:1.33
-Release:4%{?dist}
+Version:1.34
+Release:1%{?dist}
 Summary:Write user-friendly command line apps with even less suffering
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooseX-App/
 Source0:
http://www.cpan.org/authors/id/M/MA/MAROS/MooseX-App-%{version}.tar.gz
 BuildArch:  noarch
 # Build
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl(base)
 BuildRequires:  perl(Config)
@@ -89,6 +90,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Feb 22 2016 Petr Šabata  - 1.34-1
+- 1.34 bump
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
1.33-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
diff --git a/sources b/sources
index ce3beb2..48358b4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f52717ab0bc69c57c3d0d60deb5203df  MooseX-App-1.33.tar.gz
+97ac9c24967fefdbd6bf1311574b9301  MooseX-App-1.34.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-MooseX-App.git/commit/?h=f22=d5ef0deac03fc4455f59261ba3fcd1a52364a337
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata pushed to perl-MooseX-App (f22). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild"

[notifications]

From e9f94ae5d6c13c021ca4939642351802e79a454e Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Thu, 4 Feb 2016 14:46:38 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild

---
 perl-MooseX-App.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-MooseX-App.spec b/perl-MooseX-App.spec
index 8a33575..22cba7e 100644
--- a/perl-MooseX-App.spec
+++ b/perl-MooseX-App.spec
@@ -1,6 +1,6 @@
 Name:   perl-MooseX-App
 Version:1.33
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Write user-friendly command line apps with even less suffering
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooseX-App/
@@ -89,6 +89,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 04 2016 Fedora Release Engineering  - 
1.33-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.33-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-MooseX-App.git/commit/?h=f22=e9f94ae5d6c13c021ca4939642351802e79a454e
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata pushed to perl-MooseX-App (f22). "Perl 5.22 rebuild"

[notifications]

From ccc0c2eeb8d6927eeba51f34e80ced54224642f1 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 8 Jun 2015 20:22:09 +0200
Subject: Perl 5.22 rebuild

---
 perl-MooseX-App.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-MooseX-App.spec b/perl-MooseX-App.spec
index d362487..946422b 100644
--- a/perl-MooseX-App.spec
+++ b/perl-MooseX-App.spec
@@ -1,6 +1,6 @@
 Name:   perl-MooseX-App
 Version:1.33
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Write user-friendly command line apps with even less suffering
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooseX-App/
@@ -89,6 +89,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jun 08 2015 Jitka Plesnikova  - 1.33-2
+- Perl 5.22 rebuild
+
 * Tue Apr 21 2015 Petr Šabata  - 1.33-1
 - 1.33 bump
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-MooseX-App.git/commit/?h=f22=ccc0c2eeb8d6927eeba51f34e80ced54224642f1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata pushed to perl-MooseX-App (f22). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From 50574ef712b7357788343b821f337fa191a3e880 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 04:39:59 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-MooseX-App.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-MooseX-App.spec b/perl-MooseX-App.spec
index 946422b..8a33575 100644
--- a/perl-MooseX-App.spec
+++ b/perl-MooseX-App.spec
@@ -1,6 +1,6 @@
 Name:   perl-MooseX-App
 Version:1.33
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Write user-friendly command line apps with even less suffering
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooseX-App/
@@ -89,6 +89,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 1.33-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Mon Jun 08 2015 Jitka Plesnikova  - 1.33-2
 - Perl 5.22 rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-MooseX-App.git/commit/?h=f22=50574ef712b7357788343b821f337fa191a3e880
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata pushed to perl-MooseX-App (f23). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild"

[notifications]

From e9f94ae5d6c13c021ca4939642351802e79a454e Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Thu, 4 Feb 2016 14:46:38 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild

---
 perl-MooseX-App.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-MooseX-App.spec b/perl-MooseX-App.spec
index 8a33575..22cba7e 100644
--- a/perl-MooseX-App.spec
+++ b/perl-MooseX-App.spec
@@ -1,6 +1,6 @@
 Name:   perl-MooseX-App
 Version:1.33
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Write user-friendly command line apps with even less suffering
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooseX-App/
@@ -89,6 +89,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Feb 04 2016 Fedora Release Engineering  - 
1.33-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.33-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-MooseX-App.git/commit/?h=f23=e9f94ae5d6c13c021ca4939642351802e79a454e
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata pushed to perl-MooseX-App (master). "1.34 bump"

[notifications]

From d5ef0deac03fc4455f59261ba3fcd1a52364a337 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Mon, 22 Feb 2016 14:49:53 +0100
Subject: 1.34 bump

---
 .gitignore   | 1 +
 perl-MooseX-App.spec | 8 ++--
 sources  | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 25cd1df..c83d57d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /MooseX-App-1.31.tar.gz
 /MooseX-App-1.32.tar.gz
 /MooseX-App-1.33.tar.gz
+/MooseX-App-1.34.tar.gz
diff --git a/perl-MooseX-App.spec b/perl-MooseX-App.spec
index 22cba7e..38f50c6 100644
--- a/perl-MooseX-App.spec
+++ b/perl-MooseX-App.spec
@@ -1,12 +1,13 @@
 Name:   perl-MooseX-App
-Version:1.33
-Release:4%{?dist}
+Version:1.34
+Release:1%{?dist}
 Summary:Write user-friendly command line apps with even less suffering
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooseX-App/
 Source0:
http://www.cpan.org/authors/id/M/MA/MAROS/MooseX-App-%{version}.tar.gz
 BuildArch:  noarch
 # Build
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl(base)
 BuildRequires:  perl(Config)
@@ -89,6 +90,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Feb 22 2016 Petr Šabata  - 1.34-1
+- 1.34 bump
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
1.33-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
diff --git a/sources b/sources
index ce3beb2..48358b4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f52717ab0bc69c57c3d0d60deb5203df  MooseX-App-1.33.tar.gz
+97ac9c24967fefdbd6bf1311574b9301  MooseX-App-1.34.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-MooseX-App.git/commit/?h=master=d5ef0deac03fc4455f59261ba3fcd1a52364a337
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata pushed to perl-MooseX-App (f23). "1.34 bump"

[notifications]

From d5ef0deac03fc4455f59261ba3fcd1a52364a337 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Mon, 22 Feb 2016 14:49:53 +0100
Subject: 1.34 bump

---
 .gitignore   | 1 +
 perl-MooseX-App.spec | 8 ++--
 sources  | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 25cd1df..c83d57d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /MooseX-App-1.31.tar.gz
 /MooseX-App-1.32.tar.gz
 /MooseX-App-1.33.tar.gz
+/MooseX-App-1.34.tar.gz
diff --git a/perl-MooseX-App.spec b/perl-MooseX-App.spec
index 22cba7e..38f50c6 100644
--- a/perl-MooseX-App.spec
+++ b/perl-MooseX-App.spec
@@ -1,12 +1,13 @@
 Name:   perl-MooseX-App
-Version:1.33
-Release:4%{?dist}
+Version:1.34
+Release:1%{?dist}
 Summary:Write user-friendly command line apps with even less suffering
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooseX-App/
 Source0:
http://www.cpan.org/authors/id/M/MA/MAROS/MooseX-App-%{version}.tar.gz
 BuildArch:  noarch
 # Build
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl(base)
 BuildRequires:  perl(Config)
@@ -89,6 +90,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Feb 22 2016 Petr Šabata  - 1.34-1
+- 1.34 bump
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
1.33-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
diff --git a/sources b/sources
index ce3beb2..48358b4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f52717ab0bc69c57c3d0d60deb5203df  MooseX-App-1.33.tar.gz
+97ac9c24967fefdbd6bf1311574b9301  MooseX-App-1.34.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-MooseX-App.git/commit/?h=f23=d5ef0deac03fc4455f59261ba3fcd1a52364a337
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata uploaded MooseX-App-1.34.tar.gz for perl-MooseX-App

[notifications]

97ac9c24967fefdbd6bf1311574b9301  MooseX-App-1.34.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-MooseX-App/MooseX-App-1.34.tar.gz/md5/97ac9c24967fefdbd6bf1311574b9301/MooseX-App-1.34.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1310360] perl-CPAN-Perl-Releases-2.58 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-CPAN-Perl-Releases-2.5
   ||8-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2016-02-22 08:40:17



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

Re: Fedora mass rebuild 2016

[Richard Shaw]

I've pretty much addressed all my packages except for cqrlog which I guess
wasn't on the list since it will compile with gcc 5. Upstream has stated
they will address gcc 6 issues on the next release.

My other two packages that I could find in your list, smesh & OCE, have
both been addressed and built. Unfortunately with smesh the solution was to
re-enable gnu++98. Upstream was surprised to find out it even built with
gcc 5.

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1310646] perl-XML-XPath-1.31 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-XML-XPath-1.31-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2016-02-22 08:30:14



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

psabata pushed to perl-CPAN-Perl-Releases (master). "2.58 bump, updated for v5.23.8"

[notifications]

From c9bd08819643a380e16f6dc846399f89d8da3b44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Mon, 22 Feb 2016 14:30:02 +0100
Subject: 2.58 bump, updated for v5.23.8

---
 .gitignore   | 1 +
 perl-CPAN-Perl-Releases.spec | 7 +--
 sources  | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index fcc00c9..5325042 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,3 +37,4 @@
 /CPAN-Perl-Releases-2.52.tar.gz
 /CPAN-Perl-Releases-2.54.tar.gz
 /CPAN-Perl-Releases-2.56.tar.gz
+/CPAN-Perl-Releases-2.58.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index 4b5bdf8..ae708ad 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,6 +1,6 @@
 Name:   perl-CPAN-Perl-Releases
-Version:2.56
-Release:2%{?dist}
+Version:2.58
+Release:1%{?dist}
 Summary:Mapping Perl releases on CPAN to the location of the tarballs
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Feb 22 2016 Petr Šabata  - 2.58-1
+- 2.58 bump, updated for v5.23.8
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
2.56-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
diff --git a/sources b/sources
index 6dc668f..e326bea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6148133929e7dda340b7d2835f0dac0  CPAN-Perl-Releases-2.56.tar.gz
+92b48064be4727e40f72be5a7ac0c880  CPAN-Perl-Releases-2.58.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-CPAN-Perl-Releases.git/commit/?h=master=c9bd08819643a380e16f6dc846399f89d8da3b44
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata uploaded CPAN-Perl-Releases-2.58.tar.gz for perl-CPAN-Perl-Releases

[notifications]

92b48064be4727e40f72be5a7ac0c880  CPAN-Perl-Releases-2.58.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-CPAN-Perl-Releases/CPAN-Perl-Releases-2.58.tar.gz/md5/92b48064be4727e40f72be5a7ac0c880/CPAN-Perl-Releases-2.58.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1310475] perl-DateTime-Format-Strptime-1.64 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DateTime-Format-Strpti
   ||me-1.64-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2016-02-22 08:24:40



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

jplesnik pushed to perl-XML-XPath (master). "1.31 bump"

[notifications]

From f02eb71d4777d726fb0050a483c32206701773fd Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 22 Feb 2016 14:14:57 +0100
Subject: 1.31 bump

---
 .gitignore  | 1 +
 perl-XML-XPath.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 87ca91f..c0500f9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ XML-XPath-1.13.tar.gz
 /XML-XPath-1.28.tar.gz
 /XML-XPath-1.29.tar.gz
 /XML-XPath-1.30.tar.gz
+/XML-XPath-1.31.tar.gz
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index b126a05..f748e31 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,5 +1,5 @@
 Name:   perl-XML-XPath
-Version:1.30
+Version:1.31
 Release:1%{?dist}
 Summary:XPath parser and evaluator for Perl
 # XML/XPath.pm, XML/XPath/PerlSAX.pm, REAME: GPL+ or Artistic
@@ -75,6 +75,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Feb 22 2016 Jitka Plesnikova  - 1.31-1
+- 1.31 bump
+
 * Mon Feb 08 2016 Jitka Plesnikova  - 1.30-1
 - 1.30 bump
 
diff --git a/sources b/sources
index c1523e3..15f79d0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-913cecb3acec52ae622d1b4d75b0be90  XML-XPath-1.30.tar.gz
+de2afbc69c5baf9c8c3d4b53a51c4863  XML-XPath-1.31.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-XML-XPath.git/commit/?h=master=f02eb71d4777d726fb0050a483c32206701773fd
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org