new packages pending review & approve

[Sun, Yunying]

Hello there,

I have 2 packages under review now:
https://bugzilla.redhat.com/show_bug.cgi?id=1369708
https://bugzilla.redhat.com/show_bug.cgi?id=1369720

Some reviews and updates have been done, and now it has been quiet for some 
days.
Could someone help with the review and approve? Since it's my first package, 
also need a sponsor.

Thanks,
Yunying

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2016-10-27 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-10-27 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2016-10-27 09:00 Thu US/Pacific PDT
2016-10-27 12:00 Thu US/Eastern EDT
2016-10-27 16:00 Thu UTC <-
2016-10-27 17:00 Thu Europe/London  BST
2016-10-27 18:00 Thu Europe/Paris  CEST
2016-10-27 18:00 Thu Europe/Berlin CEST
2016-10-27 21:30 Thu Asia/Calcutta  IST
--new day--
2016-10-28 00:00 Fri Asia/Singapore SGT
2016-10-28 00:00 Fri Asia/Hong_Kong HKT
2016-10-28 01:00 Fri Asia/Tokyo JST
2016-10-28 02:00 Fri Australia/BrisbaneAEST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/13

= Followups =

#topic #398 Tilde in version
.fpc 398
https://fedorahosted.org/fpc/ticket/398

#topic #558 Application/Library distinction and package splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558

#topic #610 Packaging guidelines: Check upstream tarball signatures
.fpc 610
https://fedorahosted.org/fpc/ticket/610

#topic #647 No mention of macros for systemd scriptlets for user
units
.fpc 647
https://fedorahosted.org/fpc/ticket/647

#topic #650 Alternate Python Interpreters
.fpc 650
https://fedorahosted.org/fpc/ticket/650

#topic #654 glibc file triggers
.fpc 654
https://fedorahosted.org/fpc/ticket/654

#topic #655 meson buildsystem guidelines
.fpc 655
https://fedorahosted.org/fpc/ticket/655

#topic #656 pre/post-release version guidelines need major
simplification
.fpc 656
https://fedorahosted.org/fpc/ticket/656

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/13

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Randy Barlow]

There are some good thoughts in this thread. A few people have
suggested that getting the update process to go faster would really
help with these problems, and I agree.

Patrick Uiterwijk has recently made quite a few contributions to Bodhi
that a) make it more reliable, and b) allow it to gate on automatic
signatures. I believe these two areas of improvement in Bodhi will get
us closer to automating Bodhi. I'm sure we still have bugs that we will
need to shake out to get it there, but that's the goal I would like to
see us achieve and I don't think it's unrealistic. I expect that
automating Bodhi will make our update process a little bit faster, and
I'm sure there are many other opportunities for improvement that we can
tackle as well. Contributions welcome!

By the way, I am planning to release Bodhi 2.3.0 tomorrow which has the
automatic signing gating feature that Patrick wrote for us. The draft
release notes are here:

https://github.com/fedora-infra/bodhi/pull/1054

Once that's in place, there are nice little icons that render on Update
pages to indicate whether the builds are signed yet or not. Once the
builds are signed, the Update can then progress from pending to testing
during the next push.

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [OT] Best Practices: Populating RPM SPEC %defines in basic Ant build management

[Orion Poplawski]

On 10/26/2016 12:32 PM, Bryan Smith wrote:

PREFACE:  My apologies as this may be off-topic.  But I figured this
might be the best set of SMEs to ask this question, especially since
I'm drawing a blank from when I had to do this a few years ago.

Environment:
 - Disconnected systems (no or very limited Internet access)
 - Apache Ant build management

Best Practice Sought:
 - Solution to populate %defines at the top of RPM SPEC files

Feel free to tell me to RTFM with a link or anything else.  I just
haven't kept up with the latest set of 'Best Practices' and/or tools
to manage many of the common %defines at the top of RPM SPEC files in
an Ant build management solution.

I.e., I assume there is a way to manage this better than just some
scripts called as part of the buildfile that does direct file
manipulation (e.g., via sed) and/or populates via environmental
variables

Side Note:  We were looking at introducing Maven-Nexus as well, but
we're sticking with just our Git repos and Ant to match our
traditional software development and its build process.  This would be
for packaging things into RPM atop of all that.

Again, likely off-topic and/or remedial for this list, but I'd figure
I'd ask as I'm several years out-of-date.

-- bjs



Perhaps give some examples?  I for one have no idea what you're talking 
about from the description above.  An ant rpm spec file doesn't need 
much, see https://fedora-java.github.io/howto/latest/#ant



--
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{python3_pkgversion} tag

[Orion Poplawski]

On 10/26/2016 05:16 PM, Germano Massullo wrote:

A proven packager edited one of the python libraries I maintain, to add
some useful stuff. Among all the edits he made, there is one in
particular that made me write this message.
%{?python_provide:%python_provide python3-%{pypi_name}}
has been replaced with
%{?python_provide:%python_provide python%{python3_pkgversion}-%{pypi_name}}

What is the advantage of using %{python3_pkgversion} tag? Have in future
a package name like python31-foo ?
Till now I have only seen names like
python2-foo
and
python3-foo


%python3_pkgversion will always resolve to 3 on Fedora (at least for the 
foreseeable future).  On EPEL, it currently resolves to 34 as that is 
the current main (and only at the moment) python3 version in EPEL.  At 
some point we will introduce a new python3 version (probably 3.6 at this 
point) and will start to shift to that.


See also - https://fedoraproject.org/wiki/PackagingDrafts:Python3EPEL

We don't currently have %python3_other*.  I'm hopeful that we can come 
up with some better macros for handling the multiple versions before 
rolling that out.


- Orion

--
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
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Firefox 49.0.2

[Bojan Smojver]

I use e10 all the time. Works fine.

-- 
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

%{python3_pkgversion} tag

[Germano Massullo]

A proven packager edited one of the python libraries I maintain, to add
some useful stuff. Among all the edits he made, there is one in
particular that made me write this message.
%{?python_provide:%python_provide python3-%{pypi_name}}
has been replaced with
%{?python_provide:%python_provide python%{python3_pkgversion}-%{pypi_name}}

What is the advantage of using %{python3_pkgversion} tag? Have in future
a package name like python31-foo ?
Till now I have only seen names like
python2-foo
and
python3-foo

Thank you
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

[Bug 1387642] perl-Log-Report-1.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Log-Report-1.18-1.fc26 |perl-Log-Report-1.18-1.fc26
   ||perl-Log-Report-1.18-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-10-26 18:30:36



--- Comment #3 from Fedora Update System  ---
perl-Log-Report-1.18-1.fc25 has been pushed to the Fedora 25 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1388082] perl-Dist-Zilla-Plugin-Test-Compile-2.055 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-Test-Compile-2.055-1.fc24 has been pushed to the Fedora
24 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-76798110e3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1387849] perl-Unicode-Collate-1.15 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.fc24 has been pushed to the Fedora 24 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-710db253cd

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1388282] perl-Unicode-Collate-1.16 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.fc24 has been pushed to the Fedora 24 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-710db253cd

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Proposal to move things from fedora-qa.git to Pagure

[Adam Williamson]

Hey folks!

So, if no-one has any objections, I'm intending to move the contents of
fedora-qa.git from fedorahosted to Pagure. At the same time, I think
it'd make sense to split some things out into their own projects. My
rough plan is to split out at least check-compose, relvalconsumer and
stats into separate projects. I'm not sure which of the other things
it's worth splitting out.

I'll probably put the new projects in the fedora-qa namespace and under
the fedora-qa group (if I can). git seems to have some fairly nifty
capabilities for isolating the history of individual files /
directories:

https://blogs.atlassian.com/2014/04/tear-apart-repository-git-way/

so we should be able to produce decent histories for each new project.

Does anyone mind me going ahead and doing this? And importantly, is
anyone aware of any significant deployments besides the ones I'm
already looking after (openQA boxes etc) which use the stuff from this
git repo, and would need to be updated to pull from the new project
repos?

Thanks, everyone!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: f24 x86_64 :: yumex-dnf SIGSEGV

[Alexander Ploumistos]

On Wed, Oct 26, 2016 at 6:08 PM, Adrian Sevcenco
 wrote:
> does anyone have any idea about this? is my ram dying?

If you suspect a problem with your RAM, you should try testing it with
memtest86+ and something like Prime95 before filing a bug report (if
there is indeed a bug).

For future reference, such questions are better suited for the users
mailing list.

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Bojan Smojver]

https://bugzilla.redhat.com/show_bug.cgi?id=1370061#c7

