Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Jeffrey Ollie]

On Fri, Jan 15, 2016 at 2:24 AM, Tomáš Smetana  wrote:

>
> I tend to use systemd-nspawn containers for building rpms. So for example,
> I
> have a Fedora 24 system and use its dnf to create e.g. Centos 7 container
> root and then build Centos rpms from within that container.  If I
> understand
> the change correctly, this is going to break since the Centos 7 rpm-build
> will not be able to read the database created by the Fedora 24 dnf.
>

I personally prefer to build my containers by starting with the raw files
that are used to build the base CentOS and Fedora Docker containers:

https://raw.githubusercontent.com/CentOS/sig-cloud-instance-images/CentOS-7.2.1511/docker/centos-7.2.1511-docker.tar.xz
https://download.fedoraproject.org/pub/fedora/linux/releases/23/Docker/x86_64/Fedora-Docker-Base-23-20151030.x86_64.tar.xz

The CentOS tarfile can be easily untarred into an empty directory.  The
Fedora tarball contains a layer.tar file that contains the raw filesystem.

I like doing it this way because I don't have to depend on the host yum/dnf
to set up the filesystem.  This would work too for non-rpm systems (or for
RHEL) as well but I haven't had the need so I haven't searched for the
appropriate media.

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

2016-01-18 @ 15:00 UTC - Fedora QA Devel Meeting

[Tim Flink]

# Fedora QA Devel Meeting
# Date: 2016-01-18
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net


The agenda looks much like last week for some reason. I'd like to
get the process of having disposable clients in production started
by the end of the week, though.

Please put announcements and information under the "Announcements and
Information" section of the wiki page for this meeting:

https://phab.qadevel.cloud.fedoraproject.org/w/meetings/20160118-fedoraqadevel/

Tim


Proposed Agenda
===

Announcements and Information
-
  - Please list announcements or significant information items below so
the meeting goes faster

Tasking
---
  - Does anyone need tasks to do?

Potential other topics
--
  - disposable clients release status
  - image building
  - docker and fedora atomic
  - examples for automation workshop?

Open Floor
--
  - TBD


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

Re: attempting to contact nonresponsive maintainer: ivazquez

[Jeffrey Ollie]

On Fri, Jan 15, 2016 at 4:20 PM, David Shea  wrote:

> Does anyone know how to contact Ignacio Vazquez-Abrams? I've been trying
> to contact him in regards to
> https://bugzilla.redhat.com/show_bug.cgi?id=1287273, and have also tried
> contacting him via the email address in bugzilla, and have not received any
> response.
>
> It looks like he has not been active in Fedora for a while. The
> fedora-active-user script returns this:
> Last login in FAS:
>ivazquez 2013-11-05
> Last action on koji:
>Thu, 17 Sep 2015 package list entry created: xmlcopyeditor in f23_Beta
> by ausil [still active]
> Last package update on bodhi:
> ERROR:active-user:'updates'
>
> The last koji action is obviously not correct, and points to another
> problem package: xmlcopyeditor was last updated by ivazquez in 2011, and
> since then has twice had to be updated or modified (like actually modified,
> not just rebulit) for build failures.
>

It's unfortunate, but this isn't the first time that Ignacio has gone AWOL:

https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00708.html
https://www.redhat.com/archives/fedora-extras-list/2006-August/msg00564.html

There's an identically named person that's active on Stack Exchange, but I
have no idea if it's actually the same person.

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

Re: dnf still is unuseable

[James Hogarth]

On 18 Jan 2016 06:33, "Igor Gnatenko"  wrote:
>
> I hope Heiko Adams and Reindl Harald should co-operate and write usable
and bug free package manager.
>
> Related to topic: Please prepare full list of bugs which you think
critical for you and write to each how to reproduce it.
>
> P.S. autoremove works here fine (fresh 23).
>

The autoremove reference might be the well known issue with packagekit, not
dnf, that is not marking packages as installed rather than dependencies.

The default dnf configuration is autoremove so that doesn't then know that
have been specifically installed rather than just unneeded dependencies of
something else and then helpfully tries to remove them...

Note this is a result of a packagekit bug not dnf.

On a side note it'd be nice if pk just called out to dnf so that they have
a common backend which would prevent behaviour like this and would result
in sharing a history database as well.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Igor Gnatenko]

I hope Heiko Adams and Reindl Harald should co-operate and write usable and
bug free package manager.

Related to topic: Please prepare full list of bugs which you think critical
for you and write to each how to reproduce it.

P.S. autoremove works here fine (fresh 23).

On Sun, Jan 17, 2016, 11:48 PM Heiko Adams  wrote:

> Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
> > may i suggest to forget that dnf ever existed and switch back to yum?
> >
> > ongoing problems in the core-task solve dependencies is not
> > production
> > ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and
> > "yum-deprecated" until DNF is useable and provides the same
> > capabilities
> > as yum/yum-utils
> >
> And please don't forget that the autoremove command is unusable at
> least since somewhere between Fedora 23 beta and final. That's
> absolutely unacceptable!
>
> So please fix your shit or remove the parts you can't fix! And until
> then de-deprecate yum until dnf is feature-complete, in a usable stage
> and you can guarantee dnf will stay in that stage for a long time.
>
> For me a new package manager has to be absolutely reliable and every
> feature has to work as expected before the new one can replace the
> current one!
> --
> Regards,
>
> Heiko Adams
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

-- 

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

[Bug 1298628] perl-DBD-SQLite-1.48-2.fc24 FTBFS: t/virtual_table/21_perldata_charinfo.t test fails with sqlite 3.10.0

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-DBD-SQLite-1.48-3.fc23 has been submitted as an update to Fedora 23.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-745ec448de

-- 
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: Updating perl-Spreadsheet-ParseExcel on EPEL 5

[Petr Pisar]

On Sun, Jan 17, 2016 at 06:13:39PM +0100, Robert Scheck wrote:
> I would like to update perl-Spreadsheet-ParseExcel on EPEL 5 to the version
> that EPEL 6 has. The requirement of perl(Crypt::RC4) gets satisfied with
> this update:
> 
>   https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-70c923f5af
> 
> EPEL 5 has currently 0.3200-2.el5, while EPEL 6 has 0.5900-1.el6.

I didn't checked the code, but a glimpse on the changelog shows:

0.53 August 24 2009
+ Refactored Workbook API and docs.

0.50 August 18 2009
+ Refactored Worksheet interface and documentation.
  Added 04_regression.t and 05_regression.t to test above changes.

0.43 January 7 2009
+ Renamed public methods RowRange(), ColRange() and Cell() to row_range(),
  col_range() and get_cell(). Old methods are still available.

0.33 2008.09.07
- Default format for formatted dates changed from 'm-d-yy' to '-mm-dd'

This sounds like the API changed and thus the two versions are not compatible
and thus the package cannot be upgraded.

-- Petr


signature.asc
Description: PGP signature
--
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: Appdata files template for Fedora Workstation

[Richard Hughes]

On 17 January 2016 at 09:44, Mattia Verga  wrote:
> Just curious: how can a metainfo.xml file be validated?
> I tried to use also appstream-util validate-relax, but it always fail:
> $ appstream-util validate-relax blenderplayer.metainfo.xml
> blenderplayer.metainfo.xml: failed to parse blenderplayer.metainfo.xml:
> Errore alla riga 2 carattere 2: Il documento deve iniziare con un elemento
> (es. )

Are you using non-breaking UTF-8 spaces perhaps? Have a look in vim
and see if it has lots of control chars showing. At the moment even
xmllint won't validate it.

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

Re: Appdata files template for Fedora Workstation

[Richard Hughes]

On 17 January 2016 at 19:51, Mattia Verga  wrote:
> Do also addons metainfo.xml files need to be validated in .spec file? I
> can't find anything about that on Packaging Guidelines.

Up to you; Kalev did try and get this validation automatic when
building rpms in koji. Kalev, did we stall on something, or is this
still the plan?

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

