date:20180716

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

Bug 1467608 Summary: CVE-2017-10788 CVE-2017-10789 perl-DBD-MySQL: various 
flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1467608

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|EOL |---



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/LESRVP3WIZV55N7JJG46YVUZ3HXEPQKO/

[Bug 1467600] CVE-2017-10788 perl-DBD-MySQL: Use-after-free when calling mysql_stmt_error() after mysql_stmt_close()

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

Bug 1467608 Summary: CVE-2017-10788 CVE-2017-10789 perl-DBD-MySQL: various 
flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1467608

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|EOL |---



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/7OLO5MD6A43MJBRIMAQ44VDASDV6OKI7/

[Bug 1467608] CVE-2017-10788 CVE-2017-10789 perl-DBD-MySQL: various flaws [fedora-all]

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

Huzaifa S. Sidhpurwala  changed:

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|EOL |---
   Keywords||Reopened



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/J2PLVKGJQW7PULMCX7YY2SB4WRW2DTHM/

[EPEL-devel] Re: Package Updates: python-passlib

On 16 July 2018 at 20:15, Alcantar, Miguel  wrote:
> To reiterate what was said:  There will be no further updates to the
> python-passlib package which lives in the EPEL repo for EL7.
>
> Is that correct?  Thanks.
>

The terms 'further updates' can mean different things in this context
so I will try to clarify even further.

A. Further updates means moving it to a version newer than what is in
RHEL. The answer here is no as EPEL does not replace packages that Red
Hat ships in the base OS, Extras, and HA channels.
B. Further updates means moving it up to the version that is in RHEL
but not replacing it. That is up to the maintainer. They can either do
so or we can retire it since it will cause build problems.
C. Further updates means removing it from EPEL. This is probably the
most likely scenario.

-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/H43W7SY4B5NPQMYCQIWRV35OGX7QSS3V/

Re: Release criteria proposal: installing / removing software

2018-07-16 Thread Adam Williamson

On Thu, 2018-06-14 at 17:31 -0700, Adam Williamson wrote:
> On Thu, 2018-06-14 at 19:25 -0400, Matthew Miller wrote:
> > On Thu, Jun 14, 2018 at 03:47:25PM -0700, Adam Williamson wrote:
> > > There's a footnote explaining that already:
> > 
> > Ah, that clears it up. Thanks :)
> > 
> > > as explained there, we actually *specifically* added this wording
> > > because there was a bug with packages from modules being selected as
> > > updates when the modules they were from weren't installed, and we felt 
> > > it was best to have the criterion explicitly cover this kind of
> > > situation.
> > 
> > Hmmm; this *could* apply to install, too -- for example, installing a
> > package from a module that's not supposed to be enabled, or failing to
> > from one that is.
> 
> Hum, that's a decent point. /me continues to cogitate

So, having cogitated, how about this wording?

Basic:

"The installed system must be able appropriately to install, remove,
and update software with the default console tool for the relevant
software type (e.g. default console package manager). This includes
downloading of packages to be installed/updated."

Beta:

"The installed system must be able appropriately to install, remove,
and update software with the default tool for the relevant software
type in all release-blocking desktops (e.g. default graphical package
manager). This includes downloading of packages to be
installed/updated."

Grammatically, this means the "appropriately" applies to all three
actions ("install, remove and update").

The footnote would read:

"Appropriately?

''Appropriately'' means that the relevant software mechanism(s) for any
given deployment must choose the software to be installed, updated or
removed in ways that are broadly in line with the user's intent and
typical expectations, and the project's intent as to which software
should be provided from which repositories etc.

To give a specific example of why this wording is included, there was
previously a case where newer package versions from modules were being
installed as 'updates' to systems which did not have those modules
installed, only the package with the same name from the non-modular
system repositories. This would be an example of 'inappropriate'
updating that violated this criterion. Other examples might include
installing packages from the wrong module stream, or failing to include
available updates from an enabled official repository."

Does that sound good to everyone? Thanks!
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ESFHPARCUBI5UJMHCW774XSHSY4FXN3U/

[Bug 1601648] New: perl-Net-Amazon-S3-0.84 is available

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

Bug ID: 1601648
   Summary: perl-Net-Amazon-S3-0.84 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-Amazon-S3
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
rr...@redhat.com



Latest upstream release: 0.84
Current version/release in rawhide: 0.83-1.fc29
URL: http://search.cpan.org/dist/Net-Amazon-S3/

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

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

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

Based on the information from anitya: 
https://release-monitoring.org/project/6573/

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/FUE2PYTD62HRYE2IRJHA6C2MHHPN5IKR/

[EPEL-devel] Re: Package Updates: python-passlib

2018-07-16 Thread Alcantar, Miguel

To reiterate what was said:  There will be no further updates to the 
python-passlib package which lives in the EPEL repo for EL7.

Is that correct?  Thanks.


From: Stephen John Smoogen 
Sent: Monday, July 16, 2018 5:04:04 PM
To: EPEL Development List
Subject: [EPEL-devel] Re: Package Updates: python-passlib

On 16 July 2018 at 19:28, Alcantar, Miguel  wrote:
> We use RHEL Server and Workstation x86_64
>

So in this case the RHEL version would be as new as we are going to
move to. The maintainer would need to look at copying the version that
was in RHEL-7 and make it with an NVR which is less than RHEL's for
the 2 platforms we don't have python-passlib. We would not be
upgrading to a newer version than that if that makes sense.

> 
> From: Stephen John Smoogen 
> Sent: Monday, July 16, 2018 4:21:10 PM
> To: EPEL Development List
> Subject: [EPEL-devel] Re: Package Updates: python-passlib
>
> On 16 July 2018 at 18:44, Alcantar, Miguel  wrote:
>> epel-devel,
>>
>>
>> The following package is included in RHEL Server:
>> python-passlib-1.6.5-2.el7
>>
>> The current EPEL version is older:  python-passlib-1.6.2-2.el7
>>
>> When will this package be updated?
>>
>
> This looks to be one of those packages which are only in EPEL for
> users of the aarch64 and ppc64 architectures. Which platform do you
> need it for?
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/WQQPVT7OGBMRQOIXF73OHYNIS3H46OHJ/
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/VMG5JNSV4ROIAR2QDZQVS5SW2SAUB4CS/
>



--
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/LWRSVNRVNT2ODQRJX5DZIAWUXUBPEKHS/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/TEXQDV4NZ3XIUK2SZBKTWRZ7LWQBQ5F3/

[EPEL-devel] Re: Package Updates: python-passlib

On 16 July 2018 at 19:28, Alcantar, Miguel  wrote:
> We use RHEL Server and Workstation x86_64
>

So in this case the RHEL version would be as new as we are going to
move to. The maintainer would need to look at copying the version that
was in RHEL-7 and make it with an NVR which is less than RHEL's for
the 2 platforms we don't have python-passlib. We would not be
upgrading to a newer version than that if that makes sense.

> 
> From: Stephen John Smoogen 
> Sent: Monday, July 16, 2018 4:21:10 PM
> To: EPEL Development List
> Subject: [EPEL-devel] Re: Package Updates: python-passlib
>
> On 16 July 2018 at 18:44, Alcantar, Miguel  wrote:
>> epel-devel,
>>
>>
>> The following package is included in RHEL Server:
>> python-passlib-1.6.5-2.el7
>>
>> The current EPEL version is older:  python-passlib-1.6.2-2.el7
>>
>> When will this package be updated?
>>
>
> This looks to be one of those packages which are only in EPEL for
> users of the aarch64 and ppc64 architectures. Which platform do you
> need it for?
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/WQQPVT7OGBMRQOIXF73OHYNIS3H46OHJ/
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/VMG5JNSV4ROIAR2QDZQVS5SW2SAUB4CS/
>



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/LWRSVNRVNT2ODQRJX5DZIAWUXUBPEKHS/

[EPEL-devel] Re: Package Updates: python-passlib

On 16 July 2018 at 19:31, Jason L Tibbitts III  wrote:
>> "SJS" == Stephen John Smoogen  writes:
>
> SJS> This looks to be one of those packages which are only in EPEL for
> SJS> users of the aarch64 and ppc64 architectures.
>
> I wonder how you can tell.  The specfile doesn't indicate anything about
> it.
>
>  - J<

We download all the 'main' repos and see which ones it was in: x86_64, ppc64le