-- 
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Bojan Smojver]

I guess I must have misread this as all kernels built in koji, not just
scratch builds. Ouch.

-- 
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1388082] perl-Dist-Zilla-Plugin-Test-Compile-2.055 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-Test-Compile-2.055-1.fc25 has been pushed to the Fedora
25 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-82d23e0925

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1388282] perl-Unicode-Collate-1.16 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.fc25 has been pushed to the Fedora 25 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-782bf1ecf2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1387849] perl-Unicode-Collate-1.15 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.fc25 has been pushed to the Fedora 25 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-782bf1ecf2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

review swap

[Björn Esser]

Hello toghether,

I have Odoo waiting for review [1].  It is the package for my change 
proposal for Fedora 26 [2].  Anyone interested to swap reviews?


Cheers,
  Björn


[1]  https://bugzilla.redhat.com/show_bug.cgi?id=1379432
[2]  https://fedoraproject.org/wiki/Changes/Odoo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Bug in awscli-1.11.0-1.el7

[Ben Smith]

Hi Stephen, today I noticed the bugzilla and entered a bug, thanks.

On Wed, Oct 26, 2016 at 10:53 AM, Stephen John Smoogen 
wrote:

> On 25 October 2016 at 16:32, Ben Smith  wrote:
> > After an upgrade to the current EPEL awcli, a system I'm working on
> broke. There's a bug with downloading empty files that's been fixed in
> 1.11.1. We verified that upgrading to awscli-1.11.2-1.el7 fixes the problem.
> >
> > https://github.com/aws/aws-cli/blob/develop/CHANGELOG.rst#
> >
> > Thanks!
>
> Hi I have sent this to the packager to look at. In general, the best
> way to get these sorts of issues dealt with is by filing a bug as I
> may or may not get to this.
>
> Thanks for the info
>
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[OT] Best Practices: Populating RPM SPEC %defines in basic Ant build management

[Bryan Smith]

PREFACE:  My apologies as this may be off-topic.  But I figured this
might be the best set of SMEs to ask this question, especially since
I'm drawing a blank from when I had to do this a few years ago.

Environment:
 - Disconnected systems (no or very limited Internet access)
 - Apache Ant build management

Best Practice Sought:
 - Solution to populate %defines at the top of RPM SPEC files

Feel free to tell me to RTFM with a link or anything else.  I just
haven't kept up with the latest set of 'Best Practices' and/or tools
to manage many of the common %defines at the top of RPM SPEC files in
an Ant build management solution.

I.e., I assume there is a way to manage this better than just some
scripts called as part of the buildfile that does direct file
manipulation (e.g., via sed) and/or populates via environmental
variables

Side Note:  We were looking at introducing Maven-Nexus as well, but
we're sticking with just our Git repos and Ant to match our
traditional software development and its build process.  This would be
for packaging things into RPM atop of all that.

Again, likely off-topic and/or remedial for this list, but I'd figure
I'd ask as I'm several years out-of-date.

-- bjs

--
Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
E-mail:  b.j.smith at ieee.org  or  me at bjsmith.me
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1389064] New: EPEL7 branch missing (required for psad)

[bugzilla]

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

Bug ID: 1389064
   Summary: EPEL7 branch missing (required for psad)
   Product: Fedora
   Version: rawhide
 Component: perl-IPTables-ChainMgr
  Assignee: m...@redhat.com
  Reporter: domi...@greysector.net
QA Contact: extras...@fedoraproject.org
CC: m...@redhat.com, perl-devel@lists.fedoraproject.org



Description of problem:
EPEL7 branch is missing for perl-IPTables-ChainMgr, preventing psad from being
installed. Please build it for EPEL7.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1389064] EPEL7 branch missing (required for psad)

[bugzilla]

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

Dominik 'Rathann' Mierzejewski  changed:

   What|Removed |Added

 Blocks||1281755




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1281755
[Bug 1281755] Build psad for EPEL7
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1389060] EPEL7 branch missing (required for psad)

[bugzilla]

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

Dominik 'Rathann' Mierzejewski  changed:

   What|Removed |Added

 Blocks||1281755




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1281755
[Bug 1281755] Build psad for EPEL7
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1389064] EPEL7 branch missing (required for psad)

[bugzilla]

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



--- Comment #1 from Miloslav Trmač  ---
I’m afraid I can’t take on that maintenance work.  If you wanted to maintain
that yourself (or even take over the package completely), I’d be happy to ACK
the necessary permissions in pkgdb.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1389060] EPEL7 branch missing (required for psad)

[bugzilla]

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



--- Comment #1 from Miloslav Trmač  ---
I’m afraid I can’t take on that maintenance work.  If you wanted to maintain
that yourself (or even take over the package completely), I’d be happy to ACK
the necessary permissions in pkgdb.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1389060] New: EPEL7 branch missing (required for psad)

[bugzilla]

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

Bug ID: 1389060
   Summary: EPEL7 branch missing (required for psad)
   Product: Fedora
   Version: rawhide
 Component: perl-IPTables-Parse
  Assignee: m...@redhat.com
  Reporter: domi...@greysector.net
QA Contact: extras...@fedoraproject.org
CC: m...@redhat.com, perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Description of problem:
EPEL7 branch is missing for perl-IPTables-Parse, preventing psad from being
installed. Please build it for EPEL7.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-Cpanel-JSON-XS (perl-Cpanel-JSON-XS-3.0219-1.fc26). "Update to 3.0219 (..more)"

[notifications]

From 22a87d3f266ace5ad9d92b73c06e7f63f9575d41 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Wed, 26 Oct 2016 19:04:31 +0100
Subject: Update to 3.0219

