On Fri, 2016-09-30 at 23:22 +0200, Thomas Moschny wrote:
> this is a heads-up about the pytest update to version 3.0.3 that just
> hit rawhide.
> A number of incompatible changes were made in 3.0.0 compared to 2.9.2.
> See http://doc.pytest.org/en/latest/changelog.html for the full list of
> changes and new features.
> If you got this email directly, then your package (SRPM) depends on
> pytest. Please check, whether it builds and works with the new pytest
> release. This especially holds for the pytest plugins, some of which
> definitively need to be updated to support pytest 3.0.
> Here's the list of packages that (according to dnf repoquery)
> build-depend on pytest:
I don't think you made this query wide enough. It doesn't list fedfind,
for instance, which has:
%endif # if with_python3
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
Forwarding this on from announce for any intested parties.
Begin forwarded message:
Date: Fri, 30 Sep 2016 23:22:07 +0200
From: Thomas Moschny <thomas.moschny(a)gmx.de>
Subject: pytest 3.0 in rawhide
this is a heads-up about the pytest update to version 3.0.3 that just
A number of incompatible changes were made in 3.0.0 compared to 2.9.2.
See http://doc.pytest.org/en/latest/changelog.html for the full list of
changes and new features.
If you got this email directly, then your package (SRPM) depends on
pytest. Please check, whether it builds and works with the new pytest
release. This especially holds for the pytest plugins, some of which
definitively need to be updated to support pytest 3.0.
Here's the list of packages that (according to dnf repoquery)
build-depend on pytest:
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to
On Fri, Sep 30, 2016 at 4:41 PM, Josh Berkus <jberkus(a)redhat.com> wrote:
> On 09/30/2016 01:11 PM, Adam Miller wrote:
>> On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
>> <mattdm(a)fedoraproject.org> wrote:
>>> On Thu, Sep 29, 2016 at 04:16:15PM -0700, Adam Williamson wrote:
>>>>> think QA clearly understands what cloud image(s) are release blocking,
>>>>> as previously they were just the non-atomic images.
>>>> Which images are prominent on the download pages and how much of a
>>>> relationship there is between that and 'release blocking' status is
>>>> *also* not my problem, but I'd agree with you (Chris) that it'd be
>>>> rather strange for the most prominently advertised deliverable for a
>>>> given product not to be a release-blocking one.
>>> I don't think that Atomic *needs* to be release blocking, because if it
>>> misses the grand unified release, we have the ability to update it at
>>> the next cycle, so it's less of a big deal. But if we collectively
>>> prefer to make sure everything is lined up on the release day... I can
>>> see arguments for that, too.
> Well, currently I'm working with the designers on a new page for Atomic
> F25. So if that's NOT going to be live the day of the F25 release, then
> it's something we need to know ahead of time.
> I also really don't like the message Atomic not being ready sends. We
> will have three branches for GetFedora: Workstation, Server, and Atomic.
> If Atomic isn't ready the day of the release, it looks pretty bad;
> that's saying we're ok with only being 2/3 ready, or that despite
> promoting Atomic to 1st class status we don't really believe it's important.
So... there is a pretty big disparity between what you just said and
what FESCo has been told in the past two meetings. Jan has been
trying to get release blocking deliverables for the Cloud WG (now
Atomic?) confirmed for a while . Two weeks ago, Kushal confirmed
the existing base images are release blocking and Atomic is not. That
was repeated in today's meeting as well:
16:44:56 <kushal> Cloud base image is the only blocking deliverable.
16:44:59 <kushal> Atomic is not.
I realize this WG is in the middle of rebooting itself, but to have
clearly conflicting information from the WG members is a bit
= Proposed System Wide Change: OpenSSL 1.1.0 =
* Tomas Mraz <tmraz AT redhat DOT com>
Rebase of OpenSSL package to 1.1.0 version
== Detailed Description ==
Update the OpenSSL library to the 1.1.0 branch in Fedora to bring
multiple big improvements, new cryptographic algorithms, and new API
that allows for keeping ABI stability in future upgrades. We will also
add compat openssl102 package so the applications and other
dependencies which are not ported yet to the new API continue to work.
== Scope ==
* Proposal owners:
Prepare and test rebased openssl package. Prepare and test compat
openssl102 package. Help with patching and rebuilding dependent
* Other developers:
Patch and rebuild your package if it uses OpenSSL library (proposal
owner will help).
* Release engineering:
N/A unless we decide that separate branch is needed. Mass rebuild will
not help as the packages have to be patched for the API changes.
* List of deliverables:
* Policies and guidelines:
* Trademark approval:
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Something between F23 and F24 broke coredumpctl in Fedora. It's still
broken. Appears to be an SELinux bug. It's reported as . I want
coredumpctl to be enabled by default in F26 as a F26 feature, but I can
hardly go ahead and propose that while it's still broken. It would be
great if the SELinux developers could look into the issue. systemd
developers have been responsive and already left several comments in
the bug, but I've failed to get the attention of SELinux folks thus
Greetings, we've been told that the email addresses
for these package maintainers are no longer valid. I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS). If they're not interested in maintaining or we
can't locate them I'll have FESCo orphan the packages so that others
can take them over.
If you have a way to contact these maintainers, please let them
know that we'd appreciate knowing what to do with their packages.
Point of contact:
rpms/geoclue2 -- Geolocation service ( master f25 f24 f23 )
rpms/geocode-glib -- Geocoding helper library ( master f25 f24 f23 )
Point of contact:
rpms/ceelog -- Tool for receiving, filtering and searching CEE/Lumberjack logs ( master f25 f24 f23 )
rpms/liblogging -- An easy to use logging library ( master f25 f24 f23 )
rpms/libmongo-client -- Alternative C driver for MongoDB ( master f25 f24 f23 epel7 )
rpms/librelp -- The Reliable Event Logging Protocol library ( master f25 f24 f23 )
rpms/libumberlog -- CEE-enhanced syslog API library ( master f25 f24 f23 )
rpms/rsyslog -- Enhanced system logging and kernel message trapping daemon ( master f25 f24 f23 )
Point of contact:
rpms/rubygem-simple_form -- Flexible and powerful components to create forms ( master f25 f24 f23 )
Point of contact:
rpms/drpm -- A library for making, reading and applying deltarpm packages ( master f25 f24 f23 )