Logitech mouse
by Emmett Culley
I have a logitech mouse that has been working well for a long time. Except that every once in a while it suddenly won't scroll one line at a time and instead requires multiple turns of the wheel to move a page.
I've been putting up with this as I am able to fix it by running solaar and toggling scroll wheel resolution off then on again. Only a couple of mouse clicks.
Now it seems to have gotten worse, or I am finally tired of having to stop my workflow to fix it. It seems to be related to the mouse going to sleep during inactivity, though it is random enough so I cannot be sure.
I am on the latest fedora 34 code, and I have been seeing issue since before 32.
Any ideas where to look for a solution?
Emmett
11 months, 2 weeks
Release criteria proposal: networking requirements
by Adam Williamson
Hi folks!
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
networking criteria.
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1 year
Khelpcenter for non-KDE apps
by Patrick O'Callaghan
I've had some recent trouble using Evolution (Gnome) under KDE/Plasma.
The issue is that Evolution would give me a KDE error when trying to
open its Help docs. I tried reporting this the KDE BZ but was rebuffed,
then took it up on the Evolution BZ. You can see the discussion here:
https://bugzilla.redhat.com/show_bug.cgi?id=2057454
Although the immediate problem is solved by using a gio setting (Gnome
again), Milan Crha, the main Evolution maintainer, has some suggestions
as to why this happened and what can be done about it in general. It
might be worth someone's time to take a look from the KDE side and see
what they think. I have no strong opinions either way, but this may not
be an isolated case.
poc
1 year
new release criterion proposal: Graphical package managers
by Kamil Paral
In blocker discussions during the F35 cycle, there were multiple arguments
about what exactly is and is not the required functionality of a graphical
package manager, and it was decided that we'd like to have an explicit
criterion covering those apps in detail. You can find a proposal for this
criterion below, and I'd like to hear your thoughts/concerns. This proposal
was already discussed (and fine-tuned) on the test list, so you can read
the existing discussion there [1] (and even an older one from November as
well [2]).
Please note that we already have package management partly covered in the
Basic criteria [3] and Beta criteria [4]. Please read those first,
including footnotes. The following new criterion is proposed against the
Final milestone:
~~~~~~~~~~~~~~~~~~~~
The default graphical package manager for a given software type must
appropriately:
* Install, remove and update software
* List locally-installed software coming from the official Fedora
repositories
* List available software (possibly in categories, a curated list, etc)
* Display metadata relevant to the selected software (e.g. the description,
screenshots, the size)
* Start the selected installed software
* Configure software sources by enabling/disabling pre-defined official
repositories and then adjust the available software pool accordingly
* Notify the user when system updates are available (taking into account
the intended frequency of such notifications)
The following must hold true:
* When multiple operations (covered by this criterion) are requested, all
of them must finish correctly. (It's also valid to inform the user that a
certain operation is not available at that moment, see the "Supported
functionality and design decisions" note).
* The displayed state of software or software sources must not differ from
their actual state. (E.g. an RPM package must not be shown as installed
when it is not, a repository must not be shown as disabled or missing when
it is enabled, etc).
* Usual GUI interactivity must not break operations covered by this
criterion. (E.g. when the GUI allows the user to click some buttons while
an operation is running, it must not break that operation).
* The package manager must never make the system enter an inconsistent or
unbootable state. (E.g. damage the local software database, remove wrong
system files, break the bootloader, etc).
Note: Supported functionality and design decisions
All requirements apply only if such a functionality is supported by the
package manager; it does not imply that the package manager must support
all this functionality. The requirements don't apply if some functionality
is intentionally modified as a design decision (e.g. if some software
sources can't be disabled as an intentional precaution to users breaking
their system). If there is a bug violating the design decisions in one of
the covered areas (e.g. a software source which is supposed to be always
enabled can be disabled), it's up to the blocker review team to consider
whether this bug makes the user experience or system safety considerably
worse.
Note: Systems in an inconsistent state
While the package manager must not be the primary cause for breaking a
system (unbootable, invalid internal structures, etc), it doesn't have to
'''prevent''' these events from happening. So if there's e.g. a power
outage during its operation or a package with harmful scriptlets is
installed, which breaks the system, this is not the fault of the package
manager and the criteria above are not considered violated. Similarly, when
the package manager operates on an already broken system (e.g. with an
inconsistent rpm database), the correct behavior cannot be guaranteed, and
therefore the criteria also don't apply.
Note: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools][3]
regarding software types, 'appropriate' behavior, scope and so on are all
generally applicable to this criterion also.
~~~~~~~~~~~~~~~~~~~~
Please tell me if this sounds reasonable to you. Thank you.
[1]
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.or...
[2]
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.or...
[3]
https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-re...
[4]
https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing...
1 year, 1 month
KDE critical path barely defined
by Adam Williamson
I noticed today that openQA KDE tests for F34 updates were failing.
After a bit of investigation I found the bug had been filed and is in
the process of being fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=2049560
However, ideally, the bug should never have made it to stable. If
openQA tests had run on the initial update, they would have failed and
gating would have prevented the update going stable.
openQA didn't run on the broken update because the package - qt5-
qtwayland - is not marked as critical path. We only run openQA tests on
critical path updates at present due to capacity limitations.
I've sent a PR to add qt5-qtwayland to the critpath definition:
https://pagure.io/fedora-comps/pull-request/710
but in so doing I noticed the critical-path-kde group is almost empty.
This means when other KDE components are updated, we're not running the
openQA tests and so we won't catch if they break. It would be much
better if someone could come up with a list of critical KDE packages
and populate the group, so that we would properly test and gate updates
with a decent chance of breaking KDE.
Can someone help produce such a list? Thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 1 month
cmake warning when building tellico
by José Abílio Matos
Hi,
this is mostly a development related question.
When building tellico, like in:
https://kojipkgs.fedoraproject.org//packages/tellico/3.4.3/1.fc35/data/lo...
I get warnings like the following:
CMake Warning (dev) at /usr/share/ECM/modules/ECMFindModuleHelpers.cmake:112 (message):
Your project should require at least CMake 3.16.0 to use FindKF5.cmake
Call Stack (most recent call first):
/usr/share/ECM/find-modules/FindKF5.cmake:30 (ecm_find_package_version_check)
CMakeLists.txt:62 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
Is there anything that needs to be done from our side or is this an issue with upstream cmake usage?
Best regards,
--
José Abílio
1 year, 1 month