- New upstream release 3.0219
  - Work around mingw 4.0 modfl() bug (Perl RT#125924)
---
 perl-Cpanel-JSON-XS.spec | 6 +-
 sources  | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/perl-Cpanel-JSON-XS.spec b/perl-Cpanel-JSON-XS.spec
index b85f606..264a681 100644
--- a/perl-Cpanel-JSON-XS.spec
+++ b/perl-Cpanel-JSON-XS.spec
@@ -1,6 +1,6 @@
 Name:  perl-Cpanel-JSON-XS
 Summary:   JSON::XS for Cpanel, fast and correct serializing
-Version:   3.0218
+Version:   3.0219
 Release:   1%{?dist}
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/Cpanel-JSON-XS/
@@ -156,6 +156,10 @@ make test %{!?perl_bootstrap:AUTHOR_TESTING=1}
 %{_mandir}/man3/Cpanel::JSON::XS::Boolean.3*
 
 %changelog
+* Wed Oct 26 2016 Paul Howarth  - 3.0219-1
+- Update to 3.0219
+  - Work around mingw 4.0 modfl() bug (Perl RT#125924)
+
 * Thu Oct 13 2016 Paul Howarth  - 3.0218-1
 - Update to 3.0218
   - Detect INF/NAN: ?/++/-?/--- on HP-UX (GH#56)
diff --git a/sources b/sources
index bbb57ce..f6f2579 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-818af1a8354341646d839ca1a14b780c  Cpanel-JSON-XS-3.0218.tar.gz
+91ce668c8bf3b6ddc526b4e61f710b2b  Cpanel-JSON-XS-3.0219.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Cpanel-JSON-XS.git/commit/?h=perl-Cpanel-JSON-XS-3.0219-1.fc26=22a87d3f266ace5ad9d92b73c06e7f63f9575d41
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Fedora Rawhide-20161026.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 12/101 (x86_64), 3/17 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20161025.n.0):

ID: 44327   Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/44327
ID: 44328   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/44328
ID: 44329   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/44329
ID: 44332   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/44332
ID: 44343   Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/44343

Old failures (same test failed in Rawhide-20161025.n.0):

ID: 44330   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/44330
ID: 44345   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/44345
ID: 44390   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/44390
ID: 44404   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/44404
ID: 44407   Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/44407
ID: 44409   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/44409
ID: 44411   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/44411
ID: 44412   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/44412
ID: 44432   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/44432
ID: 44433   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/44433
ID: 44569   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/44569

Passed openQA tests: 86/101 (x86_64), 14/17 (i386)

New passes (same test did not pass in Rawhide-20161025.n.0):

ID: 44318   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/44318
ID: 44319   Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/44319
ID: 44320   Test: x86_64 Workstation-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/44320
ID: 44321   Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/44321
ID: 44322   Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/44322
ID: 44323   Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/44323
ID: 44324   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/44324
ID: 44325   Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/44325
ID: 44326   Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/44326
ID: 44331   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/44331

Skipped openQA tests: 1 of 120
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-Cpanel-JSON-XS (master). "Update to 3.0219 (..more)"

[notifications]

From 22a87d3f266ace5ad9d92b73c06e7f63f9575d41 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Wed, 26 Oct 2016 19:04:31 +0100
Subject: Update to 3.0219

- New upstream release 3.0219
  - Work around mingw 4.0 modfl() bug (Perl RT#125924)
---
 perl-Cpanel-JSON-XS.spec | 6 +-
 sources  | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/perl-Cpanel-JSON-XS.spec b/perl-Cpanel-JSON-XS.spec
index b85f606..264a681 100644
--- a/perl-Cpanel-JSON-XS.spec
+++ b/perl-Cpanel-JSON-XS.spec
@@ -1,6 +1,6 @@
 Name:  perl-Cpanel-JSON-XS
 Summary:   JSON::XS for Cpanel, fast and correct serializing
-Version:   3.0218
+Version:   3.0219
 Release:   1%{?dist}
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/Cpanel-JSON-XS/
@@ -156,6 +156,10 @@ make test %{!?perl_bootstrap:AUTHOR_TESTING=1}
 %{_mandir}/man3/Cpanel::JSON::XS::Boolean.3*
 
 %changelog
+* Wed Oct 26 2016 Paul Howarth  - 3.0219-1
+- Update to 3.0219
+  - Work around mingw 4.0 modfl() bug (Perl RT#125924)
+
 * Thu Oct 13 2016 Paul Howarth  - 3.0218-1
 - Update to 3.0218
   - Detect INF/NAN: ?/++/-?/--- on HP-UX (GH#56)
diff --git a/sources b/sources
index bbb57ce..f6f2579 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-818af1a8354341646d839ca1a14b780c  Cpanel-JSON-XS-3.0218.tar.gz
+91ce668c8bf3b6ddc526b4e61f710b2b  Cpanel-JSON-XS-3.0219.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Cpanel-JSON-XS.git/commit/?h=master=22a87d3f266ace5ad9d92b73c06e7f63f9575d41
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded Cpanel-JSON-XS-3.0219.tar.gz for perl-Cpanel-JSON-XS

[notifications]

91ce668c8bf3b6ddc526b4e61f710b2b  Cpanel-JSON-XS-3.0219.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Cpanel-JSON-XS/Cpanel-JSON-XS-3.0219.tar.gz/md5/91ce668c8bf3b6ddc526b4e61f710b2b/Cpanel-JSON-XS-3.0219.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Bug in awscli-1.11.0-1.el7

[Stephen John Smoogen]

On 25 October 2016 at 16:32, Ben Smith  wrote:
> After an upgrade to the current EPEL awcli, a system I'm working on broke. 
> There's a bug with downloading empty files that's been fixed in 1.11.1. We 
> verified that upgrading to awscli-1.11.2-1.el7 fixes the problem.
>
> https://github.com/aws/aws-cli/blob/develop/CHANGELOG.rst#
>
> Thanks!

Hi I have sent this to the packager to look at. In general, the best
way to get these sorts of issues dealt with is by filing a bug as I
may or may not get to this.

Thanks for the info

> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: F26 proposed release tooling changes

[Charalampos Stratakis]

kerberos support for Fedora infra would be an amazing step forward.

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "Amanda Carter" 
To: devel@lists.fedoraproject.org
Sent: Monday, October 24, 2016 8:04:40 PM
Subject: F26 proposed release tooling changes

Heads up about the release tooling changes we're proposing for F26. Note that 
this list may exclude work to be completed for modularity but that will be 
added to the same page at a later date. If there's anything that seems to be 
missing or mis-prioritized please let me know. I'd like feedback on this list 
by the end of the week. Next week we'll start getting ready to deliver these 
changes.

https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline#F26_Proposed_Tools_Changes

Thanks!

-- 
Amanda Carter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1388082] perl-Dist-Zilla-Plugin-Test-Compile-2.055 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|ON_QA



--- Comment #1 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-Test-Compile-2.055-1.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-62230dac53

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1388282] perl-Unicode-Collate-1.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.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-93de4e2d67

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1387849] perl-Unicode-Collate-1.15 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Unicode-Collate-1.16-1.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-93de4e2d67

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F26 proposed release tooling changes

[Ken Dreyer]

On Wed, Oct 26, 2016 at 12:39 AM, Alexander Bokovoy  wrote:
> We implemented HTTPS proxying of the Kerberos protocol, based on
> MS-KKDCP specification. It is in MIT Kerberos 1.13+.

Oh, fantastic! I didn't know that standard, or that MIT Kerberos supported it.

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20161026.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 4/101 (x86_64), 1/17 (i386)

New failures (same test did not fail in 25-20161025.n.0):

ID: 44499   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/44499
ID: 44524   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/44524

Old failures (same test failed in 25-20161025.n.0):

ID: 8   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/8
ID: 44510   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/44510
ID: 44553   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/44553

Passed openQA tests: 97/101 (x86_64), 16/17 (i386), 2/2 (arm)

New passes (same test did not pass in 25-20161025.n.0):

ID: 44454   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/44454
ID: 44464   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/44464
ID: 44512   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/44512
ID: 44526   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/44526
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: reviewing captagent (HOMER / SIPCapture)

[Jared K. Smith]

On Tue, Oct 25, 2016 at 5:07 AM, Daniel Pocock  wrote:

>
> Is anybody interested in reviewing captagent?
>

I was going to take it, but it looks like someone beat me to the punch.

-Jared
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: scikit-learn in Fedora 25 ?

[Tom Devel]

Jason, thanks, I contacted the package maintainer.

Tom

On Tue, Oct 25, 2016 at 7:08 PM, Jason L Tibbitts III 
wrote:

> > "TD" == Tom Devel  writes:
>
> TD> I have used scikit-learn in several previous Fedora releases,
> TD> however if I look at
> TD> https://bodhi.fedoraproject.org/updates/?packages=python-scikit-learn
> TD> there is no scikit-learn for Fedora 25 anymore.
>
> No updates have been issued for that package in Fedora 25.  So I would
> not expect that it would appear in the updates system.  That has nothing
> to do with whether it is still present in the distribution.
>
> Plenty of info is at:
>
> https://apps.fedoraproject.org/packages/python-scikit-learn/overview/
>
> Or of course you could always look on the download servers to see if the
> package is present.
>
> TD> The latest stable version is 0.18.1
>
> Perhaps you could file a ticket requesting that it be updated.  The
> maintainers don't have upstream release monitoring turned on so the
> monitoring system won't automatically alert them.   Doesn't mean that
> they aren't aware, but it doesn't hurt to file a ticket if one hasn't
> already been filed.
>
> TD> Will scikit-learn be included Fedora 25?
>
> I don't see why it wouldn't be included.  The packages sure seem to be
> there.
>
>  - J<
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Matthew Miller]

On Tue, Oct 25, 2016 at 07:37:32PM -0600, Kevin Fenzi wrote:
> Nope. We have talked about having some kind of fast track, but IMHO, we
> should just get the normal process faster. 

Getting the normal process faster would help in a large number of other
areas. Right now, when we have issues in a spin or other deliverable,
we have to first update the RPM, wait for it to get pushed to testing,
wait for it to get pushed to stable, and then wait for a new release
artifact (iso, qcow, whatever) with that RPM included. This means it
can take several days from fix to testing the fix, and if it takes
several tries to get right, it can easily take a week to address a
simpel problem. It'd be nice if we could reduce that turn-around time
to hours, if not minutes.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Matthew Miller]

On Tue, Oct 25, 2016 at 05:59:24PM -0700, Andrew Lutomirski wrote:
> 1. Updates, even critical security updates, are very slow.  Getting an
> update out involves creating a build and an update (which is
> reasonably fast for most packages), pushing the update to

There are two open tickets on issues related to this:

Release Engineering:

  https://fedorahosted.org/rel-eng/ticket/5886

Security Team:

  https://fedorahosted.org/fedora-security-team/ticket/3


Both of these are stalled and could use help.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[David Shea]

> On 10/25/2016 09:35 PM, David Shea wrote:
> 
> Well then, who exactly should set the RPM standard if not RPM itself?
> 
> FWIW, the change in question occurred in the transition from RPM V3 
> packages to V4 packages which involved much more than just file name 
> storage and RPM still transparently handles both package versions 
> sixteen years after the change. I'm not sure what's so funny about that.
> 
>   - Panu -