dnf still is unuseable

[Reindl Harald]

for localupdate i switched back to yum-deprecated long ago, but for 
ordinary kernel updates pretend unsolved deps is simply unacceptable


*no* i am not the only one - see karma comments for 4.3.3-300.fc23

https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
https://bugzilla.redhat.com/show_bug.cgi?id=1271676

may i suggest to forget that dnf ever existed and switch back to yum?

ongoing problems in the core-task solve dependencies is not production 
ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and 
"yum-deprecated" until DNF is useable and provides the same capabilities 
as yum/yum-utils




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

Re: dnf still is unuseable

[Pierre-Yves Chibon]

On Sun, Jan 17, 2016 at 11:48:23PM +0100, Heiko Adams wrote:
> Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
> > may i suggest to forget that dnf ever existed and switch back to yum?
> > 
> > ongoing problems in the core-task solve dependencies is not
> > production 
> > ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and 
> > "yum-deprecated" until DNF is useable and provides the same
> > capabilities 
> > as yum/yum-utils
> > 
> And please don't forget that the autoremove command is unusable at
> least since somewhere between Fedora 23 beta and final. That's
> absolutely unacceptable!
> 
> So please fix your shit or remove the parts you can't fix! And until
> then de-deprecate yum until dnf is feature-complete, in a usable stage
> and you can guarantee dnf will stay in that stage for a long time.

I would like to point out that this way of communicating is not welcome on this
list. If you have something to say, please say it but be respectful in your tone
and wording with everyone and everyone's work. We are all on the same boat and
shooting each other on the legs isn't going to help.
You may want to refresh your memory on our code of conduct:
https://getfedora.org/code-of-conduct


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

Re: dnf still is unuseable

[Reindl Harald]

Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:

On Sun, 17 Jan 2016 23:27:02 +0100
Reindl Harald  wrote:


for localupdate i switched back to yum-deprecated long ago, but for
ordinary kernel updates pretend unsolved deps is simply unacceptable

*no* i am not the only one - see karma comments for 4.3.3-300.fc23


But your comment doesn't explain what you are even doing.
What was the command and all output?


just "dnf upgrade" and DNF don't give any useful output, even not with 
"dnf -v upgrade" in the last case with *no local* packages



For localling installing new kernel versions, I use 'dnf install' and
it works just fine here.


"dnf update *.rpm" is the way which has to work


https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
https://bugzilla.redhat.com/show_bug.cgi?id=1271676


This seems like a matter of taste. If you want to keep yearly logs, set
your logrotate that way.


AFAIR the config files are not config noreplace"


may i suggest to forget that dnf ever existed and switch back to yum?


You can suggest it, but it's not going to happen, so I'd advise
relaxing some and working with dnf developers.


what more than report bugs months ago which can be reprodcued with 
nearly every "dnf update *.rpm" when there are sub-packages with 
inter-dependencies


better adivse the dnf evelopers to work together with reporters and just 
try "dnf update *.rpm" which worked in case of "yum update *.rpm" forever



I'd encourage you to re-read our code of conduct
( https://getfedora.org/code-of-conduct ) and try and be more
respectful in bugs and here. We are all trying to improve things, lets
work together


in case of such obvious bugs this *is* resepectful



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

Re: Appdata files template for Fedora Workstation

[Mattia Verga]

Il 17/01/2016 18:58, Richard Hughes ha scritto:
Are you using non-breaking UTF-8 spaces perhaps? Have a look in vim 
and see if it has lots of control chars showing. At the moment even 
xmllint won't validate it. Richard. 

Thanks, yes. That was the problem.
Using validate-relax now is ok.

Do also addons metainfo.xml files need to be validated in .spec file? I 
can't find anything about that on Packaging Guidelines.

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

Re: dnf still is unuseable

[Heiko Adams]

Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
> may i suggest to forget that dnf ever existed and switch back to yum?
> 
> ongoing problems in the core-task solve dependencies is not
> production 
> ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and 
> "yum-deprecated" until DNF is useable and provides the same
> capabilities 
> as yum/yum-utils
> 
And please don't forget that the autoremove command is unusable at
least since somewhere between Fedora 23 beta and final. That's
absolutely unacceptable!

So please fix your shit or remove the parts you can't fix! And until
then de-deprecate yum until dnf is feature-complete, in a usable stage
and you can guarantee dnf will stay in that stage for a long time.

For me a new package manager has to be absolutely reliable and every
feature has to work as expected before the new one can replace the
current one!
-- 
Regards,

Heiko Adams



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

Re: How to fix a package name with wrong capitalization?

[Mattia Verga]

kpmcore is now built in Rawhide.

Can I move ahead and retire KPMcore or should I wait some time before 
doing that?

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

Re: F24 Self Contained Change: Micro Bit

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 17, 2016 at 10:42:07PM +0530, Kushal Das wrote:
> On 16/01/16, Peter Robinson wrote:
> > On Fri, Jan 15, 2016 at 4:31 PM, Jan Kurik  wrote:
> > > = Proposed Self Contained Change: Micro Bit =
> > > https://fedoraproject.org/wiki/Changes/Micro_Bit
> > >
> > > Change owner(s):
> > > * Kushal Das 
> > >
> > > Enable the use of BBC Micro Bit on Fedora systems. Users will be able
> > > develop, and put in new code to their micro:bit devices using Fedora.
> > >
> > > == Detailed Description ==
> > > Micro Bit (or micro:bit) is an ARM-based embedded system designed by
> > > the BBC for use in computer education in the UK. It will be given to
> > > every class 7 students in UK. This change will make sure that they
> > > simply use Fedora to use their devices.
> > 
> > This is a very limited description of the intentions. The way it's
> > intended to be used in the UK is via a programming web interface
> > written by Microsoft (apparently it'll be open sourced!) which will be
> > the standard, but it'll also support micropython [1] and I suspect
> > some form of ardrino style programming, but being a Cortex-M series
> > processor is obviously not capable of running Fedora itself so I think
> > for this to be a feature you need to actually specify how it's
> > actually going to be supported and what tools rather than a handy wavy
> > "support" outline.
> My mistake of not putting in all the details on time. It comes down to
> packaging uFlash, the tool which can be used to flash the device with
> Python scripts, and MicroPython runtime.
How does this relate to https://bugzilla.redhat.com/show_bug.cgi?id=1113915?

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

Re: dnf still is unuseable

[Kevin Fenzi]

On Sun, 17 Jan 2016 23:27:02 +0100
Reindl Harald  wrote:

> for localupdate i switched back to yum-deprecated long ago, but for 
> ordinary kernel updates pretend unsolved deps is simply unacceptable
> 
> *no* i am not the only one - see karma comments for 4.3.3-300.fc23

But your comment doesn't explain what you are even doing. 
What was the command and all output? 

For localling installing new kernel versions, I use 'dnf install' and
it works just fine here. 

> https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
> https://bugzilla.redhat.com/show_bug.cgi?id=1271676

This seems like a matter of taste. If you want to keep yearly logs, set
your logrotate that way. 

> may i suggest to forget that dnf ever existed and switch back to yum?

You can suggest it, but it's not going to happen, so I'd advise
relaxing some and working with dnf developers. 

I'd encourage you to re-read our code of conduct 
( https://getfedora.org/code-of-conduct ) and try and be more
respectful in bugs and here. We are all trying to improve things, lets
work together. 

kevin


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

[Bug 1285437] Upgrade perl-Spreadsheet-XLSX to 0.15

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Spreadsheet-XLSX-0.15-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 1285437] Upgrade perl-Spreadsheet-XLSX to 0.15

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Spreadsheet-XLSX-0.15- |perl-Spreadsheet-XLSX-0.15-
   |1.fc23  |1.fc23
   ||perl-Spreadsheet-XLSX-0.15-
   ||1.fc22



-- 
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 1299286] New: perl-Test-Strict-0.36 is available

[bugzilla]

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

Bug ID: 1299286
   Summary: perl-Test-Strict-0.36 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Strict
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Latest upstream release: 0.36
Current version/release in rawhide: 0.34-1.fc24
URL: http://search.cpan.org/dist/Test-Strict/

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 1299283] New: perl-podlators-4.05 is available

