Just a couple of smallish things after upgrading (via dnf) from F23 to
F24 a couple of months ago:
1. deja-dup gui:
one has to deselect then reselect the Overview option in order
to be offered the "Backup Now" option.
The details option in the progress dialog will only display two
or three lines, is not resizeable, and does not follow resizing the
The progress dialog does not wait to be dismissed at the end,
causing any messages about problems (like failure to backup a particular
file) to not be seen
2. fingerprint identification:
The laptop has a fingerprint reader and it works fine. However
I prefer not to use it. The user set up specifies that fingerprint login
However whenever I am asked for a password the fingerprint
reader blinks until I swipe a finger over it (even after using a
No fingerprint is registered.
This is different than F23 where it never blinked.
3. Scrolling issues:
This, edge and natural scrolling via the touchpad, was covered
nicely in a previous thread.
Solutions offered there work well but should be better
integrated as I am sure they will be.
Desktop is: gnome-desktop3-3.20.2-1.fc24.x86_64
laptop is Thinkpad X240 (Intel graphics)
Not to be a pita, just trying to help
I really like Fedora & the Gnome desktop
Roger Wells, P.E.
221 Third St
Newport, RI 02840
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