My point is there is no standard. The part I quoted is a comment to a static 
function in a file in the rpm source. The comment on RPMTAG_FILENAMES in 
rpmtag.h (NB: these comments are the only things that explain what tags exist 
and what goes in them) notes that the tag is an "extension", and the comment on 
fnTag() is the only place that explains what the heck it's extended from.

There is no RPM standard. The content of RPM, the file format, is dictated by 
RPM, the program, and it is hostile to parsing by any other program. What 
*should* set the RPM standard is an actual, you know, standard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

f24 x86_64 :: yumex-dnf SIGSEGV

[Adrian Sevcenco]

Hi! I have a laptop with fedora 24 and today i encountered a strange thing :
beside various crashes in kde (apps crashing at logout or shutdown, suspend to 
ram not working)
i tried to use yumex-dnf through ssh -XY and i got a stern :
[root@t420 ~]# yumex-dnf
Segmentation fault (core dumped)

trying to debug "python3 /usr/bin/yumex-dnf" i got

(gdb) set args /usr/bin/yumex-dnf
(gdb) run
Starting program: /usr/bin/python3 /usr/bin/yumex-dnf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
rawmemchr () at ../sysdeps/x86_64/rawmemchr.S:37
37  movdqu  (%rdi), %xmm0

does anyone have any idea about this? is my ram dying?

Thank you!
Adrian



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] EPEL-ANNOUNCE Re: New rnapshot build for EPEL is testing

[James Hogarth]

On 18 October 2016 at 06:26, Steven Roberts  wrote:
> EPEL packages for a new rsnapshot version (1.4.2) have been built and
> available in testing.
>
> There are many bug fixed in this release.  From upstream the config file
> should be comptabile with the existing 1.3.1 currently in EPEL.
>
> However given new upstream maintainer/hosting, it was about seven years
> between upstream releases, and rsnapshot is used for things like
> backups, we are taking extra caution with this release.
>
> So we are emailing this list to get extra notice and we are planning on
> at least 4 weeks in testing and hoping to get some good testing and
> karma reflected before moving to push to stable.
>
> the bugzilla bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1375289
>
> the bodhi links for each EPEL version:
>
> EL5:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a017ef5480
> EL6:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5a39cec441
> EL7:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-91b8d9eccc
>
> Also, thanks to new co-maintener for the rsnapshot package James Hogarth
> for getting the actually mods, builds put together.
>


As an update to the announcement, it's been noted in the Fedora users
mailing list that the log file had a change of syntax at 1.3.2 (we
were on 1.3.1) back in 2012 ...

The logfile now has the timestamps in ISO 8601 format rather than
apache-like so if any parsing or logstash tools are being used against
the rsnapshot logs they will need to be updated to account for this
___
epel-announce mailing list -- epel-annou...@lists.fedoraproject.org
To unsubscribe send an email to epel-announce-le...@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Fedora 25 compose report: 20161026.n.0 changes

[Fedora Branched Report]

OLD: Fedora-25-20161025.n.0
NEW: Fedora-25-20161026.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  1
Dropped packages:0
Upgraded packages:   79
Downgraded packages: 0

Size of added packages:  69.71 KiB
Size of dropped packages:0.00 B
Size of upgraded packages:   1.14 GiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   27.40 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =
Image: Docker_Base docker armhfp
Path: Docker/armhfp/images/Fedora-Docker-Base-25-20161026.n.0.armhfp.tar.xz
Image: Docker_Base docker x86_64
Path: Docker/x86_64/images/Fedora-Docker-Base-25-20161026.n.0.x86_64.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-wikipedia-1.4.5-2.fc25
Summary: Wikipedia API for Python
RPMs:python2-wikipedia python3-wikipedia
Size:71388 bytes


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Field3D-1.7.2-3.fc25
Old package:  Field3D-1.7.2-2.fc25
Summary:  Library for storing voxel data
RPMs: Field3D Field3D-devel
Size: 5957172 bytes
Size change:  34340 bytes
Changelog:
  * Mon Oct 17 2016 Richard Shaw <hobbes1...@gmail.com> - 1.7.2-3
  - Add patch to fix unit tests on big endian systems.


Package:  abi-dumper-0.99.19-1.fc25
Old package:  abi-dumper-0.99.18-1.fc25
Summary:  Tool to dump ABI of an ELF object containing DWARF debug info
RPMs: abi-dumper
Size: 40710 bytes
Size change:  336 bytes
Changelog:
  * Mon Oct 10 2016 Richard Shaw <hobbes1...@gmail.com> - 0.99.19-1
  - Update to latest upstream release.


Package:  analitza-16.08.2-1.fc25
Old package:  analitza-16.08.1-1.fc25
Summary:  Library of mathematical features
RPMs: analitza analitza-devel
Size: 1462648 bytes
Size change:  -7288 bytes
Changelog:
  * Thu Oct 13 2016 Rex Dieter <rdie...@fedoraproject.org> - 16.08.2-1
  - 16.08.2


Package:  artikulate-16.08.2-1.fc25
Old package:  artikulate-16.08.1-1.fc25
Summary:  Improve your pronunciation by listening to native speakers
RPMs: artikulate artikulate-libs
Size: 7740480 bytes
Size change:  -6328 bytes
Changelog:
  * Thu Oct 13 2016 Rex Dieter <rdie...@fedoraproject.org> - 16.08.2-1
  - 16.08.2


Package:  blinken-16.08.2-1.fc25
Old package:  blinken-16.08.1-1.fc25
Summary:  Memory Enhancement Game
RPMs: blinken
Size: 1742038 bytes
Size change:  -3060 bytes
Changelog:
  * Thu Oct 13 2016 Rex Dieter <rdie...@fedoraproject.org> - 16.08.2-1
  - 16.08.2


Package:  btbuilder-0.5.13-1.fc25
Old package:  btbuilder-0.5.12-1.fc25
Summary:  Turn based role-playing game builder and engine
RPMs: btbuilder btbuilder-data
Size: 408038744 bytes
Size change:  152584 bytes
Changelog:
  * Wed Oct 19 2016 Dennis Payne <du...@identicalsoftware.com> - 0.5.13-1
  - New version of btbuilder released.


Package:  cantor-16.08.2-1.fc25
Old package:  cantor-16.08.1-1.fc25
Summary:  KDE Frontend to Mathematical Software
RPMs: cantor cantor-R cantor-devel cantor-libs python2-cantor 
python3-cantor
Size: 3301252 bytes
Size change:  -14672 bytes
Changelog:
  * Mon Sep 19 2016 Peter Robinson <pbrobin...@fedoraproject.org> 16.08.1-2
  - aarch64 now has LuaJIT

  * Thu Oct 13 2016 Rex Dieter <rdie...@fedoraproject.org> - 16.08.2-1
  - 16.08.2


Package:  chirp-20161018-1.fc25
Old package:  chirp-20160819-1.fc25
Summary:  A tool for programming two-way radio equipment
RPMs: chirp
Size: 1082234 bytes
Size change:  50796 bytes
Changelog:
  * Tue Oct 18 2016 Richard Shaw <hobbes1...@gmail.com> - 20161018-1
  - Update to latest upstream release.


Package:  cjdns-18-3.fc25
Old package:  cjdns-17.4-7.fc25
Summary:  The privacy-friendly network without borders
RPMs: cjdns cjdns-graph cjdns-python cjdns-selinux cjdns-tools
Size: 1404194 bytes
Size change:  28664 bytes
Changelog:
  * Wed Oct 12 2016 Stuart D. Gathman <stu...@gathman.org> 18-1
  - Update to 18 upstream release

  * Fri Oct 14 2016 Stuart D. Gathman <stu...@gathman.org> 18-2
  - Remove Sign.c which uses a private API and isn't needed until supernodes.
  - Use libsodium by default: seems best performance of dynamic libraries

  * Fri Oct 14 2016 Stuart D. Gathman <stu...@gathman.org> 18-3
  - libstdc++ not needed with libsodium


Package:  classified-ads-0.11-2.fc25
Old package:  classified-ads-0.11-1.fc25
Summary:  Classified ads is a program for posting ads online
RPMs: classified-ads
Size: 3158650 bytes
Size change:  -6540 bytes
Changelog:
  * Tue Oct 11 2016 Antti Jarvinen <antti.jarvi...@katiska.org> - 0.11-2
  - Rebuild due to miniupnpc soname change. See fedora bugzilla #1383734.


Package:  devscripts-2.16.8-1.fc25
Old package:  devscripts-2.16.7-1.fc25
Summary:  Scripts fo

Re: Pondering security update time frames

[Stephen John Smoogen]