[bugzilla]

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

Bug ID: 1299283
   Summary: perl-podlators-4.05 is available
   Product: Fedora
   Version: rawhide
 Component: perl-podlators
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 4.05
Current version/release in rawhide: 4.04-1.fc24
URL: http://search.cpan.org/dist/podlators/

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 1299283] perl-podlators-4.05 is available

[bugzilla]

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



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

-- 
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 1299287] New: perl-System-Command-1.117 is available

[bugzilla]

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

Bug ID: 1299287
   Summary: perl-System-Command-1.117 is available
   Product: Fedora
   Version: rawhide
 Component: perl-System-Command
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
psab...@redhat.com



Latest upstream release: 1.117
Current version/release in rawhide: 1.116-1.fc24
URL: http://search.cpan.org/dist/System-Command/

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

Re: dnf still is unuseable

[Neal Gompa]

On Sun, Jan 17, 2016 at 6:01 PM, Reindl Harald  wrote:
>
>
> Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:
>>
>> I'd encourage you to re-read our code of conduct
>> ( https://getfedora.org/code-of-conduct ) and try and be more
>> respectful in bugs and here. We are all trying to improve things, lets
>> work together
>
>
> in case of such obvious bugs this *is* resepectful
>

No, it is not. Your tone and method of communication is highly
antagonistic in nature on both mailing lists and in bugs you've filed
in the Red Hat Bugzilla, and it's very hard to be willing to even
consider issues you experience when you continue to maintain such a
tone while trying to seek assistance or trying to get something fixed.

Fedora is a large community and all of us love using and developing
the distribution. Passions may get a bit hot, but we should always be
respectful and constructive. We also don't live in isolation, and work
with other communities to develop excellent solutions that everyone
can use, including the many projects and products that are downstream
from Fedora.

And if you really want something fixed that badly, talk to the DNF
development team about contributing to fix particular issues, or even
work with them one-on-one to help them fix it properly. Suggesting to
throw out DNF and re-instate Yum is not helpful and makes it really
easy to ignore you.


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

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 00:48 schrieb Kevin Fenzi:

On Mon, 18 Jan 2016 00:01:13 +0100
Reindl Harald  wrote:

...snip...


"dnf update *.rpm" is the way which has to work


Why? It works fine as a install. It's installing a new kernel, since
kernels can have many versions installed at a time it makes more sense
for it to be a install than an upgrade (which would imply that the old
version would be removed).


why?

because you don't type "dnf install kernel" instead "dnf upgrade" and 
"kernel-headers" *is never installed* in multiple versions



https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
https://bugzilla.redhat.com/show_bug.cgi?id=1271676


This seems like a matter of taste. If you want to keep yearly logs,
set your logrotate that way.


AFAIR the config files are not config noreplace"


The spec seems to have:
%config(noreplace) %{_sysconfdir}/logrotate.d/%{name}


well, give it a try, but for many years you had yum-logs for the 
complete year rotated once on the begin of a new year - package updates 
are not that often and don#t flood logs like some systemd things




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

[Bug 1299283] perl-podlators-4.05 is available

[bugzilla]

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



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

-- 
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 5 updates-testing report

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 820  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2013-11893   
libguestfs-1.20.12-1.el5
 584  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-1626   
puppet-2.7.26-1.el5
 434  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
  77  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
  49  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-d1309b0eb2   
libsndfile-1.0.17-8.el5
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-01879cfdd3   
lighttpd-1.4.39-1.el5
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7750a31388   
openvpn-2.3.10-1.el5
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-512e1f2343   
wordpress-4.4.1-1.el5
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7191918aa5   
openssl101e-1.0.1e-6.el5
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d4bdacdc4a   
prosody-0.9.9-2.el5
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-43d6b4225b   
mbedtls-2.2.1-1.el5


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

emacs-yaml-mode-0.0.12-2.el5
pcc-1.1.0-1.1.20160115cvs.el5

Details about builds:



 emacs-yaml-mode-0.0.12-2.el5 (FEDORA-EPEL-2016-1b94744ebc)
 Major mode to edit YAML files for emacs

Update Information:

emacs-yaml-mode for el5

References:

  [ 1 ] Bug #1247442 - Review Request: emacs-yaml-mode - major mode to edit 
YAML file for emacs
https://bugzilla.redhat.com/show_bug.cgi?id=1247442




 pcc-1.1.0-1.1.20160115cvs.el5 (FEDORA-EPEL-2016-f89489d293)
 The Portable C Compiler

Update Information:

Update to latest snapshot.    Update to newest cvs snapshot.

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

Re: dnf still is unuseable

[Johnny Robeson]

On Mon, 2016-01-18 at 00:00 +0100, Pierre-Yves Chibon wrote:
> On Sun, Jan 17, 2016 at 11:48:23PM +0100, Heiko Adams wrote:
> > Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
> > > may i suggest to forget that dnf ever existed and switch back to
> > > yum?
> > > 
> > > ongoing problems in the core-task solve dependencies is not
> > > production 
> > > ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup"
> > > and 
> > > "yum-deprecated" until DNF is useable and provides the same
> > > capabilities 
> > > as yum/yum-utils
> > > 
> > And please don't forget that the autoremove command is unusable at
> > least since somewhere between Fedora 23 beta and final. That's
> > absolutely unacceptable!
> > 
> > So please fix your shit or remove the parts you can't fix! And
> > until
> > then de-deprecate yum until dnf is feature-complete, in a usable
> > stage
> > and you can guarantee dnf will stay in that stage for a long time.
> 
> I would like to point out that this way of communicating is not
> welcome on this
> list. If you have something to say, please say it but be respectful
> in your tone
> and wording with everyone and everyone's work. We are all on the same
> boat and
> shooting each other on the legs isn't going to help.
> You may want to refresh your memory on our code of conduct:
> https://getfedora.org/code-of-conduct
> 
> 
> Pierre
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org

agreed. This is a major reason I choose not to participate on Fedora
lists. I can't trust that even the limited code of conduct that exists
will even be enforced.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Kevin Fenzi]

On Mon, 18 Jan 2016 00:01:13 +0100
Reindl Harald  wrote:

...snip...
 
> "dnf update *.rpm" is the way which has to work

Why? It works fine as a install. It's installing a new kernel, since
kernels can have many versions installed at a time it makes more sense
for it to be a install than an upgrade (which would imply that the old
version would be removed). 

> 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1271676  
> >
> > This seems like a matter of taste. If you want to keep yearly logs,
> > set your logrotate that way.  
> 
> AFAIR the config files are not config noreplace"

The spec seems to have:
%config(noreplace) %{_sysconfdir}/logrotate.d/%{name}

kevin



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

Re: dnf still is unuseable

[Heiko Adams]

Am Montag, den 18.01.2016, 00:00 +0100 schrieb Pierre-Yves Chibon:
> On Sun, Jan 17, 2016 at 11:48:23PM +0100, Heiko Adams wrote:
> > Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
> > > may i suggest to forget that dnf ever existed and switch back to
> > > yum?
> > > 
> > > ongoing problems in the core-task solve dependencies is not
> > > production 
> > > ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup"
> > > and 
> > > "yum-deprecated" until DNF is useable and provides the same
> > > capabilities 
> > > as yum/yum-utils
> > > 
> > And please don't forget that the autoremove command is unusable at
> > least since somewhere between Fedora 23 beta and final. That's
> > absolutely unacceptable!
> > 
> > So please fix your shit or remove the parts you can't fix! And
> > until
> > then de-deprecate yum until dnf is feature-complete, in a usable
> > stage
> > and you can guarantee dnf will stay in that stage for a long time.
> 
> I would like to point out that this way of communicating is not
> welcome on this
> list. If you have something to say, please say it but be respectful
> in your tone
> and wording with everyone and everyone's work. We are all on the same
> boat and
> shooting each other on the legs isn't going to help.
> You may want to refresh your memory on our code of conduct:
> https://getfedora.org/code-of-conduct
> 
I apologize for that mail and I'll try to say it more respectful this
time:

The first time i noticed the autoerase feature of dnf seems to be
broken was somewhere between Fedora 23 beta and final. But it seems to
be broken since Feb 2015 [1], which is IMHO unacceptable since a
default package manager and all of its features have to work absolutely
reliable. And in my case autoerase want's to remove  half of my GNOME
desktop which seems to be reliable a very bad joke.

But IMHO this reliability seems to be not the case ATM so I'd prefer to
rollback the switch from yum to dnf at least until the broken features
are fixed and dnf works absolutely reliable (again).
And the next time it would be nice if switching the package manager
would only affect fresh installations.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1190141
-- 
Regards,

Heiko Adams



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

Re: dnf still is unuseable

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 18, 2016 at 12:55:54AM +0100, Heiko Adams wrote:
> But it seems to be broken since Feb 2015, which is IMHO unacceptable
> since a default package manager and all of its features have to work
> absolutely reliable.

When was the last time you saw a program bigger then /bin/true that was
"absolutely reliable"? Your implicit premise that yum was bug free
is completely bogus, just look for yum bugs in bugzilla [1].

It seems that with dnf we are currently in the phase of fine-tuning
user interaction. The resolver works nicely, there is a growing system
of plugins based on a stable API, the codebase was ported to the
current version of python, speed is decent most of the time... There
*are* things to fix, but calling for the return of yum is a complete
waste of the time of everbody on this list.

Zbyszek

[1] 
https://bugzilla.redhat.com/buglist.cgi?classification=Fedora=yum=Fedora_format=advanced
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Reindl Harald]

Am 18.01.2016 um 00:08 schrieb Neal Gompa:

On Sun, Jan 17, 2016 at 6:01 PM, Reindl Harald  wrote:



Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:


I'd encourage you to re-read our code of conduct
( https://getfedora.org/code-of-conduct ) and try and be more
respectful in bugs and here. We are all trying to improve things, lets
work together



in case of such obvious bugs this *is* resepectful



No, it is not. Your tone and method of communication is highly
antagonistic in nature on both mailing lists and in bugs you've filed
in the Red Hat Bugzilla, and it's very hard to be willing to even
consider issues you experience when you continue to maintain such a
tone while trying to seek assistance or trying to get something fixed.


and replace a perfect working package manager is respectful to users?


Fedora is a large community and all of us love using and developing
the distribution. Passions may get a bit hot, but we should always be
respectful and constructive. We also don't live in isolation, and work
with other communities to develop excellent solutions that everyone
can use, including the many projects and products that are downstream
from Fedora.


dnf is far away from "excellent solutions"

just the fact that there are no useful outputs about the nature of a 
(mostly pretended) dependency problem disqualifies it while 
"yum-deprecated" shows you even soname-conflicts in a clear way


the case where i had enough again and wrote the mail above was a "dnf -v 
upgrade" with no useful output and "yum-deprecated upgrade" just worked 
fine as all the years ago - so *there is no* dependency problem



And if you really want something fixed that badly, talk to the DNF
development team about contributing to fix particular issues, or even
work with them one-on-one to help them fix it properly. Suggesting to
throw out DNF and re-instate Yum is not helpful and makes it really
easy to ignore you.


it would be enough to *remove* all that deprecation warnings for 
"yum-deprecated" and "package-cleanup" so that i could set an alias back 
to yum-deprecated




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

Re: dnf still is unuseable

[Kevin Fenzi]

On Mon, 18 Jan 2016 00:53:00 +0100
Reindl Harald  wrote:

...snip...

> 
> why?
> 
> because you don't type "dnf install kernel" instead "dnf upgrade" and 
> "kernel-headers" *is never installed* in multiple versions

Sure, you want upgrade/update to update installonly pkgs too. 

In any case 'dnf install' will work for locally downloaded kernel rpms,
which was your case right? so it should work as a workaround at least
for now, no?

kevin





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

Re: Appdata files template for Fedora Workstation

[Mattia Verga]

Just curious: how can a metainfo.xml file be validated?
I tried to use also appstream-util validate-relax, but it always fail:
$ appstream-util validate-relax blenderplayer.metainfo.xml
blenderplayer.metainfo.xml: failed to parse blenderplayer.metainfo.xml: 
Errore alla riga 2 carattere 2: Il documento deve iniziare con un 
elemento (es. )


Il 16/01/2016 23:36, Luya Tshimbalanga ha scritto:

Based on the Workstation wiki related to appdata addons[1], I created
each metainfo.xml for the missing addons including for some applications
like Blender.[2]

Nearly all on them are associated with the related applications and it
is a matter of filling the missing informations. Each metainfo.xml is
validated by appstream-lib so downstream can submit the completed addon
appdata to upstream.

For more details, please read
http://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html


P.S: I realized I forgot to add .desktop extension but the guideline
will suffice.

Reference:
---
[1] https://fedoraproject.org/wiki/Workstation/AddonAppdata
[2] https://luya.fedorapeople.org/appdata/


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

[EPEL-devel] Re: MPI Fortran compiler detection failed on EPEL7

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/17/2016 12:08 AM, Orion Poplawski wrote:
> On 01/16/2016 03:44 PM, Antonio Trande wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Hello everybody,
>> 
>> OpenMPI Fortran compiler detection fails during 
>> Sundials-OpenMPI(1.10.0) rebuilds on EPEL7:
>> 
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=12582324
>> 
>> Unexpectedly, cmake's Fortran compiler test works on ppc64le
>> arch, but fails on x86_64.
>> 
>>> 
>>> -- Looking for MPI Fortran compiler script 
>>> /usr/lib64/openmpi/bin/mpifort
>> 
>>> -- Trying to compile and link a simple MPI Fortran program... 
>>> FAILED
>>> 
>> 
>> This does not happen on Fedora (OpenMPI-1.8.8) and EPEL6 
>> (OpenMPI-1.8.1);  see
>> 
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=12581901
>> (rawhide) 
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=12582140
>> (epel6)
>> 
>> Am I missing something? Any comment/idea?
> 
> Really impossible to tell without the cmake output logs,
> specifically CMakeFiles/CMakeError.log.
> 

Hardened flags break cmake's MPI Fortran compiler test; I had to add

%if 0%{?rhel} && 0%{?rhel} > 6
%undefine _hardened_build
%endif

Best regards.
- -- 
Antonio Trande

mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWm3r3AAoJEF5tK7VWXmU8jawIAIB4t9VdHEx9b1PW8Avx37YX
rhUGlrrpCgRiM/R7auwxZi0VHySLB2jEO9LcGd72VkJzEB5L8F4q2QE67Q46HOzA
LCaVXtPKukAfU2JmJz/9OFulKuse4C4hr+PR64aZIgttelieTbngO1Cu9aIYNTDT
rXNZRfO90TaRt8PxqBOki0g5mLIn9bu46gm5mF54wSkuK55qyK3eggOyTAgAWAKH
MkDwniEnjKXZl/AnTCUQ9qNrPuog5H7PTeYb4uJc/3v19Qry2Sy0WUbHUIKhYoph
A//SnDaEsRxjtUHJv0rX9he/63lCFcW/ZaxtkZXDgpiyC75tjNwwWyRSrks7c88=
=Bcwi
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

rawhide report: 20160117 changes

[Fedora Rawhide Report]

Compose started at Sun Jan 17 05:15:02 UTC 2016
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[atomic-reactor]
python-atomic-reactor-1.6.1-1.fc24.noarch requires 
python-docker-scripts >= 0:0.4.4
python3-atomic-reactor-1.6.1-1.fc24.noarch requires 
python3-docker-scripts >= 0:0.4.4
[avogadro]
avogadro-libs-1.1.1-15.fc24.i686 requires libGLEW.so.1.10
[bes]
bes-3.14.0-8.fc24.i686 requires libdap.so.17
[couchdb]
couchdb-1.6.1-7.fc24.i686 requires erlang(erl_nif_version) = 0:2.7
couchdb-1.6.1-7.fc24.i686 requires erlang(erl_drv_version) = 0:3.1
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
[ejabberd]
ejabberd-14.07-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.7
ejabberd-14.07-6.fc22.i686 requires erlang(erl_drv_version) = 0:3.1
[erlang-basho_metrics]
erlang-basho_metrics-1.0.0-15.fc23.i686 requires 
erlang(erl_nif_version) = 0:2.7
[erlang-bitcask]
erlang-bitcask-1.6.3-6.fc22.i686 requires erlang(erl_nif_version) = 
0:2.7
[erlang-cl]
erlang-cl-1.2.1-7.fc23.i686 requires erlang(erl_nif_version) = 0:2.7
[erlang-ebloom]
erlang-ebloom-2.0.0-2.fc23.i686 requires erlang(erl_nif_version) = 0:2.7
[erlang-eleveldb]
erlang-eleveldb-1.3.2-7.fc22.i686 requires erlang(erl_nif_version) = 
0:2.7
[erlang-emmap]
erlang-emmap-0-0.12.git05ae1bb.fc23.i686 requires 
erlang(erl_nif_version) = 0:2.7
[erlang-erlsyslog]
erlang-erlsyslog-0.6.2-9.fc23.i686 requires erlang(erl_drv_version) = 
0:3.1
[erlang-esasl]
erlang-esasl-0.1-18.20120116git665cc80.fc23.i686 requires 
erlang(erl_drv_version) = 0:3.1
[erlang-esdl]
erlang-esdl-1.3.1-8.fc23.i686 requires erlang(erl_drv_version) = 0:3.1
[erlang-js]
erlang-js-1.3.0-1.fc22.i686 requires erlang(erl_drv_version) = 0:3.1
[erlang-sd_notify]
erlang-sd_notify-0.1-6.fc23.i686 requires erlang(erl_nif_version) = 
0:2.7
[erlang-skerl]
erlang-skerl-1.1.0-11.fc23.i686 requires erlang(erl_nif_version) = 0:2.7
[erlang-snappy]
erlang-snappy-1.0.3-0.11.git80db168.fc23.i686 requires 
erlang(erl_nif_version) = 0:2.7
[fawkes]
fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so
fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
[gcc-python-plugin]
gcc-python2-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python2-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python3-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python3-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 

pghmcfc uploaded Software-License-0.103011.tar.gz for perl-Software-License

[notifications]

53d79b47a33cb8e5f656cb0f9d6d6817  Software-License-0.103011.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Software-License/Software-License-0.103011.tar.gz/md5/53d79b47a33cb8e5f656cb0f9d6d6817/Software-License-0.103011.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

pghmcfc pushed to perl-Software-License (master). "Update to 0.103011 (..more)"

[notifications]

From 1d52ca601c07dabb6d0b92eee3120535124b2c06 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Sun, 17 Jan 2016 14:37:34 +
Subject: Update to 0.103011

- New upstream release 0.103011
  - Do not load Sub::Install, since it isn't used!
  - Eliminate superfluous FULL STOP characters (".")
- Update patch for building with old Test::More versions
- Classify buildreqs by usage
- Use %license where possible
---
 Software-License-0.103010-old-Test::More.patch | 90 --
 Software-License-0.103011-old-Test::More.patch | 89 +
 perl-Software-License.spec | 42 
 sources|  2 +-
 4 files changed, 121 insertions(+), 102 deletions(-)
 delete mode 100644 Software-License-0.103010-old-Test::More.patch
 create mode 100644 Software-License-0.103011-old-Test::More.patch

diff --git a/Software-License-0.103010-old-Test::More.patch 
b/Software-License-0.103010-old-Test::More.patch
deleted file mode 100644
index 0bc92e1..000
--- a/Software-License-0.103010-old-Test::More.patch
+++ /dev/null
@@ -1,90 +0,0 @@
 t/000-report-versions-tiny.t
-+++ t/000-report-versions-tiny.t
-@@ -1,12 +1,8 @@
- use strict;
- use warnings;
--use Test::More 0.88;
--# This is a relatively nice way to avoid Test::NoWarnings breaking our
--# expectations by adding extra tests, without using no_plan.  It also helps
--# avoid any other test module that feels introducing random tests, or even
--# test plans, is a nice idea.
-+use Test::More tests => 1;
- our $success = 0;
--END { $success && done_testing; }
-+END { $success; }
- 
- # List our own version used to generate this
- my $v = "\nGenerated by Dist::Zilla::Plugin::ReportVersions::Tiny v1.10\n";
 t/custom.t
-+++ t/custom.t
-@@ -2,7 +2,7 @@
- use strict;
- use warnings;
- 
--use Test::More;
-+use Test::More tests => 8;
- 
- use Software::License::Custom;
- 
-@@ -40,5 +40,3 @@ Well... this is only some sample text. I
- 
- Yes, spanning more lines and more paragraphs.
- END_OF_FULLTEXT
--
--done_testing;
 t/guess_meta_license.t
-+++ t/guess_meta_license.t
-@@ -64,4 +64,3 @@ is_deeply(
-   [ ],
- );
- 
--done_testing;
 t/meta-names.t
-+++ t/meta-names.t
-@@ -2,13 +2,16 @@
- use strict;
- use warnings;
- 
--use Test::More 0.88;
-+use Test::More;
- 
- my @files = ;
- 
-+plan tests => scalar @files;
-+
- for my $module (@files) {
-   # It's retired.  Dunno if it's okay to be open_source.  Punt!
--  next if $module =~ /Sun.pm$/;
-+  SKIP: {
-+  skip "Dunno if it's okay for Sun.pm to be open_source", 1 if $module =~ 
/Sun.pm$/;
- 
-   my $pkg = $module;
-   $pkg =~ s{^lib/}{};
-@@ -18,6 +21,5 @@ for my $module (@files) {
-   eval "require $pkg; 1";
- 
-   ok(defined $pkg->meta_name, "$pkg provide meta_name");
-+  }
- }
--
--done_testing;
 xt/release/changes_has_content.t
-+++ xt/release/changes_has_content.t
-@@ -2,7 +2,7 @@
- 
- use Test::More tests => 2;
- 
--note 'Checking Changes';
-+diag 'Checking Changes';
- my $changes_file = 'Changes';
- my $newver = '0.103010';
- my $trial_token = '-TRIAL';
-@@ -14,8 +14,6 @@ SKIP: {
- ok(_get_changes($newver), "$changes_file has content for $newver");
- }
- 
--done_testing;
--
- # _get_changes copied and adapted from Dist::Zilla::Plugin::Git::Commit
- # by Jerome Quelin
- sub _get_changes
diff --git a/Software-License-0.103011-old-Test::More.patch 
b/Software-License-0.103011-old-Test::More.patch
new file mode 100644
index 000..12c1050
--- /dev/null
+++ b/Software-License-0.103011-old-Test::More.patch
@@ -0,0 +1,89 @@
+--- t/custom.t
 t/custom.t
+@@ -2,7 +2,7 @@
+ use strict;
+ use warnings;
+ 
+-use Test::More;
++use Test::More tests => 8;
+ 
+ use Software::License::Custom;
+ 
+@@ -40,5 +40,3 @@ Well... this is only some sample text. I
+ 
+ Yes, spanning more lines and more paragraphs.
+ END_OF_FULLTEXT
+-
+-done_testing;
+--- t/guess_meta_license.t
 t/guess_meta_license.t
+@@ -64,4 +64,3 @@ is_deeply(
+   [ ],
+ );
+ 
+-done_testing;
+--- t/meta-names.t
 t/meta-names.t
+@@ -2,13 +2,16 @@
+ use strict;
+ use warnings;
+ 
+-use Test::More 0.88;
++use Test::More;
+ 
+ my @files = ;
+ 
++plan tests => scalar @files;
++
+ for my $module (@files) {
+   # It's retired.  Dunno if it's okay to be open_source.  Punt!
+-  next if $module =~ /Sun.pm$/;
++  SKIP: {
++  skip "Dunno if it's okay for Sun.pm to be open_source", 1 if $module =~ 
/Sun.pm$/;
+ 
+   my $pkg = $module;
+   $pkg =~ s{^lib/}{};
+@@ -18,6 +21,5 @@ for my $module (@files) {
+   eval "require $pkg; 1";
+ 
+   ok(defined $pkg->meta_name, "$pkg provide meta_name");
++  }
+ }
+-
+-done_testing;
+--- t/two-dots.t
 t/two-dots.t
+@@ -32,6 +32,8 @@ my @licenses = qw(
+ Zlib
+ );
+ 
++plan tests => 3 * scalar(@licenses);
++
+ for my $l (@licenses) {
+ my $class = 'Software::License::' . $l;
+ require_ok($class);
+@@ -48,4 +50,3 @@ for my $l (@licenses) {
+ );
+ }
+ 
+-done_testing;
+--- 

pghmcfc pushed to perl-Software-License (perl-Software-License-0.103011-1.fc24). "Update to 0.103011 (..more)"

[notifications]

From 1d52ca601c07dabb6d0b92eee3120535124b2c06 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Sun, 17 Jan 2016 14:37:34 +
Subject: Update to 0.103011

- New upstream release 0.103011
  - Do not load Sub::Install, since it isn't used!
  - Eliminate superfluous FULL STOP characters (".")
- Update patch for building with old Test::More versions
- Classify buildreqs by usage
- Use %license where possible
---
 Software-License-0.103010-old-Test::More.patch | 90 --
 Software-License-0.103011-old-Test::More.patch | 89 +
 perl-Software-License.spec | 42 
 sources|  2 +-
 4 files changed, 121 insertions(+), 102 deletions(-)
 delete mode 100644 Software-License-0.103010-old-Test::More.patch
 create mode 100644 Software-License-0.103011-old-Test::More.patch

diff --git a/Software-License-0.103010-old-Test::More.patch 
b/Software-License-0.103010-old-Test::More.patch
deleted file mode 100644
index 0bc92e1..000
--- a/Software-License-0.103010-old-Test::More.patch
+++ /dev/null
@@ -1,90 +0,0 @@
 t/000-report-versions-tiny.t
-+++ t/000-report-versions-tiny.t
-@@ -1,12 +1,8 @@
- use strict;
- use warnings;
--use Test::More 0.88;
--# This is a relatively nice way to avoid Test::NoWarnings breaking our
--# expectations by adding extra tests, without using no_plan.  It also helps
--# avoid any other test module that feels introducing random tests, or even
--# test plans, is a nice idea.
-+use Test::More tests => 1;
- our $success = 0;
--END { $success && done_testing; }
-+END { $success; }
- 
- # List our own version used to generate this
- my $v = "\nGenerated by Dist::Zilla::Plugin::ReportVersions::Tiny v1.10\n";
 t/custom.t
-+++ t/custom.t
-@@ -2,7 +2,7 @@
- use strict;
- use warnings;
- 
--use Test::More;
-+use Test::More tests => 8;
- 
- use Software::License::Custom;
- 
-@@ -40,5 +40,3 @@ Well... this is only some sample text. I
- 
- Yes, spanning more lines and more paragraphs.
- END_OF_FULLTEXT
--
--done_testing;
 t/guess_meta_license.t
-+++ t/guess_meta_license.t
-@@ -64,4 +64,3 @@ is_deeply(
-   [ ],
- );
- 
--done_testing;
 t/meta-names.t
-+++ t/meta-names.t
-@@ -2,13 +2,16 @@
- use strict;
- use warnings;
- 
--use Test::More 0.88;
-+use Test::More;
- 
- my @files = ;
- 
-+plan tests => scalar @files;
-+
- for my $module (@files) {
-   # It's retired.  Dunno if it's okay to be open_source.  Punt!
--  next if $module =~ /Sun.pm$/;
-+  SKIP: {
-+  skip "Dunno if it's okay for Sun.pm to be open_source", 1 if $module =~ 
/Sun.pm$/;
- 
-   my $pkg = $module;
-   $pkg =~ s{^lib/}{};
-@@ -18,6 +21,5 @@ for my $module (@files) {
-   eval "require $pkg; 1";
- 
-   ok(defined $pkg->meta_name, "$pkg provide meta_name");
-+  }
- }
--
--done_testing;
 xt/release/changes_has_content.t
-+++ xt/release/changes_has_content.t
-@@ -2,7 +2,7 @@
- 
- use Test::More tests => 2;
- 
--note 'Checking Changes';
-+diag 'Checking Changes';
- my $changes_file = 'Changes';
- my $newver = '0.103010';
- my $trial_token = '-TRIAL';
-@@ -14,8 +14,6 @@ SKIP: {
- ok(_get_changes($newver), "$changes_file has content for $newver");
- }
- 
--done_testing;
--
- # _get_changes copied and adapted from Dist::Zilla::Plugin::Git::Commit
- # by Jerome Quelin
- sub _get_changes
diff --git a/Software-License-0.103011-old-Test::More.patch 
b/Software-License-0.103011-old-Test::More.patch
new file mode 100644
index 000..12c1050
--- /dev/null
+++ b/Software-License-0.103011-old-Test::More.patch
@@ -0,0 +1,89 @@
+--- t/custom.t
 t/custom.t
+@@ -2,7 +2,7 @@
+ use strict;
+ use warnings;
+ 
+-use Test::More;
++use Test::More tests => 8;
+ 
+ use Software::License::Custom;
+ 
+@@ -40,5 +40,3 @@ Well... this is only some sample text. I
+ 
+ Yes, spanning more lines and more paragraphs.
+ END_OF_FULLTEXT
+-
+-done_testing;
+--- t/guess_meta_license.t
 t/guess_meta_license.t
+@@ -64,4 +64,3 @@ is_deeply(
+   [ ],
+ );
+ 
+-done_testing;
+--- t/meta-names.t
 t/meta-names.t
+@@ -2,13 +2,16 @@
+ use strict;
+ use warnings;
+ 
+-use Test::More 0.88;
++use Test::More;
+ 
+ my @files = ;
+ 
++plan tests => scalar @files;
++
+ for my $module (@files) {
+   # It's retired.  Dunno if it's okay to be open_source.  Punt!
+-  next if $module =~ /Sun.pm$/;
++  SKIP: {
++  skip "Dunno if it's okay for Sun.pm to be open_source", 1 if $module =~ 
/Sun.pm$/;
+ 
+   my $pkg = $module;
+   $pkg =~ s{^lib/}{};
+@@ -18,6 +21,5 @@ for my $module (@files) {
+   eval "require $pkg; 1";
+ 
+   ok(defined $pkg->meta_name, "$pkg provide meta_name");
++  }
+ }
+-
+-done_testing;
+--- t/two-dots.t
 t/two-dots.t
+@@ -32,6 +32,8 @@ my @licenses = qw(
+ Zlib
+ );
+ 
++plan tests => 3 * scalar(@licenses);
++
+ for my $l (@licenses) {
+ my $class = 'Software::License::' . $l;
+ require_ok($class);
+@@ -48,4 +50,3 @@ for my $l (@licenses) {
+ );
+ }
+ 
+-done_testing;
+--- 

Re: Specs using %define

[Richard Fearn]

> eclipse-findbugs (richardfearn)

Fixed - thanks!

Richard

-- 
Richard Fearn
richardfe...@gmail.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1297527] Review Request: perl-WWW-Twilio-API - Accessing Twilio's REST API with Perl

[bugzilla]

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



--- Comment #14 from Fedora Update System  ---
perl-WWW-Twilio-API-0.18-2.fc23 has been pushed to the Fedora 23 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-0d6a91da2e

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

Fedora Rawhide 20160117 compose check report

[Fedora compose checker]

Missing expected images:

Kde disk raw armhfp
Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64

Images in this compose but not Rawhide 20160116:

Design_suite live x86_64
Workstation live x86_64
Workstation live i386
Cinnamon live i386
Mate live i386
Workstation disk raw armhfp
Mate disk raw armhfp
Cinnamon live x86_64
Design_suite live i386
Mate live x86_64

Images in Rawhide 20160116 but not this:

Cloud disk raw i386
Cloud_atomic disk raw x86_64
Cloud disk qcow x86_64
Cloud docker x86_64
Cloud vagrant libvirt x86_64
Cloud vagrant virtualbox x86_64
Cloud_atomic disk qcow x86_64
Cloud disk raw x86_64
Cloud disk qcow i386

Failed openQA tests: 42 of 69

ID: 3290Test: x86_64 universal server_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/3290
ID: 3289Test: x86_64 universal server_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/3289
ID: 3288Test: x86_64 universal server_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/3288
ID: 3266Test: x86_64 universal server_sata_multi
URL: https://openqa.fedoraproject.org/tests/3266
ID: 3265Test: x86_64 universal server_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/3265
ID: 3263Test: x86_64 universal server_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/3263
ID: 3262Test: x86_64 universal server_delete_pata
URL: https://openqa.fedoraproject.org/tests/3262
ID: 3314Test: x86_64 generic_boot default_install@uefi
URL: https://openqa.fedoraproject.org/tests/3314
ID: 3313Test: x86_64 generic_boot default_install
URL: https://openqa.fedoraproject.org/tests/3313
ID: 3320Test: x86_64 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/3320
ID: 3264Test: x86_64 universal server_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/3264
ID: 3321Test: x86_64 kde_live default_install@uefi
URL: https://openqa.fedoraproject.org/tests/3321
ID: 3319Test: i386 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/3319
ID: 3267Test: x86_64 universal server_sata_multi@uefi
URL: https://openqa.fedoraproject.org/tests/3267
ID: 3270Test: x86_64 universal server_multi_empty
URL: https://openqa.fedoraproject.org/tests/3270
ID: 3269Test: x86_64 universal server_simple_free_space
URL: https://openqa.fedoraproject.org/tests/3269
ID: 3268Test: x86_64 universal server_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/3268
ID: 3271Test: x86_64 universal server_software_raid
URL: https://openqa.fedoraproject.org/tests/3271
ID: 3287Test: x86_64 universal package_set_minimal
URL: https://openqa.fedoraproject.org/tests/3287
ID: 3272Test: x86_64 universal server_delete_partial
URL: https://openqa.fedoraproject.org/tests/3272
ID: 3279Test: x86_64 universal server_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/3279
ID: 3280Test: x86_64 universal server_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/3280
ID: 3281Test: x86_64 universal server_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/3281
ID: 3283Test: x86_64 universal server_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/3283
ID: 3282Test: x86_64 universal server_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/3282
ID: 3293Test: x86_64 universal server_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/3293
ID: 3274Test: x86_64 universal server_ext3
URL: https://openqa.fedoraproject.org/tests/3274
ID: 3273Test: x86_64 universal server_btrfs
URL: https://openqa.fedoraproject.org/tests/3273
ID: 3275Test: x86_64 universal server_xfs
URL: https://openqa.fedoraproject.org/tests/3275
ID: 3298Test: x86_64 universal server_updates_img_local
URL: https://openqa.fedoraproject.org/tests/3298
ID: 3276Test: x86_64 universal server_lvmthin
URL: https://openqa.fedoraproject.org/tests/3276
ID: 3328Test: x86_64 workstation_live base_services_start
URL: https://openqa.fedoraproject.org/tests/3328
ID: 3299Test: x86_64 universal server_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/3299
ID: 3301Test: x86_64 universal european_language_install
URL: https://openqa.fedoraproject.org/tests/3301
ID: 3300Test: x86_64 universal server_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/3300
ID: 3286Test: x86_64 universal server_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/3286
ID: 3285Test: x86_64 universal server_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/3285
ID: 3284Test: x86_64 universal server_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/3284
ID: 3291Test: x86_64 universal server_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/3291
ID: 3278Test: x86_64 

robert pushed to perl-Crypt-RC4 (el5). "The??package??was??approved??in??Fedora. (..more)"

[notifications]

From 8178fb4e5d08d04d7d12a41bb37d5d0a3369d256 Mon Sep 17 00:00:00 2001
From: Mathieu Bridon 
Date: Tue, 5 Jul 2011 16:24:36 +0800
Subject: =?UTF-8?q?The=C2=A0package=C2=A0was=C2=A0approved=C2=A0in=C2=A0Fe?=
 =?UTF-8?q?dora.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Sources were uploaded to the lookaside cache with fedpkg. This commit
reflects the change in the sources and .gitignore files.
---
 .gitignore | 1 +
 sources| 1 +
 2 files changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index e69de29..7148c2a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Crypt-RC4-2.02.tar.gz
diff --git a/sources b/sources
index e69de29..f62136f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+4ca59a7e58ac9597c3b4f3f46ea22629  Crypt-RC4-2.02.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Crypt-RC4.git/commit/?h=el5=8178fb4e5d08d04d7d12a41bb37d5d0a3369d256
--
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

robert pushed to perl-Crypt-RC4 (el5). "Add compatibility for RHEL 5 (BuildRoot)"

[notifications]

From 91b62de8f05f0848bb9fc9ef4cd3e2f0fc379b35 Mon Sep 17 00:00:00 2001
From: Robert Scheck 
Date: Sun, 17 Jan 2016 17:37:31 +0100
Subject: Add compatibility for RHEL 5 (BuildRoot)

---
 perl-Crypt-RC4.spec | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/perl-Crypt-RC4.spec b/perl-Crypt-RC4.spec
index e3782da..5660f3a 100644
--- a/perl-Crypt-RC4.spec
+++ b/perl-Crypt-RC4.spec
@@ -9,6 +9,9 @@ Source0:
http://www.cpan.org/authors/id/S/SI/SIFUKURT/Crypt-RC4-%{version
 BuildArch:  noarch
 BuildRequires:  perl(ExtUtils::MakeMaker)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+%if 0%{?rhel} == 5
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} 
-n)
+%endif
 
 
 %description
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Crypt-RC4.git/commit/?h=el5=91b62de8f05f0848bb9fc9ef4cd3e2f0fc379b35
--
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

robert pushed to perl-Crypt-RC4 (el5). "Initial packaging of perl-Crypt-RC4. (..more)"

[notifications]

From 7d1c47054ed883a31ccf7f3eed1b0160ccf61522 Mon Sep 17 00:00:00 2001
From: Mathieu Bridon 
Date: Mon, 27 Jun 2011 11:19:24 +0800
Subject: Initial packaging of perl-Crypt-RC4.

This was submitted for review in Fedora on Mon Jun 27 2011:
https://bugzilla.redhat.com/show_bug.cgi?id=716777#c0
---
 perl-Crypt-RC4.spec | 58 +
 1 file changed, 58 insertions(+)
 create mode 100644 perl-Crypt-RC4.spec

diff --git a/perl-Crypt-RC4.spec b/perl-Crypt-RC4.spec
new file mode 100644
index 000..e3782da
--- /dev/null
+++ b/perl-Crypt-RC4.spec
@@ -0,0 +1,58 @@
+Name:   perl-Crypt-RC4
+Version:2.02
+Release:1%{?dist}
+Summary:Perl implementation of the RC4 encryption algorithm
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Crypt-RC4/
+Source0:
http://www.cpan.org/authors/id/S/SI/SIFUKURT/Crypt-RC4-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl(ExtUtils::MakeMaker)
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+
+%description
+A simple implementation of the RC4 algorithm, developed by RSA Security,
+Inc. Here is the description from RSA's website:
+
+RC4 is a stream cipher designed by Rivest for RSA Data Security (now RSA
+Security). It is a variable key-size stream cipher with byte-oriented
+operations. The algorithm is based on the use of a random permutation. Analysis
+shows that the period of the cipher is overwhelmingly likely to be greater than
+10100. Eight to sixteen machine operations are required per output byte, and
+the cipher can be expected to run very quickly in software. Independent 
analysts
+have scrutinized the algorithm and it is considered secure.
+
+
+%prep
+%setup -q -n Crypt-RC4-%{version}
+
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+
+%install
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
+
+%{_fixperms} %{buildroot}/*
+
+
+%check
+make test
+
+
+%files
+%defattr(-,root,root,-)
+%doc Changes
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+
+%changelog
+* Mon Jun 27 2011 Mathieu Bridon  2.02-1
+- Specfile autogenerated by cpanspec 1.78.
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Crypt-RC4.git/commit/?h=el5=7d1c47054ed883a31ccf7f3eed1b0160ccf61522
--
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 Rawhide 20160117 compose check report

[Adam Williamson]

On Sun, 2016-01-17 at 16:08 +, Fedora compose checker wrote:
> 
> Failed openQA tests: 42 of 69

So this is somewhat strange. It looks like the x86_64 boot.iso for
today does not boot, failing with a dracut error. However, I don't see
new versions of dracut or any other obviously related package in
today's Rawhide report. The 32-bit boot.iso booted fine, it seems, as
did both arches of the Workstation live.

I have plans today so I'm not sure I'll be able to look into it, but if
no-one else figures it out by then, I'll look into this tomorrow.

If anyone wants to grab it and have a look, you can get the failing
image at:
https://kojipkgs.fedoraproject.org/mash/rawhide-20160117/rawhide/x86_64/os/images/boot.iso
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: F24 Self Contained Change: Micro Bit

[Kushal Das]

On 16/01/16, Peter Robinson wrote:
> On Fri, Jan 15, 2016 at 4:31 PM, Jan Kurik  wrote:
> > = Proposed Self Contained Change: Micro Bit =
> > https://fedoraproject.org/wiki/Changes/Micro_Bit
> >
> > Change owner(s):
> > * Kushal Das 
> >
> > Enable the use of BBC Micro Bit on Fedora systems. Users will be able
> > develop, and put in new code to their micro:bit devices using Fedora.
> >
> > == Detailed Description ==
> > Micro Bit (or micro:bit) is an ARM-based embedded system designed by
> > the BBC for use in computer education in the UK. It will be given to
> > every class 7 students in UK. This change will make sure that they
> > simply use Fedora to use their devices.
> 
> This is a very limited description of the intentions. The way it's
> intended to be used in the UK is via a programming web interface
> written by Microsoft (apparently it'll be open sourced!) which will be
> the standard, but it'll also support micropython [1] and I suspect
> some form of ardrino style programming, but being a Cortex-M series
> processor is obviously not capable of running Fedora itself so I think
> for this to be a feature you need to actually specify how it's
> actually going to be supported and what tools rather than a handy wavy
> "support" outline.
My mistake of not putting in all the details on time. It comes down to
packaging uFlash, the tool which can be used to flash the device with
Python scripts, and MicroPython runtime. The second package is called
mu, which is actively being developed, it is very simple editor, which
can be used to write and flash the device with the Python scripts. mu
removes the dependency to the internet connection, it also has repl
which connects to the device.

Optionally we can package any addition packages required to
develop MicroPython itself on Fedora.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
CentOS Cloud SIG lead
http://kushaldas.in
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Updating perl-Spreadsheet-ParseExcel on EPEL 5

[Robert Scheck]

Hello Paul,

I would like to update perl-Spreadsheet-ParseExcel on EPEL 5 to the version
that EPEL 6 has. The requirement of perl(Crypt::RC4) gets satisfied with
this update:

  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-70c923f5af

EPEL 5 has currently 0.3200-2.el5, while EPEL 6 has 0.5900-1.el6. Given I
am the package maintainer of perl-Spreadsheet-XLSX and 0.15 needs now
perl(Spreadsheet::ParseExcel) >= 0.45, I would like to perform this update.

According to

  http://koji.fedoraproject.org/koji/buildinfo?buildID=260141

the reason was so far that perl(Crypt::RC4) wasn't available for EPEL 5. I
tried the builds locally and it seems to work here fine.

Please let me know if you have any objections or if it's okay to proceed.

Thank you very much.


Greetings,
  Robert


pgpwdd95X6f6b.pgp
Description: PGP signature
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: New tbb in Rawhide

[Jonathan Wakely]

On 16/01/16 21:54 -0700, Jerry James wrote:

Jonathan,

On Fri, Jan 15, 2016 at 3:43 PM, Jonathan Wakely
 wrote:

How soon will you be doing the rebuilds?

gazebo also needs to be rebuilt for Boost 1.60, which I'm currently
doing in the f24-boost side tag. If you're going to be rebuilding it
soon anyway shall I wait and not do gazebo?

And if you get round to it soon, it would be better to also use the
f24-boost side tag, so that it rebuilds using the new boost-1.60.0
package at the same time as the new tbb.


I'm very sorry.  That would have been great, but I in fact started the
rebuilds pretty much simultaneously with sending the previous message,
so I did not rebuild in the side tag.  I apologize for my impatience.


No problem, I'll do another rebuild in the side tag. At least I'll
know that if they fail the problems are related to the Boost change
and not your changes!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Standard, consistent subject lines for automated emails

[Jonathan Wakely]

On 16/01/16 13:34 +, Richard W.M. Jones wrote:


Here are a small collection of subject lines of emails sent
automatically to me by various Fedora systems in the past few days:

Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
Subject: rjones's libguestfs-1.33.1-2.fc24 completed
Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
Subject: Broken dependencies: libguestfs
Subject: ABRT report for package gnome-boxes has reached 10 occurrences
Subject: [Bug 1269975] svirt very occasionally prevents parallel libvirt [..]
Subject: Fedora 'packager' sponsor needed for suanand
Subject: sailer's mingw-sqlite-3.10.1.0-1.fc24 failed to build
Subject: libguestfs's builds are back to normal in f24
Subject: dchen pushed to ocaml-lwt (el6).  "New upstream version 2.2.0."

The only consistent thing is there's nothing consistent about them :-/


I've been thinking about complaining about the very same thing!


(2) The second word should be the status, reflecting what the reader
needs to know or do, for example "succeeded", "failed", "submitted".


Yes!  Some scratch builds have a really long header and the
"completed" or "failed" is not visible even with far more than 72
characters shown.


Maybe you have some better ideas?


LGTM.


A related topic is headers, which could be used for filtering.
Various systems add headers -- see examples below -- but again there's
not much consistency and the headers aren't particularly useful for
filtering.


Yes again. It would be great if the headers were more useful.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

libwhirlpool (a Whirlpool algorithm implementation)

[Denis Fateyev]

Hello list,

A while ago, I've created a Whirlpool hash function library [1] based on
the original implementation of Whirlpool algorithm by Vincent Rijmen and
Paulo S. L. M. Barreto.

It's packaged as 'libwhirlpool' in Fedora and EPEL [2].
Also provides 'whirlpoolsum' utility to calculate and check Whirlpool
hashes with the interface similar to 'md5sum', 'shaXXXsum' from coreutils.

Feel free to use and leave any suggestions or feedback.

[1] https://github.com/dfateyev/libwhirlpool

[2] https://admin.fedoraproject.org/pkgdb/package/rpms/libwhirlpool/

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

[Bug 1285437] Upgrade perl-Spreadsheet-XLSX to 0.15

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Spreadsheet-XLSX-0.15-
   ||1.fc23
 Resolution|--- |ERRATA
Last Closed||2016-01-17 12:51:03



-- 
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 1285437] Upgrade perl-Spreadsheet-XLSX to 0.15

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Spreadsheet-XLSX-0.15-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