[smooge@batcave01 rhel7]$ ls -1 ./*/rhel-7*extras-rpms/Packages/python-passlib*
./ppc64le/rhel-7-for-powerle-extras-rpms/Packages/python-passlib-1.6.5-2.el7.noarch.rpm
./x86_64/rhel-7-server-extras-rpms/Packages/python-passlib-1.6.5-2.el7.noarch.rpm

The aarch64 and ppc64 trees dont' have it. It also shows up in the Red
Hat Open Stack 13 tree with an even newer version but we would only
look at updating python-passlib to 1.6.5-1.9? in ppc64 and aarch64
using the python-passlib-1.6.5-2 src.rpm from centos.

-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/JJWXJQH4HY2MWDQTWHK75GLQIOYK6OQL/

[EPEL-devel] Re: Package Updates: python-passlib

2018-07-16 Thread Jason L Tibbitts III

> "SJS" == Stephen John Smoogen  writes:

SJS> This looks to be one of those packages which are only in EPEL for
SJS> users of the aarch64 and ppc64 architectures.

I wonder how you can tell.  The specfile doesn't indicate anything about
it.

 - J<
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/RXRWUPJN4QGZYKKW6CCVQ6Q7T6BWFZOB/

[EPEL-devel] Re: Package Updates: python-passlib

2018-07-16 Thread Alcantar, Miguel

We use RHEL Server and Workstation x86_64


From: Stephen John Smoogen 
Sent: Monday, July 16, 2018 4:21:10 PM
To: EPEL Development List
Subject: [EPEL-devel] Re: Package Updates: python-passlib

On 16 July 2018 at 18:44, Alcantar, Miguel  wrote:
> epel-devel,
>
>
> The following package is included in RHEL Server:
> python-passlib-1.6.5-2.el7
>
> The current EPEL version is older:  python-passlib-1.6.2-2.el7
>
> When will this package be updated?
>

This looks to be one of those packages which are only in EPEL for
users of the aarch64 and ppc64 architectures. Which platform do you
need it for?



--
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/WQQPVT7OGBMRQOIXF73OHYNIS3H46OHJ/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/VMG5JNSV4ROIAR2QDZQVS5SW2SAUB4CS/

[EPEL-devel] Re: Package Updates: python-passlib

On 16 July 2018 at 18:44, Alcantar, Miguel  wrote:
> epel-devel,
>
>
> The following package is included in RHEL Server:
> python-passlib-1.6.5-2.el7
>
> The current EPEL version is older:  python-passlib-1.6.2-2.el7
>
> When will this package be updated?
>

This looks to be one of those packages which are only in EPEL for
users of the aarch64 and ppc64 architectures. Which platform do you
need it for?



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/WQQPVT7OGBMRQOIXF73OHYNIS3H46OHJ/

[EPEL-devel] Package Updates: python-passlib

2018-07-16 Thread Alcantar, Miguel

epel-devel,

The following package is included in RHEL Server:  python-passlib-1.6.5-2.el7

The current EPEL version is older:  python-passlib-1.6.2-2.el7

When will this package be updated?

Thank you,
Miguel

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/CYOLZDBJ4YZL7LHVER4JG4SSPOGBWSPO/

Re: Build failures of packages which use waf as build system


On 16.7.2018 21:54, Guido Aulisi wrote:

I fixed some of these audio packages, prefixing waf calls with
%{__python2} macro. You have to BR python2-rpm-macros or python2-devel
to use it.


Or you can just type "python2". However, if you need %{__python2} macro, 
BR python2-devel, not python2-rpm-macros. Consider python2-rpm-macros an 
implementation detail.


Also, try to use %{__python3} or python3 with waf, it should be 
compatible, depending of course on the version.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6W6KDX3YTQFGNXH5ZSNYI4CD63JI26OW/

Re: Intent to orphan Python 2

2018-07-16 Thread Charalampos Stratakis



- Original Message -
> From: "R P Herrold" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, July 16, 2018 8:57:11 PM
> Subject: Re: Intent to orphan Python 2
> 
> On Mon, 16 Jul 2018, Miro Hrončok wrote:
> 
> > On 23.3.2018 12:23, Petr Viktorin wrote:
> > > tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
> > > to start dropping python2 packages now.
>  
> tl;dr: --- that statement by itself overlooks the obvious.
> Not ALL packages become unsupported that first day of that
> year
> 
> > > Python 2.7 will reach end of upstream support on 1st of January, 2020,
> > > after almost 10 years (!) of volunteer maintenance.
> 
> Not to be too direct about this, but isn't the RHEL 6 primary
> maintenance date (through 2020 11 30) a closer maintenance
> depot to look at and to compare against ?
> 

I don't see how that relates to Fedora. Could you elaborate on what you mean?

> Packages NOT in RHEL have a closer date, perhaps, but RHEL
> (next, assumedly 8, but ...) has not dropped yet.  A
> subscription customer _should_ be migrating toward 7 at this
> point, but as this is not a costless thing, such migrations
> tend to be ... with a deliberate pace
> 

Agreed but yet again, this doesn't like something that would impact Fedora.

> -- Russ herrold
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6TXSNJ7ER4SBK2D6L4BWU7YLLARJE7T/
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DAHZTVERHGRCASAXAL5UOBXJQE5SDSLR/

Adding pgadmin4 to Fedora repository

2018-07-16 Thread Joseph D. Wagner

Fedora 28 launched with PostgreSQL 10.  The PostgreSQL GUI tool in the 
repository -- pgadmin3 -- only works through version 9.x.  Hence, there 
has been a loss of functionality that I have been trying to get back.


All of the prerequisites for pgadmin4 were taken care of here:
BUG 1380826 - Review Request: pgadmin4 - Management tool for PostgreSQL
https://bugzilla.redhat.com/show_bug.cgi?id=1380826

The developer created a working package in a branch here:
https://copr.fedorainfracloud.org/coprs/itamarjp/pgadmin4/build/772898/

However, it looks like the final step of actually adding pgadmin4 as a 
package in the main repository didn't happen.  (At least, I couldn't 
find it the last time I checked.)


Could someone please help me through the next steps?  What must be done 
to get pgadmin4 into the repository?


I would really appreciate any help to get the GUI for PostgreSQL working 
again.


Thanks.

Joseph D. Wagner
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C7O4JQVQBHLLC4JHRX5JBN2VBO5IH3E3/

[Fedocal] Reminder meeting : Modularity Office Hours

2018-07-16 Thread nils

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-07-17 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6JKM2LX74KYORUNRJLJGQPNIVU4SCDM2/

[Bug 1601289] perl-Mail-JMAPTalk-0.12 is available

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



--- Comment #5 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.12-1.fc28 has been pushed to the Fedora 28 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-2018-133b3f2950

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/32XKFPQ7KGMCVJ732AIK4ZKV6KMNZEGO/

[Bug 1601286] perl-DB_File-1.842 is available

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



--- Comment #5 from Fedora Update System  ---
perl-DB_File-1.842-1.fc28 has been pushed to the Fedora 28 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-2018-584af79991

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/BFUOGSJALR67FHTX7GDNZ66O2EC5S2RO/

[Bug 1601131] perl-Test-POE-Client-TCP-1.22 is available

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



--- Comment #6 from Fedora Update System  ---
perl-Test-POE-Client-TCP-1.22-1.fc28 has been pushed to the Fedora 28 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-2018-72f67df677

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YRIMRJVSK2KOF7F7BRUF2ROT3S25HDCO/

Build failures of packages which use waf as build system

2018-07-16 Thread Guido Aulisi

Hi all,

I found many build failure of packages using waf as build system.
This is due to recent move of /usr/bin/python into a separate package

https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separat
e_package

Many audio related packages have this problem.

I fixed some of these audio packages, prefixing waf calls with
%{__python2} macro. You have to BR python2-rpm-macros or python2-devel
to use it.

For example:
https://src.fedoraproject.org/rpms/ardour5/c/e72960049735476c19c08a14cb
d5891556802753?branch=master

As discussed on the ML, this was the accepted solution, I hope this can
be useful to other people getting this problem

Guido

fas: tartina

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TIT5YDEUODUBTDOE2CGL754DWV6655F5/

Re: Lots a permission denied activity

2018-07-16 Thread Thomas Daede

On 07/16/2018 11:27 AM, Steve Grubb wrote:
> There is a /usr/libexec/tracker-extract process that searches my directories 
> about every 11 seconds. I can imagine on a laptop that would be a lot of disk 
> activity. Sometimes I use root in my home directory and accidentally create 
> files owned by root. This leads to a lots of events on my system. Does it 
> really need to run with this frequency?

I think this is a regression in tracker or one of its dependencies I
started noticing this happening last week. I haven't yet rolled it back
to figure out what version is at fault, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B2IMAX5VMFOZYYP7LGIARY7N5ER3KTNX/

[EPEL-devel] python 2 retirement commo efforts

2018-07-16 Thread R P Herrold


notwithstanding my post on the f-devel ML, ... 

Probaby there should some work on communicating the need to 
turn down EPEL 6 at 2020 11 30, and with it those python 
2 modules by that time

Smooge, if from the logs you can comb mirroring apart from 
installlation pulls, having a ranked list of python(2) 
candidates, to point


The python 2 in EPEL 7 (I see a mess of them), despite under 
40 or so python 2's in base / update RHEL, it may make sense 
to see of one of the automated conversion rubric will work on 
say 80 pct of the packages there.  Perhaps simply filing bugs 
asking the question for each, so we can garner some stats

-- Russ herrold
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/FXUP362ZU4WCCWOXTJFS7C2Y7ZINGPA2/

Re: Lots a permission denied activity

2018-07-16 Thread Adam Williamson

On Mon, 2018-07-16 at 14:27 -0400, Steve Grubb wrote:
> Hello,
> 
> I have been testing a new set of audit rules and have run across some 
> processes that are doing things that might out to be changed. Typically, 
> audit users expect a normally functioning system to not be noisy. There is a 
> requirement to audit failed file access due to permission denied. What I'm 
> finding is that two processes are generating tens of thousands of events 
> every day.
> 
> There is a /usr/libexec/tracker-extract process that searches my directories 
> about every 11 seconds. I can imagine on a laptop that would be a lot of disk 
> activity. Sometimes I use root in my home directory and accidentally create 
> files owned by root. This leads to a lots of events on my system. Does it 
> really need to run with this frequency?

It backs the live searches you can do via the GNOME overview, so for
those to be actually accurate (and I'd assume people often want to find
recently-touched content), yeah, it kinda has to run a lot. Probably
best asked on the desktop@ list, anyway.

> But I also see one that I just don't understand. Every 12 seconds, /usr/lib/
> systemd/systemd calls openat with write flags to open 
> 
> /sys/fs/cgroup/cpu/cgroup.procs
> /sys/fs/cgroup/cpuacct/cgroup.procs
> /sys/fs/cgroup/blkio/cgroup.procs
> /sys/fs/cgroup/memory/user.slice/user-4325.slice/user@4325.service/
> cgroup.procs
> /sys/fs/cgroup/memory/user.slice/user-4325.slice/cgroup.procs
> /sys/fs/cgroup/memory/user.slice/cgroup.procs
> /sys/fs/cgroup/memory/cgroup.procs
> /sys/fs/cgroup/devices/user.slice/cgroup.procs
> /sys/fs/cgroup/devices/cgroup.procs
> /sys/fs/cgroup/pids/user.slice/user-4325.slice/user@4325.service/cgroup.procs
> /sys/fs/cgroup/pids/user.slice/user-4325.slice/cgroup.procs
> /sys/fs/cgroup/pids/user.slice/cgroup.procs
> /sys/fs/cgroup/pids/cgroup.procs
> 
> Which are all root owned files. This adds up to about 45,000 events a day. Is 
> there a purpose to opening those files? And if that was truly needed, should 
> it be logging failures? Are the permissions wrong? If the failures are 
> benign, why is it doing it at all?

No idea about this one.
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4HATHQMNF3S63TPY7S7FFQCRBHYCEQI6/

Re: Intent to orphan Python 2

2018-07-16 Thread R P Herrold

On Mon, 16 Jul 2018, Miro Hrončok wrote:

> On 23.3.2018 12:23, Petr Viktorin wrote:
> > tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
> > to start dropping python2 packages now.

tl;dr: --- that statement by itself overlooks the obvious.  
Not ALL packages become unsupported that first day of that 
year

> > Python 2.7 will reach end of upstream support on 1st of January, 2020,
> > after almost 10 years (!) of volunteer maintenance.

Not to be too direct about this, but isn't the RHEL 6 primary 
maintenance date (through 2020 11 30) a closer maintenance 
depot to look at and to compare against ?  

Packages NOT in RHEL have a closer date, perhaps, but RHEL 
(next, assumedly 8, but ...) has not dropped yet.  A 
subscription customer _should_ be migrating toward 7 at this 
point, but as this is not a costless thing, such migrations 
tend to be ... with a deliberate pace

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6TXSNJ7ER4SBK2D6L4BWU7YLLARJE7T/

Re: Lots a permission denied activity

2018-07-16 Thread Sérgio Basto

On Mon, 2018-07-16 at 14:27 -0400, Steve Grubb wrote:
> Hello,
> 
> I have been testing a new set of audit rules and have run across
> some 
> processes that are doing things that might out to be changed.
> Typically, 
> audit users expect a normally functioning system to not be noisy.
> There is a 
> requirement to audit failed file access due to permission denied.
> What I'm 
> finding is that two processes are generating tens of thousands of
> events 
> every day.
> 
> There is a /usr/libexec/tracker-extract process that searches my
> directories 
> about every 11 seconds. I can imagine on a laptop that would be a lot
> of disk 
> activity. Sometimes I use root in my home directory and accidentally
> create 
> files owned by root. This leads to a lots of events on my system.
> Does it 
> really need to run with this frequency?

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

https://bugzilla.redhat.com/show_bug.cgi?id=747689 (closed as fixed !?!
)  yet today someone also complains about tracker 





> But I also see one that I just don't understand. Every 12 seconds,
> /usr/lib/
> systemd/systemd calls openat with write flags to open 
> 
> /sys/fs/cgroup/cpu/cgroup.procs
> /sys/fs/cgroup/cpuacct/cgroup.procs
> /sys/fs/cgroup/blkio/cgroup.procs
> /sys/fs/cgroup/memory/user.slice/user-4325.slice/user@4325.service/
> cgroup.procs
> /sys/fs/cgroup/memory/user.slice/user-4325.slice/cgroup.procs
> /sys/fs/cgroup/memory/user.slice/cgroup.procs
> /sys/fs/cgroup/memory/cgroup.procs
> /sys/fs/cgroup/devices/user.slice/cgroup.procs
> /sys/fs/cgroup/devices/cgroup.procs
> /sys/fs/cgroup/pids/user.slice/user-4325.slice/user@4325.service/cgro
> up.procs
> /sys/fs/cgroup/pids/user.slice/user-4325.slice/cgroup.procs
> /sys/fs/cgroup/pids/user.slice/cgroup.procs
> /sys/fs/cgroup/pids/cgroup.procs
> 
> Which are all root owned files. This adds up to about 45,000 events a
> day. Is 
> there a purpose to opening those files? And if that was truly needed,
> should 
> it be logging failures? Are the permissions wrong? If the failures
> are 
> benign, why is it doing it at all?
> 
> Thanks,
> -Steve
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/2HMJ4SX3UP22ASPI34YK6JOKEM2X5NYN/
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7I3FZI2GBROJ6CGTIIGOTRTR5U6RHBC7/

Lots a permission denied activity

2018-07-16 Thread Steve Grubb

Hello,

I have been testing a new set of audit rules and have run across some
processes that are doing things that might out to be changed. Typically,
audit users expect a normally functioning system to not be noisy. There is a
requirement to audit failed file access due to permission denied. What I'm
finding is that two processes are generating tens of thousands of events
every day.

There is a /usr/libexec/tracker-extract process that searches my directories
about every 11 seconds. I can imagine on a laptop that would be a lot of disk
activity. Sometimes I use root in my home directory and accidentally create
files owned by root. This leads to a lots of events on my system. Does it
really need to run with this frequency?

But I also see one that I just don't understand. Every 12 seconds, /usr/lib/
systemd/systemd calls openat with write flags to open

/sys/fs/cgroup/cpu/cgroup.procs
/sys/fs/cgroup/cpuacct/cgroup.procs
/sys/fs/cgroup/blkio/cgroup.procs
/sys/fs/cgroup/memory/user.slice/user-4325.slice/user@4325.service/
cgroup.procs
/sys/fs/cgroup/memory/user.slice/user-4325.slice/cgroup.procs
/sys/fs/cgroup/memory/user.slice/cgroup.procs
/sys/fs/cgroup/memory/cgroup.procs
/sys/fs/cgroup/devices/user.slice/cgroup.procs
/sys/fs/cgroup/devices/cgroup.procs
/sys/fs/cgroup/pids/user.slice/user-4325.slice/user@4325.service/cgroup.procs
/sys/fs/cgroup/pids/user.slice/user-4325.slice/cgroup.procs
/sys/fs/cgroup/pids/user.slice/cgroup.procs
/sys/fs/cgroup/pids/cgroup.procs

Which are all root owned files. This adds up to about 45,000 events a day. Is
there a purpose to opening those files? And if that was truly needed, should
it be logging failures? Are the permissions wrong? If the failures are
benign, why is it doing it at all?

Thanks,
-Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2HMJ4SX3UP22ASPI34YK6JOKEM2X5NYN/

[Bug 1529797] fusioninventory-agent-2.4.1 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||fusioninventory-agent-2.4.1
   ||-1.fc28
 Resolution|--- |ERRATA
Last Closed||2018-07-16 14:25:18



--- Comment #5 from Fedora Update System  ---
fusioninventory-agent-2.4.1-1.fc28 has been pushed to the Fedora 28 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/FTIYAHFTAAXTVGO6ZQRNIVX6UZLV7XBI/

[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL biweekly meeting

I am collecting the items for the agenda for Wednesdays meeting.
Please email me directly or the list.

On 16 July 2018 at 14:00,   wrote:
> Dear all,
>
> You are kindly invited to the meeting:
>EPEL biweekly meeting on 2018-07-18 from 18:00:00 to 19:00:00 US/Eastern
>At fedora-meet...@irc.freenode.net
>
> The meeting will be about:
> This is the bi-weekly meeting for EPEL. Items for the meeting agenda should 
> be emailed to epel-devel@lists.fedoraproject.org or to the EPEL tracker so 
> they can be addressed at the meeting.
>
> Meetings with no agenda will be cancelled.
>
> More information available at:
> [https://pagure.io/epel/](https://pagure.io/epel/)
>
>
> Source: https://apps.fedoraproject.org/calendar/meeting/9287/
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/W7Z5H63LWGZ7WFBY37O2GTHWNPV3G62G/



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/GFISJT7RQBWVWDU4UYCFW4HFDCXYKSKF/

Re: Intent to orphan Python 2


On 23.3.2018 12:23, Petr Viktorin wrote:

tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.


Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.

Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2
alive, we won't be the ones doing it – at least not at the current
magnitude".
Here are the details.


The current maintainers of python2 would like to "orphan" the python2
package in 2020 (~ Fedora 30):
- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
- dependent packages drop support for Python 2.

Unlike most other orphanings, we have some thousands of dependent
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested
packagers, as long as there's an understanding that we won't just
support python2 forever.

If you are a maintainer of anything at [1] we ask you kindly to consider
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora >
29. (On the current schedule, Fedora 30 will be the first release still
supported after 2020-01-01.)

If no one steps up to maintain python2 after 2020, we're prepared to
package a "legacy" python27 package, similar to what we do for e.g.
python33 [2], to:
- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if
their upstreams don't manage to port to Python 3 in time



[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/


This is just a reminder that nobody stepped up to maintain Python 2 
after 2020. We still need to start dropping python2 packages.


What shall we do from here? File a Fedora System Wide Change Proposal 
for Fedora 30 that nothing explicitly white-listed to require Python 2 
will be removed from Fedora? Can we even do that?


For context - there are currently 708 leaf packages [1](above).

Except several tools and applications, those are all modules that 
nothing in Fedora depends on. If we remove some, others only required by 
them will become leaf-packages as well.


We also have 1220 py2 only packages out of which plenty are probably 
unneeded modules as well, although we don't have the numbers.


As stated in the above e-mail in March, we are willing to support 
python2 for several (small number) of tools or apps. But we will not 
support it for 3 thousands of unused, unknown modules.


Python 2 will EOL in less than 1.5 year.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2ELVUFQ22YUG5XGQZJGELO7YSCMPRRGD/

[Bug 1601131] perl-Test-POE-Client-TCP-1.22 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Test-POE-Client-TCP-1.22-1.fc27 has been pushed to the Fedora 27 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-2018-174f525e37

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/6BU2YWREVUYPAREM6HYRGTO7ILH3XJF4/

[Bug 1601286] perl-DB_File-1.842 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-DB_File-1.842-1.fc27 has been pushed to the Fedora 27 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-2018-e840a1ac40

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/I5Z42QGCIUVOTJCJB7BCGGBGMPZ6OKB7/

Re: Fedora 29 Mass Rebuild

2018-07-16 Thread Sérgio Basto

On Fri, 2018-07-13 at 10:42 +0200, Miro Hrončok wrote:
> On 13.7.2018 10:38, Vascom wrote:
> > Hi.
> > As I see rebuild failed for all packages use %{__python} macro
> > because 
> > it point to /usr/bin/python that removed from python2 package.
> > 
> > Need MassFix all these packages. Many of them not updated very long
> > time.
> 
> Please, only fix yours or those you care about.
> 
> Let the old cruft be FTBFS for a while to see if the maintainers care
> or 
> not. We need to see how many legacy python stuff is in the distro 
> because it is needed and how many is there just because it
> accidentally 
> works for 10 years without any changes.

Hello 

After read this thread I think is about this scriptlet [1] 
Please how I fixed this one [2] ? 

Thanks 

[1] 
# Fix the shebangs so the package actually requires python2
sed -i -e 's@#! /usr/bin/env python@#!%{__python2}@g' \
gdesklets gdesklets-shell test-control.py ctrlinfo \
gdesklets-logview gdesklets-daemon


[2]
releng's gdesklets-0.36.3-32.fc29 failed to build
http://koji.fedoraproject.org/koji/buildinfo?buildID=1108914


> Thank You.
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/IQNNWDMYEGZN6BPN2EGDZCZ7IN7FK2ZK/
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZYRJJ4N7HLSP3C4J6EXHO6LN3V7QNYW5/

[Bug 1601289] perl-Mail-JMAPTalk-0.12 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.12-1.fc27 has been pushed to the Fedora 27 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-2018-6bd39a6fe9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org/message/4ZEGFGSEM7L24VWAXAKWRKUNURSDGA5M/

[EPEL-devel] [Fedocal] Reminder meeting : EPEL biweekly meeting

2018-07-16 Thread smooge

Dear all,

You are kindly invited to the meeting:
   EPEL biweekly meeting on 2018-07-18 from 18:00:00 to 19:00:00 US/Eastern
   At fedora-meet...@irc.freenode.net

The meeting will be about:
This is the bi-weekly meeting for EPEL. Items for the meeting agenda should be 
emailed to epel-devel@lists.fedoraproject.org or to the EPEL tracker so they 
can be addressed at the meeting. 

Meetings with no agenda will be cancelled.

More information available at:
[https://pagure.io/epel/](https://pagure.io/epel/)


Source: https://apps.fedoraproject.org/calendar/meeting/9287/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/W7Z5H63LWGZ7WFBY37O2GTHWNPV3G62G/

Re: Fedora 29 Mass Rebuild

2018-07-16 Thread Mohan Boddu

Hi All,

The F29 Mass Rebuild has been done and is being tagged back into f29 in
koji, so it will land in the buildroots shortly and in rawhide tomorrow.
Please check and fix any of your packages that failed to build. they can be
found at
https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html.

Thanks Mohan Boddu.

On Mon, Jul 16, 2018 at 1:19 PM Mohan Boddu  wrote:

>
>
> On Mon, Jul 16, 2018 at 3:59 AM Miro Hrončok  wrote:
>
>> On 6.7.2018 15:29, Mohan Boddu wrote:
>> > Hi all,
>> >
>> > Per the Fedora 29 schedule[1] we will be starting a mass rebuild for
>> > Fedora 29 very shortly. We are doing a mass rebuild for Fedora 29 for
>> > all the changes listed in
>> >
>> > https://pagure.io/releng/issue/7480
>> >
>> > we will start the mass rebuild on 2018-07-11
>> >
>> > This is a heads up that it will be done in a side tag and moved over
>> > when completed. We will be running scripts to output failure stats.
>> > please be sure to let releng know if you see any bugs in the reporting.
>> >
>> > You can contact releng in #fedora-releng on freenode.
>> >
>> > Failures can be seen
>> >
>> > https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html
>>
>> I suspect there will be more rounds? I've pushed several fixes, do I
>> need to care about rebuilding those?
>>
> Generally we run mass rebuild once per release (sometimes we do more
> than one if we found some issue).
>
> If you have pushed something, then you need to rebuild them. We
> are not going to run multiple mass rebuilds.
>
> Thanks.
>
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZAUZTDRJ47CLZVR4UQYJK3YB5K3FNRUD/
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LGC26NUF4P6E7RS6T32SRGLFZAMECDZU/

Re: Fedora 29 Mass Rebuild

2018-07-16 Thread Mohan Boddu

On Mon, Jul 16, 2018 at 3:59 AM Miro Hrončok  wrote:

> On 6.7.2018 15:29, Mohan Boddu wrote:
> > Hi all,
> >
> > Per the Fedora 29 schedule[1] we will be starting a mass rebuild for
> > Fedora 29 very shortly. We are doing a mass rebuild for Fedora 29 for
> > all the changes listed in
> >
> > https://pagure.io/releng/issue/7480
> >
> > we will start the mass rebuild on 2018-07-11
> >
> > This is a heads up that it will be done in a side tag and moved over
> > when completed. We will be running scripts to output failure stats.
> > please be sure to let releng know if you see any bugs in the reporting.
> >
> > You can contact releng in #fedora-releng on freenode.
> >
> > Failures can be seen
> >
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html
>
> I suspect there will be more rounds? I've pushed several fixes, do I
> need to care about rebuilding those?
>
Generally we run mass rebuild once per release (sometimes we do more
than one if we found some issue).

If you have pushed something, then you need to rebuild them. We
are not going to run multiple mass rebuilds.

Thanks.

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZAUZTDRJ47CLZVR4UQYJK3YB5K3FNRUD/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XLOF23HEBDYFGQO5IEOOZGYVM5QFQ6IA/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-16 Thread Sérgio Basto

On Fri, 2018-07-13 at 12:39 +0200, Igor Gnatenko wrote:
> On Fri, Jul 13, 2018, 11:19 Miro Hrončok  wrote:
> > On 8.7.2018 20:46, Igor Gnatenko wrote:
> > > As per Changes/Remove GCC from BuildRoot 
> > >  > >, I'm 
> > > going to automatically add BuildRequires: gcc and/or
> > BuildRequires: 
> > > gcc-c++ to packages which fail to build with common messages
> > (like gcc: 
> > > command not found, also autotools/cmake/meson are supported).
> > > 
> > > I'm going to do this tomorrow.
> > > 
> > > After which, I'm going to ask rel-eng to finally remove it from 
> > > buildroot. This will happen before mass rebuild. Stay tuned.
> > > -- 
> > 
> > I've clicked randomly trough failures during the mass rebuild at
> > [1].
> > 
> > I see quite a lot of commands not founds for gcc, cc, c++...
> > 
> > I think the maintainers should add them and that's fine, but it
> > seemed 
> > that during this change you said you will add those. Did it happen?
> 
> Yes, I've pushed over 2k commits adding those, however regexp might
> have not catched all possible cases. Would appreciate if you would
> link such packages so that I can fix them. Or maintainers can do it
> themselves.

releng's debconf-1.5.63-4.fc29 failed to build
man2html-1.6-22.g.fc29
noip-2.1.9-26.fc29
p7zip-16.02-13.fc29 failed to build
perl-File-FcntlLock-0.22-13.fc29
perl-Mail-Transport-Dbx
pngquant-2.12.1-2.fc29
subdownloader-2.0.19-8.fc29
python-bitarray-0.8.3-2.fc29
rawstudio-2.1-0.19.20170414.g003dd4f_rawspeed.20161119.gfa23d1c.fc29 
virtualbox-guest-additions-5.2.14-2.fc29
tetrinetx-1.13.16-21.fc29

I already fixed unar and dpkg , if you fixed some of those. I'll be
grateful

> > [1] https://kojipkgs.fedoraproject.org/mass-rebuild/f29-
> > failures.html
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidel
> > ines
> > List Archives: https://lists.fedoraproject.org/archives/list/devel@
> > lists.fedoraproject.org/message/INTODKJDI2NU36RBHKPYNLDOPSBRAPV6/
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CGZE7FPF2RJXCC6BZBXVZXWVYP6PZVBL/

[Bug 1537217] perl-gettext: Obsoletes work by package name, not by provides

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
  Flags|needinfo?(rc040203@freenet. |
   |de) |
   |needinfo?(rc040203@freenet. |
   |de) |
Last Closed||2018-07-16 12:54:24



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/QU2YUZN6KTKEINNGSG3LD6U7FS4UFUVH/

Re: Intel's Clear Linux optimizations

2018-07-16 Thread Manas Mangaonkar

The Actual Url


On Fri, Jul 13, 2018 at 12:01 AM, Chris Murphy 
wrote:

> On Thu, Jul 12, 2018 at 10:09 AM, Manas Mangaonkar
>  wrote:
> > Rpm Generation Done, Sorry for the really long delay. Request someone to
> > test it out.
> >
>
> URL?
>
>
>
> --
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/UBETVVKZ3WMLRGTLF3IWQOADORTGHWRS/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QZXR52QDW4TAJCYCFLC5PMS3WXQCSWS5/

tickets resolved by voting on the issue tracker

2018-07-16 Thread Zbigniew Jędrzejewski-Szmek

The following tickets were resolved by voting in the issue tracker
without disagreement:

#1941 F29 System Wide Change: OpenLDAP without Non-threaded Libraries
- Change is approved (+7, 0, 0)

#1938 F29 System Wide Change: Discontinue PPC64 as Alternative Architecture 
- Change is approved (+6, 0, 0)

#1937 F29 System Wide Change: CJK Default Fonts To Noto
- Change is approved (+5, 0, 0)

#1919 Non-responsive maintainer of psi-plus
- The package will be reassigned to @raphgro (+3, 0, 0)

#1933 [Policy] Do not close Fedora Security Tracking bugs with resolution
CLOSED:EOL but carry them over to next version
- The policy to *not* close those bugs is reapproved.
- Bugs for F25 and F26 that were closed, should be reopened.
(+8, 0, 0)

#1921 Clarification on the new ticket policy
- If seven members of FESCo vote +1 in a ticket, it is be approved
  immediately.
- The week for voting starts counting when a proposal is made, not
  necessarily when the ticket itself is filed.
(+5, 0, 0)
and
- The ticket policy is clarified to mean that any -1 votes
  automatically put the ticket on meeting agenda (as the wiki already
  states) (+6, 0, 0)

This should have gone as part of the meeting agenda announcement, but
it didn't. Mea culpa.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BK2MTO5Q4B3VNYZZPZMMPP6RGU5KG2AJ/

Re: Fedora c++ default build flags

On 16/07/18 18:24 +0200, Florian Weimer wrote:

On 07/16/2018 05:25 PM, Jonathan Wakely wrote:

On 12/07/18 20:49 +0200, mskal...@redhat.com wrote:

Dan Horák píše v St 11. 07. 2018 v 14:12 +0200:

On Wed, 11 Jul 2018 14:00:40 +0200
mskal...@redhat.com wrote:

Hi,
during a discussion with upstream (MongoDB) they asked me about
default Fedora C/C++ build flags. And I don't remember all Fedora
System Wide changes where it was introduced,... so is there some
place where it's described?

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/bu
ildflags.md

Thanks. Also does someone have any information how our flags affects
performance?
(which is also important for the upstream project)

Currently -D_GLIBCXX_ASSERTIONS has fairly negative effects on
performance of some code using the C++ standard library. GCC is not
able to optimise away as many of the checks as we initially thought.

Do you know if anything else besides ?
That one at least a simple source-level fix (probably fixing a real
bug in some cases): Use size_type/size_t for the index variable.

That's the only specific example I'm aware of, but there might be
plenty of correct code using unsigned for the loop variable, which
gets pessimised by the assertions. It's unusual to have more than
UINT_MAX elements in a vector, so we can't just say such code needs
fixing.

Re: Fedora c++ default build flags

2018-07-16 Thread Florian Weimer

On 07/16/2018 05:25 PM, Jonathan Wakely wrote:

On 12/07/18 20:49 +0200, mskal...@redhat.com wrote:

Dan Horák píše v St 11. 07. 2018 v 14:12 +0200:

On Wed, 11 Jul 2018 14:00:40 +0200
mskal...@redhat.com wrote:

> Hi,
> during a discussion with upstream (MongoDB) they asked me about
> default Fedora C/C++ build flags. And I don't remember all Fedora
> System Wide changes where it was introduced,... so is there some
> place where it's described?

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/bu
ildflags.md

Thanks. Also does someone have any information how our flags affects
performance?
(which is also important for the upstream project)

Currently -D_GLIBCXX_ASSERTIONS has fairly negative effects on
performance of some code using the C++ standard library. GCC is not
able to optimise away as many of the checks as we initially thought.

Do you know if anything else besides ? 
That one at least a simple source-level fix (probably fixing a real bug 
in some cases): Use size_type/size_t for the index variable.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QRSMK5J25SFDBVM2ZBR2O4EXYB6A74AB/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-16 Thread Daniel P . Berrangé

On Thu, Jul 12, 2018 at 09:17:41PM +0100, Richard W.M. Jones wrote:
> On Thu, Jul 12, 2018 at 02:10:37PM -0400, Cole Robinson wrote:
> > On 07/11/2018 04:37 PM, Kevin Fenzi wrote:
> > > On 07/11/2018 12:57 PM, Mikolaj Izdebski wrote:
> > >> On 07/11/2018 09:26 PM, Kevin Fenzi wrote:
> > >>> I don't see the cache=unsafe anywhere (although the name sure makes me
> > >>> want to enable it for official builds let me tell ya. ;) Can you point
> > >>> out more closely where it is or docs for it?
> > >>
> > >> cache=unsafe is documented at [1]. (Basically, in virt_install_command
> > >> you append ",cache=unsafe" to --disk parameter, next to "bus=virtio".)
> > >> It makes buildvmhost cache all disk operations and ignore sync
> > >> operations. Similar to nosync, but does not work on buildhw, works on
> > >> virthost level, applies to all operations, not just dnf.
> > >>
> > >> [1]
> > >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_tuning_and_optimization_guide/index#sect-Virtualization_Tuning_Optimization_Guide-BlockIO-Caching
> > > 
> > > Ah, I see at the vm level. Yeah, I don't think this would be very much
> > > of a win for us. The x86_64 buildvm's have all their storage on iscsi,
> > > the arm ones have their storage on ssd's. I suppose it could help the
> > > ppc64{le} ones, they are on 10k sas drives. I'm pretty leary of enabling
> > > anything called 'unsafe' though.
> > 
> > I think it's unsafe only in the case of on-disk consistency, so across
> > VM reboots. I _think_ over a single run of a VM it's safe, which may
> > describe koji usage.
> > 
> > I know rjones has looked deeply at qemu caching methods for use in
> > libguestfs so maybe he can comment, CC'd
> 
> I cover caching modes about half way down here:
> 
>   
> https://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/
> 
> First off, cache=unsafe really does improve performance greatly, I
> measured around 25% on a disk-heavy workload.

FYI to augment what Rich's blog post says, it helps to understand the
difference between cache modes. The QEMU 'cache' setting actually
controls 3 separate tunables under the hood:

  │ cache.writeback   cache.direct   cache.no-flush
 ─┼─
 writeback│ onoffoff
 none │ onon off
 writethrough │ off   offoff
 directsync   │ off   on off
 unsafe   │ onoffon

IOW, changing from cache=none to cache=unsafe turns off O_DIRECT so data
is buffered in host RAM, and also turns off disk flushing, so QEMU never
requests it to be pushed out to disk. The latter change is what makes
it so catastrophic on host failure - even a journalling filesystem in
the guest won't save you because we're ignoring the flush requests that
are required to make the journal work safely.

The combination of not using O_DIRECT and not honouring flush requests
means that all I/O operations on the guest complete pretty much immediately
without ever waiting for the host todo the real I/O.

The amount of RAM you have in the host though is pretty relevant here.
If the guest is doing I/O faster than the host OS can write it to disk
and there's never any flush requests to slow the guest down, you're
going to use an ever increasing amount of host RAM for caching I/O.
This could be a bad thing if you're contending on host RAM - it could
even push other important guests out to swap or trigger OOM killer.

IOW, using O_DIRECT (cache=none or directsync) is a good thing if you
need predictable host RAM usage - the only RAM used for I/O cache is
that assigned to the guest OS itself.

With using cache=unsafe for Koji I'd be a little concerned about
whether a build could inflict a denial of service on host RAM either
intentionally or accidentally, as the guest is relatively untrustworthy
and/or unconstrained in what it is running.

Finally the issue of O_DIRECT vs host page cache *only* applies if your
QEMU process is using locally exposed storage. ie a plain file, or a
local device node in /dev.  If QEMU is using iSCSI via its built-in
network client, then host page cache vs O_DIRECT is irrelevant. In
this latter case, using cache=unsafe might be OK from a host RAM
consumption POV - though I'm not entirely sure what the RAM usage
pattern of the QEMU iSCSI client is like.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List

Summary/Minutes from today's FESCo Meeting (2018-07-16)

2018-07-16 Thread Zbigniew Jędrzejewski-Szmek

Meeting started by zbyszek at 15:04:59 UTC.
Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-07-16/fesco.2018-07-16-15.04.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-07-16/fesco.2018-07-16-15.04.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-07-16/fesco.2018-07-16-15.04.log.html


Meeting summary
---
* #1936 F29 Self Contained Change: Deprecate YUM 3  (zbyszek, 15:05:47)
  * LINK: https://pagure.io/fesco/issue/1936   (zbyszek, 15:05:47)
  * LINK: https://pagure.io/koji/issue/971   (zbyszek, 15:12:37)
  * AGREED: The change is rejected for F29, but FESCo would like to see
this resubmitted for F30, with a list of dependencies (tickets),
that need to be solved first (+7, 0, 0)  (zbyszek, 15:18:01)

* #1940 F29 System Wide Change: Zchunk Metadata  (zbyszek, 15:18:30)
  * LINK: https://pagure.io/fesco/issue/1940   (zbyszek, 15:18:30)
  * AGREED: Change is approved for F29.  Whatever pieces aren't done by
F29 are approved for F30 (+7, 0, 0)  (zbyszek, 15:30:51)

* Next weeks chair  (zbyszek, 15:31:15)
  * ACTION: bowlofeggs to chair next week's meeting  (zbyszek, 15:32:12)

* Open floor  (zbyszek, 15:32:57)
  * It is understood that infra is busy, and any changes might wait
before being merged  (zbyszek, 15:40:16)
  [ this is in reference to #1940 ]

  * AGREED: The ticket policy is clarified to mean that any -1 votes
automatically put the ticket on meeting agenda (as the wiki already
states) (+6, 0, 0)  (zbyszek, 15:46:28)

Meeting ended at 15:48:37 UTC.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZOJXHLA67BIRJMDDTYMIS4R7FXW5LGYC/

[Bug 1601443] perl-libwww-perl-6.35 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-libwww-perl-6.35-1.fc2
   ||9
 Resolution|--- |RAWHIDE
Last Closed||2018-07-16 11:52:01



--- Comment #1 from Petr Pisar  ---
This release works around a file descriptor leak on Perl < 5.18. It also brings
a new build-time dependencies. Safer for Rawhide only.

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/EBKZFHJ6SB44XKW47W7TIRJIQ4NPPJYB/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-16 Thread Adam Williamson

On Mon, 2018-07-16 at 09:27 -0400, Cole Robinson wrote:
> On 07/15/2018 11:47 AM, Richard W.M. Jones wrote:
> > On Fri, Jul 13, 2018 at 04:05:42PM +0200, Mikolaj Izdebski wrote:
> > > On 07/12/2018 10:17 PM, Richard W.M. Jones wrote:
> > > > Does each build start with its own fresh VM?  Do you care about the
> > > > data in that build VM if either qemu or the host crashes?  If the
> > > > answers are 'Yes' and 'No' respectively to these questions then IMHO
> > > > this is the ideal situation for cache=unsafe.
> > > 
> > > The answers are 'No' and 'Not much'.
> > > 
> > > 1. VMs are installed once and are running for week/months until they are
> > > reinstalled. In the meantime guests and hosts are rebooted during
> > > routine maintenance, to apply updates.
> > 
> > In this case my preferred advice would be: DO NOT use cache=unsafe.
> > 
> > We've only tested scenarios for very short-lived build or temporary
> > VMs (for example when I was building RISC-V packages before we had
> > Koji, I used a script which created a VM per build and there it made
> > sense to use cache=unsafe).
> > 
> > I do not think it's a good idea to be using this for VMs which are in
> > any way long-lived as there could be unforeseen side effects which I'm
> > not aware of and certainly have never tested.
> > 
> 
> One other datapoint is that I _think_ openqa uses cache=unsafe, which is
> used for Fedora automated install testing. I'm basing this largely on
> cache=unsafe in the openqa sources.

That's mostly true, I think, except when doing multipath testing (where
it uses cache=none instead). However, openQA very much meets the
definition of 'short-lived / temporary' VMs - each openQA 'job' uses a
new VM, so the longest any one ever lasts is 2 hours (the hard limit on
an openQA job's lifetime). It also uses fresh disk images each time
(even when using a pre-created base disk image, it doesn't use it
directly but creates new scratch images based on the base image). I
don't know whether this is true of the Koji builder VMs.
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AMCPPS23B4F6Y5AON662I7GSGUL3MOSM/

Re: Annobin: "causes a section type conflict with..."


On 07/07/18 16:21 -0600, Jerry James wrote:

On Fri, Jul 6, 2018 at 2:14 PM Jonathan Wakely
 wrote:

I'm seeing this in Boost too, and given my schedule I'm going to
abandon the Boost update for f29.


Ugh, that's unfortunate.  I wonder if we should perhaps postpone the
mass rebuild until this issue has been fixed.

It would be interesting to know if turning off annobin fixes the boost
problem, too.  That would lend credence to the idea that annobin has
something to do with the issue.


I did try that of course. Turning off annobin fixed the section
conflict, but building Boost still failed for a different reason
(because they've changed the drokking build system again and our
solution for building various libs once for python2 and again for
python3 stopped working ... again).

Since I was on holiday all last week I decided not to spend my weekend
fighting with Boost's spugging build system. I had a much nicer
holiday as a result.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F6GGXNZ6HHDA3BBWWSTG65L6NDNLPQPM/

Re: Fedora c++ default build flags


On 12/07/18 20:49 +0200, mskal...@redhat.com wrote:

Dan Horák píše v St 11. 07. 2018 v 14:12 +0200:

On Wed, 11 Jul 2018 14:00:40 +0200
mskal...@redhat.com wrote:

> Hi,
> during a discussion with upstream (MongoDB) they asked me about
> default Fedora C/C++ build flags. And I don't remember all Fedora
> System Wide changes where it was introduced,... so is there some
> place where it's described?

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/bu
ildflags.md



Thanks. Also does someone have any information how our flags affects
performance?
(which is also important for the upstream project)


Currently -D_GLIBCXX_ASSERTIONS has fairly negative effects on
performance of some code using the C++ standard library. GCC is not
able to optimise away as many of the checks as we initially thought.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JIXBJ6CMLQWQOHILDMT5LIFLMYIDRRLV/

Re: [HEADS UP] Removal of GCC from the buildroot


On 10/07/18 08:42 +0100, Tomasz Kłoczko wrote:

Do you see whole context now?


No, because I stopped reading. Too longwinded, too much rambling. Try
to express yourself more concisely.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PAANM4VKN2MJC7LX6LTC3BMVRLFGG4BA/

Re: sip-related build failures in rawhide


On 16.7.2018 16:43, Rex Dieter wrote:

Rex Dieter wrote:


Rex Dieter wrote:


Scott Talbert wrote:


On Mon, 16 Jul 2018, Miro Hrončok wrote:


A few days ago scidavis builds started failing in rawhide. Someone
mentioned here that sip was to blame for a number of such failures and
according to koschei they started to happen after the update from
sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.


Sorry for stealing the thread, but this might be related:

libarcus:   Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162

libsavitar: Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370


I'll investigate these.  Odd though 'sip' is present in the buildroot,
CMake Error at cmake/FindSIP.cmake:64 (MESSAGE):
   Could not find SIP

could mean something else in this context.


OK, context is that these are looking for the sip python module, which is
no longer implicitly pulled in by current:
BuildRequires: python3-sip-devel

Seems a lot of software expects that, so I'll (re)add the dependency
Requires: python3-sip
to python3-sip-devel


Both of these should be addressed by sip-4.19.12-5 building now



Thank you.

libarcus, libsavitar and python-pyqtchart all build now

python-pyqtchart: 
https://src.fedoraproject.org/rpms/python-pyqtchart/c/1d64fa2f2b90f38ff537a15c3370e3d5b3fba188



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5PVIINAI6MEAIF35WH3QMFSGSRPYLPQI/

Schedule for today's FESCo Meeting (2018-07-16)

2018-07-16 Thread Zbigniew Jędrzejewski-Szmek

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

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

or run:
  date -d '2018-07-16 15:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

#topic #1936 F29 Self Contained Change: Deprecate YUM 3
.fesco 1936
https://pagure.io/fesco/issue/1936

= New business =

#topic #1940 F29 System Wide Change: Zchunk Metadata
.fesco 1940
https://pagure.io/fesco/issue/1940

= Open Floor = 

For more complete details, please visit each individual issue.  The
report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can reply to
this e-mail, file a new issue at https://pagure.io/fesco/,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F7JJPVTP4BUD5YL54WFWC47AJVW5RYRQ/

Re: sip-related build failures in rawhide

Scott Talbert wrote:

>> Seems a lot of software expects that, so I'll (re)add the dependency
>> Requires: python3-sip
>> to python3-sip-devel
> 
> Also, since you're now only packaging the one 'sip' binary, does it make
> sense to move it out of the 'python2-sip-devel' package to a
> python-agnostic subpackage?  

Excellent suggestion... 
That's precisely what was done and why we're having this conversation. :)

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V3IGZRWLX55U4SL37WCV77WMROFMGQG5/

Re: sip-related build failures in rawhide

2018-07-16 Thread Scott Talbert


On Mon, 16 Jul 2018, Miro Hrončok wrote:


A few days ago scidavis builds started failing in rawhide. Someone
mentioned here that sip was to blame for a number of such failures and
according to koschei they started to happen after the update from
sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.


Sorry for stealing the thread, but this might be related:

libarcus:   Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162

libsavitar: Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370


I'll investigate these.  Odd though 'sip' is present in the buildroot,
CMake Error at cmake/FindSIP.cmake:64 (MESSAGE):
  Could not find SIP

could mean something else in this context.


OK, context is that these are looking for the sip python module, which is 
no

longer implicitly pulled in by current:
BuildRequires: python3-sip-devel

Seems a lot of software expects that, so I'll (re)add the dependency
Requires: python3-sip
to python3-sip-devel


Also, since you're now only packaging the one 'sip' binary, does it make 
sense to move it out of the 'python2-sip-devel' package to a 
python-agnostic subpackage?  It seems a bit weird that a python 3 package 
that uses sip would have to BR python2-sip-devel to get the sip binary.


It appears to be in the sip package that requires no python version.


Good - yeah it looks like he moved it recently.  I was going off this, 
which is probably based off an older compose (or maybe there hasn't been 
a successful compose yet):


https://apps.fedoraproject.org/packages/python2-sip-devel/

Scott___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TKMDMXMPSZNSOLOBWAXIODWXDDSYZLNF/

Re: sip-related build failures in rawhide


On 16.7.2018 16:49, Scott Talbert wrote:

On Mon, 16 Jul 2018, Rex Dieter wrote:


A few days ago scidavis builds started failing in rawhide. Someone
mentioned here that sip was to blame for a number of such failures 
and

according to koschei they started to happen after the update from
sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.


Sorry for stealing the thread, but this might be related:

libarcus:   Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162

libsavitar: Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370


I'll investigate these.  Odd though 'sip' is present in the buildroot,
CMake Error at cmake/FindSIP.cmake:64 (MESSAGE):
  Could not find SIP

could mean something else in this context.


OK, context is that these are looking for the sip python module, which 
is no

longer implicitly pulled in by current:
BuildRequires: python3-sip-devel

Seems a lot of software expects that, so I'll (re)add the dependency
Requires: python3-sip
to python3-sip-devel


Also, since you're now only packaging the one 'sip' binary, does it make 
sense to move it out of the 'python2-sip-devel' package to a 
python-agnostic subpackage?  It seems a bit weird that a python 3 
package that uses sip would have to BR python2-sip-devel to get the sip 
binary.


It appears to be in the sip package that requires no python version.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HFIMNGF7WOWGLC4PT7CISFLDA2NNSXFH/

Re: sip-related build failures in rawhide

2018-07-16 Thread Scott Talbert


On Mon, 16 Jul 2018, Rex Dieter wrote:


A few days ago scidavis builds started failing in rawhide. Someone
mentioned here that sip was to blame for a number of such failures and
according to koschei they started to happen after the update from
sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.


Sorry for stealing the thread, but this might be related:

libarcus:   Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162

libsavitar: Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370


I'll investigate these.  Odd though 'sip' is present in the buildroot,
CMake Error at cmake/FindSIP.cmake:64 (MESSAGE):
  Could not find SIP

could mean something else in this context.


OK, context is that these are looking for the sip python module, which is no
longer implicitly pulled in by current:
BuildRequires: python3-sip-devel

Seems a lot of software expects that, so I'll (re)add the dependency
Requires: python3-sip
to python3-sip-devel


Also, since you're now only packaging the one 'sip' binary, does it make 
sense to move it out of the 'python2-sip-devel' package to a 
python-agnostic subpackage?  It seems a bit weird that a python 3 package 
that uses sip would have to BR python2-sip-devel to get the sip binary.


Scott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UWJQRBSWWUBXUBCHJQURJEZYCUHZGHMO/

Re: sip-related build failures in rawhide

Rex Dieter wrote:

> Rex Dieter wrote:
> 
>> Scott Talbert wrote:
>> 
>>> On Mon, 16 Jul 2018, Miro Hrončok wrote:
>>> 
> A few days ago scidavis builds started failing in rawhide. Someone
> mentioned here that sip was to blame for a number of such failures and
> according to koschei they started to happen after the update from
> sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.

 Sorry for stealing the thread, but this might be related:

 libarcus:   Could not find SIP
 https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162

 libsavitar: Could not find SIP
 https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370
>> 
>> I'll investigate these.  Odd though 'sip' is present in the buildroot,
>> CMake Error at cmake/FindSIP.cmake:64 (MESSAGE):
>>   Could not find SIP
>> 
>> could mean something else in this context.
> 
> OK, context is that these are looking for the sip python module, which is
> no longer implicitly pulled in by current:
> BuildRequires: python3-sip-devel
> 
> Seems a lot of software expects that, so I'll (re)add the dependency
> Requires: python3-sip
> to python3-sip-devel

Both of these should be addressed by sip-4.19.12-5 building now

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EXLONWTU3AUI6DLGKAZBIJ3TTSLW5KTF/

Re: sip-related build failures in rawhide

Rex Dieter wrote:

> Scott Talbert wrote:
> 
>> On Mon, 16 Jul 2018, Miro Hrončok wrote:
>> 
 A few days ago scidavis builds started failing in rawhide. Someone
 mentioned here that sip was to blame for a number of such failures and
 according to koschei they started to happen after the update from
 sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.
>>>
>>> Sorry for stealing the thread, but this might be related:
>>>
>>> libarcus:   Could not find SIP
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162
>>>
>>> libsavitar: Could not find SIP
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370
> 
> I'll investigate these.  Odd though 'sip' is present in the buildroot,
> CMake Error at cmake/FindSIP.cmake:64 (MESSAGE):
>   Could not find SIP
> 
> could mean something else in this context.

OK, context is that these are looking for the sip python module, which is no 
longer implicitly pulled in by current:
BuildRequires: python3-sip-devel

Seems a lot of software expects that, so I'll (re)add the dependency
Requires: python3-sip
to python3-sip-devel

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/USQNXZWW35LSVMAG4F7CULAOZILA7XVJ/

Re: sip-related build failures in rawhide

Miro Hrončok wrote:

> On 16.7.2018 16:30, Rex Dieter wrote:
>>> On this last one at least - it appears that the python3-sip executable
>>> was
>>> removed in the packaging.  I've got a query into Rex about whether what
>>> was intentional or not.
>> 
>> The removal was intentional, but as I see it was used in more places, can
>> put back a compat symlink to avoid breakage like that.
> 
> What should we use instead?

Just 'sip', aka /usr/bin/sip

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X2Q2V56AOGW6JUIGW557YFYZWQHQVWWR/

Re: sip-related build failures in rawhide


On 16.7.2018 16:30, Rex Dieter wrote:

On this last one at least - it appears that the python3-sip executable was
removed in the packaging.  I've got a query into Rex about whether what
was intentional or not.


The removal was intentional, but as I see it was used in more places, can
put back a compat symlink to avoid breakage like that.


What should we use instead?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QUE6H4DULPEA2CB6QBUQMILZ54E73F7A/

Re: sip-related build failures in rawhide

Scott Talbert wrote:

> On Mon, 16 Jul 2018, Miro Hrončok wrote:
> 
>>> A few days ago scidavis builds started failing in rawhide. Someone
>>> mentioned here that sip was to blame for a number of such failures and
>>> according to koschei they started to happen after the update from
>>> sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.
>>
>> Sorry for stealing the thread, but this might be related:
>>
>> libarcus:   Could not find SIP
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162
>>
>> libsavitar: Could not find SIP
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370

I'll investigate these.  Odd though 'sip' is present in the buildroot, 
CMake Error at cmake/FindSIP.cmake:64 (MESSAGE):
  Could not find SIP

could mean something else in this context.

>> python-pyqtchart: '/usr/bin/python3-sip' is not an executable
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=28223996
> 
> On this last one at least - it appears that the python3-sip executable was
> removed in the packaging.  I've got a query into Rex about whether what
> was intentional or not.

The removal was intentional, but as I see it was used in more places, can 
put back a compat symlink to avoid breakage like that.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3LBMYH2Y3CG3OWMZ3CHJRGLVPNASQSJO/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-16 Thread Till Maas

On Fri, Jul 13, 2018 at 12:39:55PM +0200, Igor Gnatenko wrote:

> Yes, I've pushed over 2k commits adding those, however regexp might have
> not catched all possible cases. Would appreciate if you would link such
> packages so that I can fix them. Or maintainers can do it themselves.
> 
> [1] https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html

Can you maybe add:

g?cc: [Co]mmand not found

to the script, regrep and fix the resulting packages. I just checked 3
of 12 of my failed pkgs and they had error messages like the following:

| make[1]: gcc: Command not found
| sh: gcc: command not found
| make: cc: Command not found
| 
| https://kojipkgs.fedoraproject.org//work/tasks/215/28320215/build.log
| https://kojipkgs.fedoraproject.org//work/tasks/9137/28229137/build.log
| https://kojipkgs.fedoraproject.org//work/tasks/4199/28314199/build.log

If you have the tools ready, it would make it easier to just re-run it
IMHO.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ECFKT2GEOMFPAACFWTTDND72RCZKR7CG/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-16 Thread Cole Robinson

On 07/15/2018 11:47 AM, Richard W.M. Jones wrote:
> On Fri, Jul 13, 2018 at 04:05:42PM +0200, Mikolaj Izdebski wrote:
>> On 07/12/2018 10:17 PM, Richard W.M. Jones wrote:
>>> Does each build start with its own fresh VM?  Do you care about the
>>> data in that build VM if either qemu or the host crashes?  If the
>>> answers are 'Yes' and 'No' respectively to these questions then IMHO
>>> this is the ideal situation for cache=unsafe.
>>
>> The answers are 'No' and 'Not much'.
>>
>> 1. VMs are installed once and are running for week/months until they are
>> reinstalled. In the meantime guests and hosts are rebooted during
>> routine maintenance, to apply updates.
> 
> In this case my preferred advice would be: DO NOT use cache=unsafe.
> 
> We've only tested scenarios for very short-lived build or temporary
> VMs (for example when I was building RISC-V packages before we had
> Koji, I used a script which created a VM per build and there it made
> sense to use cache=unsafe).
> 
> I do not think it's a good idea to be using this for VMs which are in
> any way long-lived as there could be unforeseen side effects which I'm
> not aware of and certainly have never tested.
> 

One other datapoint is that I _think_ openqa uses cache=unsafe, which is
used for Fedora automated install testing. I'm basing this largely on
cache=unsafe in the openqa sources.

>> 2. There would be no data loss in case of host or hypervisor crash.
>> Worst case, if guest operating system was corrupted sysadmins would need
>> to trigger VM install.
> 
> Host crash => yes you'd definitely need to reinstall that VM.
> 
> It's not a worst case, a host crash would near-definitely corrupt a VM
> that was ignoring flush requests.  It might even corrupt in an
> undetectable way (eg. throwing away data while leaving metadata
> intact).
> 
I patched kojivm code once, at the time I think new VM instances all
used qcow2 overlays ontop of a shared base. It's possible those are
created and destroyed with each VM instance, so data loss may not matter
in the case of a crash if the overlay will just be discarded regardless.
Would need koji devs to confirm though

- Cole
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G3N2NB6XS5XYU2SU2DLPOWR7YXFRX6FW/

Re: sip-related build failures in rawhide

2018-07-16 Thread Scott Talbert


On Mon, 16 Jul 2018, Miro Hrončok wrote:


A few days ago scidavis builds started failing in rawhide. Someone
mentioned here that sip was to blame for a number of such failures and
according to koschei they started to happen after the update from
sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.


Sorry for stealing the thread, but this might be related:

libarcus:   Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162

libsavitar: Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370

python-pyqtchart: '/usr/bin/python3-sip' is not an executable
https://koji.fedoraproject.org/koji/taskinfo?taskID=28223996


On this last one at least - it appears that the python3-sip executable was 
removed in the packaging.  I've got a query into Rex about whether what 
was intentional or not.


Scott___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3XSCEKTZQRBJTUPNIGZTFAXB4WB75W4Y/

Re: F29 Self Contained Change: Deprecate YUM 3

2018-07-16 Thread Neal Gompa

On Mon, Jul 16, 2018 at 8:01 AM Tom Hughes  wrote:
>
> On 12/07/18 09:15, Daniel Mach wrote:
>
> > On Thu, Jul 5, 2018 at 9:45 PM, Kevin Fenzi  > > wrote:
> >
> > koji is kinda important. I think this is meaning python2-koji?
> > I would hope python3-koji/koji stays around?
> >
> > ditto
>
> I believe koji is only in the list because it has a require
> on createrepo which (a) it doesn't really need as it can be
> configured to use createrepo_c instead and (b) won't be a
> problem once createrepo_c provides createrepo which I thought
> was supposed to be happening?
>

Koji contains an embedded copy of mergerepos from createrepo, which
does depend on YUM, and this can be ignored by telling Koji to use
createrepo_c. But it also uses YUM for repomd parsing and multilib
handling for creating dist-repos. These two functions need to be
ported, or otherwise Koji will effectively be broken in Fedora.

And dist-repos are important, since Fedora RISC-V and a number of
external Koji deployments use them.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/U2YYU4QKYUICUW2WMBNIFOJVZRKWA2L3/

[Bug 1601452] New: perl-Net-DNS-1.16 is available

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

Bug ID: 1601452
   Summary: perl-Net-DNS-1.16 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-DNS
  Keywords: FutureFeature, Triaged
  Assignee: pwout...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, ka...@ucw.cz,
mbar...@fastmail.com,
perl-devel@lists.fedoraproject.org,
pwout...@redhat.com, rhug...@redhat.com,
rstr...@redhat.com, sandm...@redhat.com



Latest upstream release: 1.16
Current version/release in rawhide: 1.15-2.fc29
URL: http://search.cpan.org/dist/Net-DNS/

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

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

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

Based on the information from anitya: 
https://release-monitoring.org/project/3147/

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/NQO2SAMPRI57ETX7HBLFAWAZEAPL46HL/

[Bug 1601289] perl-Mail-JMAPTalk-0.12 is available

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



--- Comment #3 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.12-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6bd39a6fe9

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ON2CHYITF77K4NGTQM3GEWTKQVHG4OWW/

[Bug 1601443] New: perl-libwww-perl-6.35 is available

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

Bug ID: 1601443
   Summary: perl-libwww-perl-6.35 is available
   Product: Fedora
   Version: rawhide
 Component: perl-libwww-perl
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, ka...@ucw.cz,
mbar...@fastmail.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com



Latest upstream release: 6.35
Current version/release in rawhide: 6.34-2.fc29
URL: http://search.cpan.org/dist/libwww-perl/

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

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

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

Based on the information from anitya: 
https://release-monitoring.org/project/3024/

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/IHIZRTXIW4N62MW73UWOBZ6R6GUUPZOV/

[Bug 1601289] perl-Mail-JMAPTalk-0.12 is available

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



--- Comment #2 from Fedora Update System  ---
perl-Mail-JMAPTalk-0.12-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-133b3f2950

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/CNXKQAHQBQH6COBIQNJCWTFCYRVYXMTT/

[Bug 1601289] perl-Mail-JMAPTalk-0.12 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Mail-JMAPTalk-0.12-1.f
   ||c29



--- 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/CIV5F75LFU2ARAQA6S6ABWZASC3N4XUO/

[Bug 1601286] perl-DB_File-1.842 is available

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



--- Comment #3 from Fedora Update System  ---
perl-DB_File-1.842-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e840a1ac40

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/WXL67RLQLMM274PUY4K4VTGVTEZXHS4R/

[Bug 1601286] perl-DB_File-1.842 is available

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



--- Comment #2 from Fedora Update System  ---
perl-DB_File-1.842-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-584af79991

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/XDYFMBPVZUQZOKDOPCLA2SLWLHS3TZQ6/

[Bug 1601286] perl-DB_File-1.842 is available

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-DB_File-1.842-1.fc29



--- 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/2RH7SJ4BNTEUSCXTMQDMIJN7NKGS7CEZ/

[Bug 1601131] perl-Test-POE-Client-TCP-1.22 is available

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



--- Comment #4 from Fedora Update System  ---
perl-Test-POE-Client-TCP-1.22-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-174f525e37

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TIGUCXVPLJMASBVUO6LCPT6GBUDPIQWL/

[Bug 1601131] perl-Test-POE-Client-TCP-1.22 is available

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



--- Comment #3 from Fedora Update System  ---
perl-Test-POE-Client-TCP-1.22-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-72f67df677

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/UUO7GJU3KSYYIXV3TR62KPBS4HRGUUHJ/

Re: transfig license change

2018-07-16 Thread Honza Horak


On 07/16/2018 09:59 AM, Hans de Goede wrote:

Hi,

On 15-07-18 09:11, Honza Horak wrote:

License of transfig package was changed
from: MIT
to: MIT and GPLv3+

https://src.fedoraproject.org/cgit/rpms/transfig.git/commit/?id=fe80b4977bc3a9a3c47497a0042a2ca4a5001ba8 



The fig2dev/lib/.c files are not used when building on Linux, after adding:

rm fig2dev/lib/.c

To "%setup" the package still builds fine and without the rm, no .o files
are generated, so I believe that the correct license is just MIT.

Please change the license tag back to just MIT to correctly reflect
the license of the binaries in the package which is just MIT as the
GPL licensed files are not used for building.


Change reverted, sorry for mystification.


Also in the future if you add combined license tags because of something
like this, please put a comment in the .spec file above the License
tag explaining why it is that way, rather then hiding this in the commit
message of the commit changing the license tag.


OK, will do.

Honza


Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SI4HB3FZC55VAKYCKIXHNGC7RBL4YZM3/ 


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2JECSAKMG5OKNFTCPS2D4MBGUZJE4BCJ/

[Bug 1601131] perl-Test-POE-Client-TCP-1.22 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Test-POE-Client-TCP-1.
   ||22-1.fc29



--- Comment #2 from Petr Pisar  ---
An enhancement 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/VQ63RZMRPDVB3SWONP7DOKQJKO7PKMYG/

Re: xfig license change

2018-07-16 Thread Honza Horak


On 07/16/2018 09:54 AM, Hans de Goede wrote:

Hi,

On 15-07-18 09:25, Honza Horak wrote:

License of xfig package was changed
from: MIT
to: MIT and GPLv3+ and LGPLv2+

PR submitted, not yet merged:
https://src.fedoraproject.org/rpms/xfig/pull-request/3

Hans or Steve, please, merge.


The lib/.c files are not used when building on Linux, after adding: "rm 
lib/.c" to "%setup" the package still builds fine and without the rm, no 
.o files are generated, so I believe that the correct license is just MIT


I confirm Hans is correct, sorry for misunderstanding.


It seems I cannot close the pull-req without merging it,
for some reason, can you close it please  ?


Closed.

Thanks,
Honza


Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PXQT4JLIF444F6GUXXFWDADJSX5P4XNZ/ 


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NX77PFN7HDAD7GI72G65TQS5EJ6JWDQF/

Re: sip-related build failures in rawhide

2018-07-16 Thread Antonio Trande

Hi all.

On 16/07/2018 10:04, Miro Hrončok wrote:
> On 15.7.2018 13:24, Alexander Ploumistos wrote:
>> Hello,
>>
>> A few days ago scidavis builds started failing in rawhide. Someone
>> mentioned here that sip was to blame for a number of such failures and
>> according to koschei they started to happen after the update from
>> sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.
> 
> Sorry for stealing the thread, but this might be related:
> 
> libarcus:   Could not find SIP
> https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162
> 
> libsavitar: Could not find SIP
> https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370
> 
> python-pyqtchart: '/usr/bin/python3-sip' is not an executable
> https://koji.fedoraproject.org/koji/taskinfo?taskID=28223996
> 
> 

Also 'avogadro' looks that it's affected by this presumed bug:

https://kojipkgs.fedoraproject.org//work/tasks/2327/28332327/build.log

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NALWC3CUSRDP5YP4DKCLQUFVE5AKU25H/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-16 Thread Igor Gnatenko

On Mon, Jul 16, 2018 at 7:29 AM Federico Bruni  wrote:

>
>
> Il giorno ven 13 lug 2018 alle 12:39, Igor Gnatenko
>  ha scritto:
> > On Fri, Jul 13, 2018, 11:19 Miro Hrončok  wrote:
> >> On 8.7.2018 20:46, Igor Gnatenko wrote:
> >> > As per Changes/Remove GCC from BuildRoot
> >> >
> >> ,
> >> I'm
> >> > going to automatically add BuildRequires: gcc and/or BuildRequires:
> >> > gcc-c++ to packages which fail to build with common messages (like
> >> gcc:
> >> > command not found, also autotools/cmake/meson are supported).
> >> >
> >> > I'm going to do this tomorrow.
> >> >
> >> > After which, I'm going to ask rel-eng to finally remove it from
> >> > buildroot. This will happen before mass rebuild. Stay tuned.
> >> > --
> >>
> >> I've clicked randomly trough failures during the mass rebuild at [1].
> >>
> >> I see quite a lot of commands not founds for gcc, cc, c++...
> >>
> >> I think the maintainers should add them and that's fine, but it
> >> seemed
> >> that during this change you said you will add those. Did it happen?
> >
> > Yes, I've pushed over 2k commits adding those, however regexp might
> > have not catched all possible cases. Would appreciate if you would
> > link such packages so that I can fix them. Or maintainers can do it
> > themselves.
> >
>
> I've just added  and pushed the needed BuildRequires for my package
> (extractpdfmark).
> I didn't bump the release version. Will you do it when you make a new
> mass rebuild?
>
> I see that on 3rd of July the build was successful (despite the missing
> gcc-c++ requirement):
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1102851
>
> Does it mean that the change in koji was implemented only recently?
>

Yes, it was implemented on 10th or something like that. You need to bump
release and rebuild as usual.
-- 

-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A4UGJNX6QJN4LGQII473GGA5D4Q6MAUX/

[Bug 1584479] Slic3r 1.3.0 is available

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

Miro Hrončok  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||slic3r-1.3.0-2.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-16 04:32:49



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JLSNXSWOICB333QU65HGUCSENZPDT5NQ/

Re: sip-related build failures in rawhide


On 15.7.2018 13:24, Alexander Ploumistos wrote:

Hello,

A few days ago scidavis builds started failing in rawhide. Someone
mentioned here that sip was to blame for a number of such failures and
according to koschei they started to happen after the update from
sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.


Sorry for stealing the thread, but this might be related:

libarcus:   Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28195162

libsavitar: Could not find SIP
https://koji.fedoraproject.org/koji/taskinfo?taskID=28197370

python-pyqtchart: '/usr/bin/python3-sip' is not an executable
https://koji.fedoraproject.org/koji/taskinfo?taskID=28223996


Also maybe more Qt related:

cura: ValueError: PyCapsule_GetPointer called with incorrect name
https://koji.fedoraproject.org/koji/taskinfo?taskID=28173387

python-uranium: PyCapsule_GetPointer called with incorrect name
https://koji.fedoraproject.org/koji/taskinfo?taskID=28225965

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ELHAWLNCTYM2OJRHPVQAR7C4UAM6OVB2/

[Bug 1601285] perl-App-cpm-0.975 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-App-cpm-0.975-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-16 04:03:20



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/KSPPVQ32TTPXVEOK7L3HRXJAHR34VVC7/

Re: xfig license change

2018-07-16 Thread Hans de Goede


Hi,

On 15-07-18 09:25, Honza Horak wrote:

License of xfig package was changed
from: MIT
to: MIT and GPLv3+ and LGPLv2+

PR submitted, not yet merged:
https://src.fedoraproject.org/rpms/xfig/pull-request/3

Hans or Steve, please, merge.


The lib/.c files are not used when building on Linux, after adding: "rm lib/.c" to 
"%setup" the package still builds fine and without the rm, no .o files are generated, so 
I believe that the correct license is just MIT

It seems I cannot close the pull-req without merging it,
for some reason, can you close it please  ?


Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PXQT4JLIF444F6GUXXFWDADJSX5P4XNZ/

Re: transfig license change

2018-07-16 Thread Hans de Goede


Hi,

On 15-07-18 09:11, Honza Horak wrote:

License of transfig package was changed
from: MIT
to: MIT and GPLv3+

https://src.fedoraproject.org/cgit/rpms/transfig.git/commit/?id=fe80b4977bc3a9a3c47497a0042a2ca4a5001ba8


The fig2dev/lib/.c files are not used when building on Linux, after adding:

rm fig2dev/lib/.c

To "%setup" the package still builds fine and without the rm, no .o files
are generated, so I believe that the correct license is just MIT.

Please change the license tag back to just MIT to correctly reflect
the license of the binaries in the package which is just MIT as the
GPL licensed files are not used for building.

Also in the future if you add combined license tags because of something
like this, please put a comment in the .spec file above the License
tag explaining why it is that way, rather then hiding this in the commit
message of the commit changing the license tag.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SI4HB3FZC55VAKYCKIXHNGC7RBL4YZM3/

Re: Fedora 29 Mass Rebuild


On 6.7.2018 15:29, Mohan Boddu wrote:

Hi all,

Per the Fedora 29 schedule[1] we will be starting a mass rebuild for 
Fedora 29 very shortly. We are doing a mass rebuild for Fedora 29 for 
all the changes listed in


https://pagure.io/releng/issue/7480

we will start the mass rebuild on 2018-07-11

This is a heads up that it will be done in a side tag and moved over
when completed. We will be running scripts to output failure stats.
please be sure to let releng know if you see any bugs in the reporting.

You can contact releng in #fedora-releng on freenode.

Failures can be seen

https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html


I suspect there will be more rounds? I've pushed several fixes, do I 
need to care about rebuilding those?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZAUZTDRJ47CLZVR4UQYJK3YB5K3FNRUD/

[Bug 1601132] perl-Statistics-Descriptive-3.0701 is available