On 26 October 2016 at 07:33, Florian Weimer  wrote:

> For Fedora, I would suggest to replicate the separate security archive with
> its push mirrors.  The way the Fedora updates repository is updated seems to
> cause far more delays than what is lost due to build delays (the only part
> the embargoed builders could improve).
>

Just to clarify because people seem to think we have push mirrors all
the time. Our mirroring system is a pull mirror system where sites
either copy via http or rsync the files from the master mirrors.
Attempts to put in a push mirroring system have failed mainly because
other than a few sites most mirrors have no interest (or ability) in
running any distribution specific software or allowing some other
service push data to them.




> Florian
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On aarch64:
perl-Data-Alias-1.20-2.fc24.aarch64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.aarch64 requires perl(:MODULE_COMPAT_5.22.1)
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Alien-ROOT

[buildsys]

perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-1.fc26.noarch requires root-core
Please resolve this as soon as possible.

___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[Michael Catanzaro]

On Tue, 2016-10-25 at 09:06 -0700, Adam Williamson wrote:
> That wouldn't really bother me, so I'm only curious, but why do you
> find having a big changelog at the end of the file so annoying? It's
> at
> the end and you pretty much never have to look at it. Is it just
> because it tends to match searches, or what?

Primarily to make scrolling within the document easier. It doesn't
matter if the non-changelog portion of the spec file is very small: you
can scroll with arrow keys or the mouse wheel. But if the non-changelog 
portion of the spec is large, then it's desirable to scroll using
scrollbars to cover more distance. That's only practical if the
changelog is not itself huge.

Maybe this is a silly argument, and sure it's not super important, but
what SUSE has is superior.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Curios - Why python3 is not in critical path?

[Dennis Gilmore]

On martes, 11 de octubre de 2016 10:50:44 AM CDT William Moreno wrote:
> Hello!
> 
> Looking at the pkgdb looks like python3 it is not included in the Fedora
> critical path:
> 
> https://admin.fedoraproject.org/pkgdb/package/rpms/python3/
> https://admin.fedoraproject.org/pkgdb/package/rpms/python/
> 
> In the updates system also python3 is not part of the critical path update:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-d49f8ec161
> 
> I think the critical path in bodhi is important to get enought karma before
> go to stable.
> 
> I have filler a but about that:
> https://bugzilla.redhat.com/show_bug.cgi?id=1383750
> 
> Regards.

It is now, the process to mark packages as critpath is manual and had been 
broken, so not run in awhile. its been fixed and python3 is now critpath

Dennis

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Pavel Raiskup]

On Wednesday, October 26, 2016 1:33:34 PM CEST Florian Weimer wrote:
> Debian does not build from SCM, but directly from maintainer-uploaded 
> source packages, so there is no need to have a private SCM.

Do we have a good marketing for the fact that we are that "superior"
compared to Debian then?  Sounds like a main thing for for distro comparison
article:  It sounds like this is much, *much* more difficult to get malicious
software into distribution (without noticing) for Fedora packager than for
Debian packager, right?

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Pavel Raiskup]

On Wednesday, October 26, 2016 2:03:20 PM CEST Florian Weimer wrote:
> > However, extending Koji to support "hidden builds" is certainly a good
> > idea.
> 
> Trust me, it's not.  Embargoes are against the spirit of Fedora, and a
> general hassle for everyone involved.

Vague argument, sorry.  Please elaborate what's against Fedora.

The "status quo" is bad, our _users_ are the ones who suffer from delays
in CVE fixes.  We should care take about users, in the first place.

> Deploying a lot of infrastructure for the one or two cases per year
> where it comes in handy does not make sense.

That's more than _two cases_ a year and I'm talking about _single_
package, at least I've heard mariadb/mysql guys have it similarly.

Upstream maintainers are *asking us* in advance to report them back
whether the release tarball works for us!  And they would willingly fix
the release tarballs or help us with issues, but we are unable to respond
(that's shame).  Yeah, I'm able to do my local build on x86_64 machine
(and build in i686 mock), but that's everything I can do;  if the aarch64
fails for me, then we'll have nontrivial delay..

Side note:  Really typical for Fedora devel, we always suggest people to
do either of those:
- Do nothing.
- Wait.  Other (in many times unrelated project) will fix this. (== never)
- Deal with that, that's not what Fedora is about.

I'm OK to accept the fact "hidden builds" are not perfect approach, that's
right, but that could be relatively easy for implementation.  Better to have
something in the beginning rather than wait for "expensive feature" which we'll
never have enough manpower for.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Term-Chrome (master). "Import"

[notifications]

ppisar pushed to perl-Term-Chrome (master).  "Import"

http://pkgs.fedoraproject.org/cgit/perl-Term-Chrome.git/commit/?h=master=75ef26c4d9f20b62f522317a27a6d95c6446bde2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Term-Chrome (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Term-Chrome 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Term-Chrome/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Term-Chrome (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-Term-Chrome (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Term-Chrome/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Term-Chrome (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-Term-Chrome (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Term-Chrome/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Term-Chrome (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Term-Chrome 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Term-Chrome/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Jaroslav Reznik]

On Wed, Oct 26, 2016 at 12:23 PM, Pavel Raiskup  wrote:
> On Tuesday, October 25, 2016 7:37:32 PM CEST Kevin Fenzi wrote:
>> > 3. AFAIK Fedora has no means by which it can participate in embargoed
>> > updates.  For this to work, I think there ought to be private git
>> > branches, a way to get Koji to make a private build from a private git
>> > branch, and a way to get private karma on a private update.  Then,
>> > when an embargo is lifted, the packager could merge the private branch
>> > in, the various infrastructure bits could notice that the very same
>> > git commit is now public and permit all of the private builds,
>> > updates, and karma to become public and allow an immediate push to
>> > updates.
>>
>> Yep. Thats a gigantic pile of work there for sure.
>
> That's too vague statement, really.  Can you make a better estimation?

We had this discussion in the past and the result from the Board was
that Board won't block hidden private builds (ticket #144, not sure
it's publicly accessible). That time it was me who created the ticket
on behalf of OpenJDK folks. Of course if someone implements it and we
don't have Board but Council and Council can have different opinion on
this. I was told there was some support for private builds in the past
in our tools but it was removed long time ago as there was no use for
that and it complicated the codebase.

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Florian Weimer]

On 10/26/2016 01:45 PM, Neal Gompa wrote:


For Fedora, I would suggest to replicate the separate security archive with
its push mirrors.  The way the Fedora updates repository is updated seems to
cause far more delays than what is lost due to build delays (the only part
the embargoed builders could improve).



There's no point to this, since our updateinfo metadata includes the
classifications,


This doesn't help if the data is published only once per day.


and the Debian/Ubuntu approach means that the same
package needs to be pushed to both the security repository and the
regular updates one. This is not great for keeping things sane for
mirrors.


Of course, the end user systems would have the security repository 
enabled, so timely pushes to the updates repository are not needed 
anymore to make updates available.


It should be possible to emulate this setup with a COPR repository even 
today.



However, extending Koji to support "hidden builds" is certainly a good
idea.


Trust me, it's not.  Embargoes are against the spirit of Fedora, and a 
general hassle for everyone involved.  Deploying a lot of infrastructure 
for the one or two cases per year where it comes in handy does not make 
sense.


Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Josh Boyer]

On Wed, Oct 26, 2016 at 7:45 AM, Neal Gompa  wrote:
> On Wed, Oct 26, 2016 at 7:33 AM, Florian Weimer  wrote:
>>
>>
>> Debian has a completely separate installation of its equivalent to Koji (the
>> dak part, the builders are separate from archive management). Nowadays, it's
>> source code is mostly up-to-date to what the main archive uses, but there
>> are still lingering data synchronization issues.
>
> That's a lot of work for not a lot of benefit. Our Koji system should
> be able to be extended to handle these extra use-cases. And as it is,
> we're trying to get rid of duplicate Koji instances.
>
>>
>> For Fedora, I would suggest to replicate the separate security archive with
>> its push mirrors.  The way the Fedora updates repository is updated seems to
>> cause far more delays than what is lost due to build delays (the only part
>> the embargoed builders could improve).
>>
>
> There's no point to this, since our updateinfo metadata includes the
> classifications, and the Debian/Ubuntu approach means that the same
> package needs to be pushed to both the security repository and the
> regular updates one. This is not great for keeping things sane for
> mirrors.
>
> However, extending Koji to support "hidden builds" is certainly a good
> idea. From the SCM side, I'm not sure if gitolite supports making
> private branches. At least it should be possible to give each package
> a shadow git repository in a separate namespace (as mentioned earlier)
> that would be private for doing these kinds of builds and releases.
> Upon merge to the public repository, the builds could be marked public
> to Koji (since the commit hashes should remain the same post-merge
> anyway, we can track using that).

This is directed at the whole thread, not Neal.

Here is the problem with all of this.  We have plenty of ideas, but
nobody willing to do the work.  So you can all continue to throw out
ideas and question estimates, but until someone signs up to actually
start coding things across whatever stacks are needed, nothing will
change.

If anyone is really interested in solving this problem, it's time to
roll up your sleeves.  We need code now, not ideas.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Neal Gompa]

On Wed, Oct 26, 2016 at 7:33 AM, Florian Weimer  wrote:
>
>
> Debian has a completely separate installation of its equivalent to Koji (the
> dak part, the builders are separate from archive management). Nowadays, it's
> source code is mostly up-to-date to what the main archive uses, but there
> are still lingering data synchronization issues.

That's a lot of work for not a lot of benefit. Our Koji system should
be able to be extended to handle these extra use-cases. And as it is,
we're trying to get rid of duplicate Koji instances.

>
> For Fedora, I would suggest to replicate the separate security archive with
> its push mirrors.  The way the Fedora updates repository is updated seems to
> cause far more delays than what is lost due to build delays (the only part
> the embargoed builders could improve).
>

There's no point to this, since our updateinfo metadata includes the
classifications, and the Debian/Ubuntu approach means that the same
package needs to be pushed to both the security repository and the
regular updates one. This is not great for keeping things sane for
mirrors.

However, extending Koji to support "hidden builds" is certainly a good
idea. From the SCM side, I'm not sure if gitolite supports making
private branches. At least it should be possible to give each package
a shadow git repository in a separate namespace (as mentioned earlier)
that would be private for doing these kinds of builds and releases.
Upon merge to the public repository, the builds could be marked public
to Koji (since the commit hashes should remain the same post-merge
anyway, we can track using that).



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: Ticket 49018 - Fix runUpgrade compatibility with RHEL 6

[Simon Pichugin]

Hi team,

please review my fix for lib389:
https://fedorahosted.org/389/ticket/49018
https://fedorahosted.org/389/attachment/ticket/49018/0001-Fix-runUpgrade-tool-issues.patch

Thanks,
Simon


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Florian Weimer]

On 10/26/2016 12:23 PM, Pavel Raiskup wrote:

On Tuesday, October 25, 2016 7:37:32 PM CEST Kevin Fenzi wrote:

3. AFAIK Fedora has no means by which it can participate in embargoed
updates.  For this to work, I think there ought to be private git
branches, a way to get Koji to make a private build from a private git
branch, and a way to get private karma on a private update.  Then,
when an embargo is lifted, the packager could merge the private branch
in, the various infrastructure bits could notice that the very same
git commit is now public and permit all of the private builds,
updates, and karma to become public and allow an immediate push to
updates.


Yep. Thats a gigantic pile of work there for sure.


That's too vague statement, really.  Can you make a better estimation?  As
far as I understand, there are processes in Debian which allow them
preparing CVE builds so they are able to provide "testing" builds to users
immediately after the public announcement.


Debian has a completely separate installation of its equivalent to Koji 
(the dak part, the builders are separate from archive management). 
Nowadays, it's source code is mostly up-to-date to what the main archive 
uses, but there are still lingering data synchronization issues.


Debian does not build from SCM, but directly from maintainer-uploaded 
source packages, so there is no need to have a private SCM.


The security archive is separate as well, and it is served by a 
Debian-maintained push mirror network, unlike the main archive, where 
most users use third-party mirrors.


For Fedora, I would suggest to replicate the separate security archive 
with its push mirrors.  The way the Fedora updates repository is updated 
seems to cause far more delays than what is lost due to build delays 
(the only part the embargoed builders could improve).


Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM %changelog?

[Panu Matilainen]

On 10/25/2016 09:35 PM, David Shea wrote:

Please, no, don't do that. RPM is a standard


lol.

 * The representation of file names in package headers changed in rpm-4.0.
 * Originally, file names were stored as an array of absolute paths.
 * In rpm-4.0, file names are stored as separate arrays of dirname's and
 * basename's, * with a dirname index to associate the correct dirname
 * with each basname.

That's just my personal favorite. The RPM standard is whatever RPM is doing 
right now.


Well then, who exactly should set the RPM standard if not RPM itself?

FWIW, the change in question occurred in the transition from RPM V3 
packages to V4 packages which involved much more than just file name 
storage and RPM still transparently handles both package versions 
sixteen years after the change. I'm not sure what's so funny about that.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Params-ValidationCompiler (master). "Break build cycle: perl-Moose ??? perl-DateTime ??? perl-Params-ValidationCompiler"

[notifications]

From 6313c66174aa521f093770a3931dadbaa0456f1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 26 Oct 2016 13:21:06 +0200
Subject: =?UTF-8?q?Break=20build=20cycle:=20perl-Moose=20=E2=86=92=20perl-?=
 =?UTF-8?q?DateTime=20=E2=86=92=20perl-Params-ValidationCompiler?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 perl-Params-ValidationCompiler.spec | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/perl-Params-ValidationCompiler.spec 
b/perl-Params-ValidationCompiler.spec
index fea2bf1..c518250 100644
--- a/perl-Params-ValidationCompiler.spec
+++ b/perl-Params-ValidationCompiler.spec
@@ -1,6 +1,6 @@
 Name:  perl-Params-ValidationCompiler
 Version:   0.13
-Release:   3%{?dist}
+Release:   4%{?dist}
 Summary:   Build an optimized subroutine parameter validator once, use it 
forever
 License:   Artistic 2.0
 URL:   http://search.cpan.org/dist/Params-ValidationCompiler/
@@ -37,8 +37,13 @@ BuildRequires:   perl(Const::Fast)
 BuildRequires: perl(CPAN::Meta) >= 2.120900
 BuildRequires: perl(CPAN::Meta::Prereqs)
 BuildRequires: perl(Hash::Util)
+%if !%{defined perl_bootstrap}
+# Build cycle: perl-Moose → perl-DateTime → perl-Params-ValidationCompiler
 BuildRequires: perl(Moose::Util::TypeConstraints)
+# Build cycle: perl-Type-Tiny → perl-Moose → perl-DateTime →
+# perl-Params-ValidationCompiler
 BuildRequires: perl(Types::Standard)
+%endif
 # Dependencies
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:  perl(Sub::Util) >= 1.40
@@ -70,6 +75,9 @@ make test
 %{_mandir}/man3/Params::ValidationCompiler::Exceptions.3*
 
 %changelog
+* Wed Oct 26 2016 Petr Pisar  - 0.13-4
+- Break build cycle: perl-Moose → perl-DateTime → 
perl-Params-ValidationCompiler
+
 * Mon Sep 19 2016 Paul Howarth  - 0.13-3
 - Drop unused BR: findutils (#1377252)
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Params-ValidationCompiler.git/commit/?h=master=6313c66174aa521f093770a3931dadbaa0456f1f
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Josh Boyer]

On Tue, Oct 25, 2016 at 10:00 PM, Bojan Smojver  wrote:
> If there existed updates-urgent and updates-urgent-testing repositories
> for packages like kernel (example: Dirty COW patch-to-testing wait time
> was rather long; note that some people cannot install unsigned kernel
> packages from koji due to grub2 bugs), FF etc., maybe these large (and

That part doesn't make sense.  If the kernel is built in koji, it has
been signed with the key we use for secure boot purposes.  The RPM
signature is separate and doesn't impact the grub2 issue you mention.
So official builds in koji of the kernel are usable by anyone.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Pavel Raiskup]

On Tuesday, October 25, 2016 7:37:32 PM CEST Kevin Fenzi wrote:
> > 3. AFAIK Fedora has no means by which it can participate in embargoed
> > updates.  For this to work, I think there ought to be private git
> > branches, a way to get Koji to make a private build from a private git
> > branch, and a way to get private karma on a private update.  Then,
> > when an embargo is lifted, the packager could merge the private branch
> > in, the various infrastructure bits could notice that the very same
> > git commit is now public and permit all of the private builds,
> > updates, and karma to become public and allow an immediate push to
> > updates.
> 
> Yep. Thats a gigantic pile of work there for sure.

That's too vague statement, really.  Can you make a better estimation?  As
far as I understand, there are processes in Debian which allow them
preparing CVE builds so they are able to provide "testing" builds to users
immediately after the public announcement.

Seems like we need to:

  [x] have another git repository, say prepared-rpms/PACKAGE
  - that's clone of rpms/PACKAGE
  - permission bits inherited from rpms/PACKAGE, but not publicly
available for cloning, + security guys

  [x] Making sure that only one repo is writeable:
  - if prepared-rpms/PKG exists, rpms/PKG is read only
  - the info "why" it is read-only shouldn't be public information

  [x] Support for "private" builds in koji. Maintainer should be able to re-tag
  security/prepared build into public tag once thing is publicly announced.

  [x] Nothing changes in bodhi, if we consder 'testing' to be enough for
  security purpose.  But yeah, there could be 'testing-security' optionally
  available for users...

Note that this is not security-only.  That's the reason for
'prepared-rpms' prefix, e.g. if we had something like that in Fedora, we
could test/use this feature several times a year as we are informed by
PostgreSQL upstream about upcoming releases, we have tarball in advance
...  but now it is shame we are not able to announce updates immediately
with upstream.  We are not allowed to share the tarballs with upstream before
announcement, of course.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox 49.0.2

[Martin Stransky]

Thanks for pointing it here, I miss that minor update. Btw. a new #BZ at 
bugzilla.redhat.com would work even better.


There are two security bugs marked as "High" which means "Moderate" in 
Fedora terms. The big ones has "Critical" rating and there's none fixed 
in this release.


AFAIK the main reason for 49.0.(1|2) releases were:

- the async rendering (mozbz#1307108)
- the d3d9 fallback (mozbz#1309330)

which are not so important for Fedora so we're going to ship the 49.0.2 
release and ship 50.0.


ma.

On 10/25/2016 09:23 PM, Bojan Smojver wrote:

Could someone with access please build this version of FF. Apparently,
it's a security release.

Thanks,


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Unicode-Collate (f23). "1.16 bump"

[notifications]

From b1c6b13e4bdd3f1b0a07db1b802c4c7f4696daef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 26 Oct 2016 11:02:08 +0200
Subject: 1.16 bump

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

diff --git a/.gitignore b/.gitignore
index ef6f66a..a223759 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Unicode-Collate-1.12.tar.gz
 /Unicode-Collate-1.14.tar.gz
 /Unicode-Collate-1.15.tar.gz
+/Unicode-Collate-1.16.tar.gz
diff --git a/perl-Unicode-Collate.spec b/perl-Unicode-Collate.spec
index 3e37318..7fe75b2 100644
--- a/perl-Unicode-Collate.spec
+++ b/perl-Unicode-Collate.spec
@@ -1,5 +1,5 @@
 Name:   perl-Unicode-Collate
-Version:1.15
+Version:1.16
 Release:1%{?dist}
 Summary:Unicode Collation Algorithm
 # Collate/allkeys.txt:  Unicode (the file contains a link to
@@ -65,6 +65,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Oct 26 2016 Petr Pisar  - 1.16-1
+- 1.16 bump
+
 * Mon Oct 24 2016 Petr Pisar  - 1.15-1
 - License corrected to ((GPL+ or Artistic) and Unicode)
 - 1.15 bump
diff --git a/sources b/sources
index 5c9f467..df70f08 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-427e46ed8134251d02f1e5b94940527e  Unicode-Collate-1.15.tar.gz
+95df877960af69fcd4abf1515818b7e5  Unicode-Collate-1.16.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Unicode-Collate.git/commit/?h=f23=b1c6b13e4bdd3f1b0a07db1b802c4c7f4696daef
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Unicode-Collate (f24). "1.16 bump"

[notifications]

From 9e4e6de53635b49a63889ccf62adfa22ad377388 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 26 Oct 2016 11:02:08 +0200
Subject: 1.16 bump

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

diff --git a/.gitignore b/.gitignore
index ef6f66a..a223759 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Unicode-Collate-1.12.tar.gz
 /Unicode-Collate-1.14.tar.gz
 /Unicode-Collate-1.15.tar.gz
+/Unicode-Collate-1.16.tar.gz
diff --git a/perl-Unicode-Collate.spec b/perl-Unicode-Collate.spec
index c49a1fd..a076d5b 100644
--- a/perl-Unicode-Collate.spec
+++ b/perl-Unicode-Collate.spec
@@ -1,5 +1,5 @@
 Name:   perl-Unicode-Collate
-Version:1.15
+Version:1.16
 Release:1%{?dist}
 Summary:Unicode Collation Algorithm
 # Collate/allkeys.txt:  Unicode (the file contains a link to
@@ -65,6 +65,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Oct 26 2016 Petr Pisar  - 1.16-1
+- 1.16 bump
+
 * Mon Oct 24 2016 Petr Pisar  - 1.15-1
 - License corrected to ((GPL+ or Artistic) and Unicode)
 - 1.15 bump
diff --git a/sources b/sources
index 5c9f467..df70f08 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-427e46ed8134251d02f1e5b94940527e  Unicode-Collate-1.15.tar.gz
+95df877960af69fcd4abf1515818b7e5  Unicode-Collate-1.16.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Unicode-Collate.git/commit/?h=f24=9e4e6de53635b49a63889ccf62adfa22ad377388
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1388282] perl-Unicode-Collate-1.16 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Unicode-Collate-1.16-1
   ||.fc26



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Unicode-Collate (f25). "1.16 bump"

[notifications]

From 856686ecc7c5013440dab30b11067ac81fd6d60f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 26 Oct 2016 11:02:08 +0200
Subject: 1.16 bump

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

diff --git a/.gitignore b/.gitignore
index ef6f66a..a223759 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Unicode-Collate-1.12.tar.gz
 /Unicode-Collate-1.14.tar.gz
 /Unicode-Collate-1.15.tar.gz
+/Unicode-Collate-1.16.tar.gz
diff --git a/perl-Unicode-Collate.spec b/perl-Unicode-Collate.spec
index 388a615..0675344 100644
--- a/perl-Unicode-Collate.spec
+++ b/perl-Unicode-Collate.spec
@@ -1,5 +1,5 @@
 Name:   perl-Unicode-Collate
-Version:1.15
+Version:1.16
 Release:1%{?dist}
 Summary:Unicode Collation Algorithm
 # Collate/allkeys.txt:  Unicode (the file contains a link to
@@ -65,6 +65,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Oct 26 2016 Petr Pisar  - 1.16-1
+- 1.16 bump
+
 * Mon Oct 24 2016 Petr Pisar  - 1.15-1
 - 1.15 bump
 
diff --git a/sources b/sources
index 5c9f467..df70f08 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-427e46ed8134251d02f1e5b94940527e  Unicode-Collate-1.15.tar.gz
+95df877960af69fcd4abf1515818b7e5  Unicode-Collate-1.16.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Unicode-Collate.git/commit/?h=f25=856686ecc7c5013440dab30b11067ac81fd6d60f
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar uploaded Unicode-Collate-1.16.tar.gz for perl-Unicode-Collate

[notifications]

95df877960af69fcd4abf1515818b7e5  Unicode-Collate-1.16.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Unicode-Collate/Unicode-Collate-1.16.tar.gz/md5/95df877960af69fcd4abf1515818b7e5/Unicode-Collate-1.16.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[nicolas . mailhot]

- Mail original -
De: "Adam Williamson" 

> Sure, it's arbitrary. Arbitrary doesn't necessarily mean 'bad'. The
> 96dpi consensus worked perfectly well: hardware manufacturers knew what
> sizes and resolutions to make their monitors

That's pretty disingenious. Hardware manufacturers have not produced 96dpi 
laptops for years and the same people that worship the 96 dpi holy cow will 
tell you desktops are deads and laptops the only present or future.

96dpi is a convenient "consensus" to avoid fixing the stack. And then newer 
entrants like Apple or Google show up having fixed *their* stack with dips and 
hidpi, and the emperor is naked. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Devel-Gladiator (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-Devel-Gladiator 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Devel-Gladiator/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Devel-Gladiator (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-Devel-Gladiator (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Devel-Gladiator/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Devel-Gladiator (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Devel-Gladiator 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Devel-Gladiator/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Devel-Gladiator (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Devel-Gladiator 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Devel-Gladiator/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Test-Is (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Test-Is (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Test-Is/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Test-Is (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-Test-Is (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Test-Is/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Test-Is (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-Test-Is (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Test-Is/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Test-Is (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Test-Is (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Test-Is/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Filter-Encoding (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'approveacls' permission on perl-Filter-Encoding 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Filter-Encoding/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Filter-Encoding (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Filter-Encoding 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Filter-Encoding/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Filter-Encoding (master) to 'Approved'

[notifications]

ppisar changed jplesnik's 'commit' permission on perl-Filter-Encoding (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Filter-Encoding/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Filter-Encoding (master) to 'Approved'

[notifications]

ppisar changed perl-sig's 'watchcommits' permission on perl-Filter-Encoding 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Filter-Encoding/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Firefox 49.0.2

[Greg Evenden]

> On 10/26/2016 02:45 AM, Bojan Smojver wrote:
> 
> And it seems that Fedora builds do not enable e10s, so the cache leak 
> might actually affect users.
> 
> Florian
i dont think e10s are actually stable enough for users to actually use, but as 
i said above, i really dont think 49.0.2 warrants building  since 50 is gonna 
be released on the 8th https://wiki.mozilla.org/RapidRelease/Calendar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Martin Bříza]

On Wed, 26 Oct 2016 09:20:30 +0200, Adam Williamson  
 wrote:



On Wed, 2016-10-26 at 08:30 +0200, nicolas.mail...@laposte.net wrote:

But, GTK core maintainers have always insisted those didn't exist
(just like they insisted on hardcoding 96 dpi, on the eve of Apple
showing the world it was arbitrary and obsolete).


...by releasing displays carefully tuned to look best at a precise
integer multiple of 96dpi? Not really great support for your theory.

Sure, it's arbitrary. Arbitrary doesn't necessarily mean 'bad'. The
96dpi consensus worked perfectly well: hardware manufacturers knew what
sizes and resolutions to make their monitors, and font designers (and
UI designers) knew that when they had to make a tricky decision about
how to tweak something, they should favour whatever choice makes it
look good at 96dpi. Which is really important when you're designing
something as finicky at a font, at a resolution as low as 96dpi; the
question of which point size you choose as the cutoff for rendering a
simple line as 1 pixel wide or 2 pixels wide is extremely important,
for e.g.

I used to go for the the 'everything should be perfectly resolution
independent!' argument, because it seems intellectually satisfying from
some sort of theoretical engineering point of view, but I find the
argument that it's not really the most *practical* way to do things
pretty convincing.

Even now, the consensus mostly survives; most hardware is designed to
work best at 96dpi or an integer multiple thereof. Awkward things like
13" 1080p displays are still in a distinct minority.


As a guy with a few screens that can be considered hidpi (3k on 13" and 4k  
on 23"), I have to say just integer scaling is just not enough, especially  
if you can't setup the scaling factor.


For example the 23" 4k display is NOT scaled, despite the fact I've got a  
fullHD display of the same size, that results in having windows on the 4k  
screen that are half as small as the ones on the fullHD display. Meanwhile  
the 3k 13" display actually is scaled (don't know the factor but I guess  
2x) and everything is way too large to my taste.


Scaling by an arbitrary float number may be too much but I think trying to  
mimic Windows in this wouldn't be a bad idea. There you can set (manually,  
despite there's an initial estimation of what you'd probably want) scaling  
to be 1x, 1.25x, 1.5x, 1.75x, etc. This still leaves room for glitches but  
I think on toolkit level, it's possible to tweak the layouts, font  
rendering,... just for those values.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1388782] bugzilla rejected automatically generated bug report claiming spam

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 CC|emman...@seyman.fr, |huiw...@redhat.com,
   |perl-devel@lists.fedoraproj |qg...@redhat.com
   |ect.org |
  Component|bugzilla|Creating/Changing Bugs
Version|25  |4.4
   Assignee|ita...@ispbrasil.com.br |hss-ied-b...@redhat.com
Product|Fedora  |Bugzilla
 QA Contact|extras...@fedoraproject.org |tools-b...@redhat.com



--- Comment #1 from Emmanuel Seyman  ---
This looks specific to bugzilla.redhat.com .

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1388782] New: bugzilla rejected automatically generated bug report claiming spam

[bugzilla]

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

Bug ID: 1388782
   Summary: bugzilla rejected automatically generated bug report
claiming spam
   Product: Fedora
   Version: 25
 Component: bugzilla
  Severity: urgent
  Assignee: ita...@ispbrasil.com.br
  Reporter: grgo...@yahoo.com
QA Contact: extras...@fedoraproject.org
CC: bazanlui...@gmail.com, emman...@seyman.fr,
ita...@ispbrasil.com.br,
perl-devel@lists.fedoraproject.org



Created attachment 1214200
  --> https://bugzilla.redhat.com/attachment.cgi?id=1214200=edit
saved bug report from bug report wizard on fedora 25 system. bugzilla claimes
that this report contains spam.

Description of problem:
start of firefox caused segfault in KWin. during the wizzard processing I got a
message that the report contains spam. see enclosed bug report.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Adam Williamson]

On Wed, 2016-10-26 at 08:30 +0200, nicolas.mail...@laposte.net wrote:
> But, GTK core maintainers have always insisted those didn't exist
> (just like they insisted on hardcoding 96 dpi, on the eve of Apple
> showing the world it was arbitrary and obsolete).

...by releasing displays carefully tuned to look best at a precise
integer multiple of 96dpi? Not really great support for your theory.

Sure, it's arbitrary. Arbitrary doesn't necessarily mean 'bad'. The
96dpi consensus worked perfectly well: hardware manufacturers knew what
sizes and resolutions to make their monitors, and font designers (and
UI designers) knew that when they had to make a tricky decision about
how to tweak something, they should favour whatever choice makes it
look good at 96dpi. Which is really important when you're designing
something as finicky at a font, at a resolution as low as 96dpi; the
question of which point size you choose as the cutoff for rendering a
simple line as 1 pixel wide or 2 pixels wide is extremely important,
for e.g.

I used to go for the the 'everything should be perfectly resolution
independent!' argument, because it seems intellectually satisfying from
some sort of theoretical engineering point of view, but I find the
argument that it's not really the most *practical* way to do things
pretty convincing.

Even now, the consensus mostly survives; most hardware is designed to
work best at 96dpi or an integer multiple thereof. Awkward things like
13" 1080p displays are still in a distinct minority.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Desktop application major update (darktable)

[Germano Massullo]

Il 25/10/2016 19:07, Kevin Fenzi ha scritto:
> Well, we need more information (or at least I do): 
>
> * Is 1.x still supported by upstream?
No
> * is 1.x still supported by anyone else (rhel, other lts distros,
>   people you could work with on backporting fixes). 
I don't think so, and I have never seen a new 1.x release since
darktable 2.x has been released
> * Are there any known 1.x security issues?
No
> * Is the upgrade from 1.x to 2.x transparent for the user? ie, would
>   they have to do any manual steps to move config? or is that all done
>   by the application?
No action is required by the user
> * Is the "user experence" different between 1.x and 2.x?
It is almost the same, even if there are more features on 2.x
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: F26 proposed release tooling changes

[Alexander Bokovoy]

On ti, 25 loka 2016, Ken Dreyer wrote:

On Tue, Oct 25, 2016 at 3:00 PM, Dennis Gilmore  wrote:

On martes, 25 de octubre de 2016 2:42:15 PM CDT Ken Dreyer wrote:

Hi Amanda,

I'm curious about this change: "Kerberos support in koji, fedpkg, OSBS "

Is koji.fedoraproject.org is going to eventually stop supporting TLS
authentication, and we'll have a Fedora-project-wide Kerberos
infrastructure instead?


there will be kerberos auth for koji and lookaise cache, if it will be project
wide or not I am not sure that is decided yet.


Thanks Dennis.

I'm curious about this because most organizations do not expose their
KDCs directly to the internet. As I understand it, it's possible for a
passive attacker to sniff the TGT exchange and brute-force a password,
whereas this attack scenario is not possible with Koji's current HTTPS
client cert authentication.

We implemented HTTPS proxying of the Kerberos protocol, based on
MS-KKDCP specification. It is in MIT Kerberos 1.13+.

--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[nicolas . mailhot]

- Mail original -
De: "Andrew Lutomirski" 

> (Projectors are probably a lost cause and perhaps it should be purely
> a function of resolution.)

Even for projectors it would be rather easy since video organisations (SMPTE, 
THX, ISF, etc) publish strict guidelines on the optimal viewing distance to use 
in common video modes, and any pro or semi-pro setup will honor them. Just 
Google "smpte projector distance" they're hardy top secret.

But, GTK core maintainers have always insisted those didn't exist (just like 
they insisted on hardcoding 96 dpi, on the eve of Apple showing the world it 
was arbitrary and obsolete).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org