I noticed recently that each time I send an email to the kde(a)lists.fedoraproject.org mailing list I get up to three failed DMARC reports from other email servers.
The list is sending email "from" me with the source address:
Source-IP: 38.145.60.11 (bastion-iad01.fedoraproject.org)
Which, of course, does not match up with my email server's IP address, so SPF fails, It also appears that DKIM signature also does not match.
I've had my server's DNS set up to request DMARK failure reports for a few years and haven't seen any reports lately except via this list. So I am wondering if something is mis-configured on this list server.
Emmett
Looking over some broken deps reports, I came across some old packages:
kdebindings
smokeqt
smokekde
qyoto (csharp/mono)
kimono (csharp/mono)
ruby-qt
ruby-korundum
perl-Qt
Of these, the only one that's not a pure leaf package is perl-Qt (debconf-
kde depends on it).
any comment or objection to considering orphaning most (all minus
smokeqt/perl-Qt) or all of these ?
-- Rex
Hi folks!
We've had openQA testing of updates for stable and branched releases,
and gating based on those tests, enabled for a while now. I believe
this is going quite well, and I think we addressed the issues reported
when we first enabled gating - Bodhi's gating status updates work more
smoothly now, and openQA respects Bodhi's "re-run tests" button so
failed tests can be re-triggered.
A few weeks ago, I enabled testing of Rawhide updates in the openQA
lab/stg instance. This was to see how smoothly the tests run, how often
we run into unexpected failures or problems, and whether the hardware
resources we have are sufficient for the extra load.
So far this has been going more smoothly than I anticipated, if
anything. The workers seem to keep up with the test load, even though
one out of three worker systems for the stg instance is currently out
of commission (we're using it to investigate a bug). We do get
occasional failures which seem to be related to Rawhide kernel slowness
(e.g. operations timing out that usually don't otherwise time out), but
on the whole, the level of false failures is (I would say) acceptably
low, enough that my current regime of checking the test results daily
and restarting failed ones that don't seem to indicate a real bug
should be sufficient.
So, I'd like to propose that we enable Rawhide update testing on the
production openQA instance also. This would cause results to appear on
the Automated Tests tab in Bodhi, but they would be only informational
(and unless the update was gated by a CI test, or somehow otherwise
configured not to be pushed automatically, updates would continue to be
pushed 'stable' almost immediately on creation, regardless of the
openQA results).
More significantly, I'd also propose that we turn on gating on openQA
results for Rawhide updates. This would mean Rawhide updates would be
held from going 'stable' (and included in the next compose) until the
gating openQA tests had run and passed. We may want to do this a bit
after turning on the tests; perhaps Fedora 37 branch point would be a
natural time to do it.
Currently this would usually mean a wait from update submission to
'stable push' (which really means that the build goes into the
buildroot, and will go into the next Rawhide compose when it happens)
of somewhere between 45 minutes and a couple of hours. It would also
mean that if Rawhide updates for inter-dependent packages are not
correctly grouped, the dependent update(s) will fail testing and be
gated until the update they depend on has passed testing and been
pushed. The tests for the dependent update(s) would then need to be re-
run, either by someone hitting the button in Bodhi or an openQA admin
noticing and restarting them, before the dependent update(s) could be
pushed.
In the worst case, if updated packages A and B both need the other to
work correctly but the updates are submitted separately, both updates
may fail tests and be blocked. This could only be resolved by waiving
the failures, or replacing the separate updates with an update
containing both packages.
All of those considerations are already true for stable and branched
releases, but people are probably more used to grouping updates for
stable and branched than doing it for Rawhide, and the typical flow of
going from a build to an update provides more opportunity to create
grouped updates for branched/stable. For Rawhide the easiest way to do
it if you need to do it is to do the builds in a side tag and use
Bodhi's ability to create updates from a side tag.
As with branched/stable, only critical path updates would have the
tests run and be gated on the results. Non-critpath updates would be
unaffected. (There's a small allowlist of non-critpath packages for
which the tests are also run, but they are not currently gated on the
results).
I think doing this could really help us keep Rawhide solid and avoid
introducing major compose-breaking bugs, at minimal cost. But it's a
significant change and I wanted to see what folks think. In particular,
if you find the existing gating of updates for stable/branched releases
to cause problems in any way, I'd love to hear about it.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
Hi all;
I can create a new profile in Konsole:
Settings -> Manage Profiles -> New
and the new profile shows up for :
Settings -> Switch Profile
But it only shows for the current Konsole window, If I open another
Konsole window then the new profile is not there
Thanks in advance for any advice
I have a new touchscreen laptop, installed Fedora 36 - KDE spin on it.
Can I set it up so when I open Konsole, or firefox that the virtual
keyboard will pop up?
Thanks in advance
All;
I just picked up a surface prom 8, tried an install of F36 / Gnome but
the touch screen does not work. Anyone know if KDE has better support?
anthing else I need to install?
Thanks in advance
I have both an internal (IGP) graphics chip on the motherboard, and an
AMD add-on card. Using Gnome, there is an option to "Run <application>
on discrete graphics card", but I don't see an equivalent with Plasma.
Any suggestions?
poc
# F37 Blocker Review meeting
# Date: 2022-11-07
# Time: **15:00** UTC
# Location: #fedora-blocker-review on irc.libera.chat
Hi folks! We have 1 proposed blocker and 1 proposed freeze exception to
review, so let's have a review meeting.
Note that clocks went back in North America this weekend, so the
meeting time is one hour earlier in UTC. If your clocks went back this
weekend, the meeting will be the same time as before in your local
time. If your clocks didn't change, the meeting will be one hour
earlier in your local time.
If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F36 can be found on the
wiki [0].
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
Have a good night and see you tomorrow!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
Hi all;
I cannot enable bluetooth, running Fedora 36 - KDE spin on a DELL XPS 17
If I go to system settings -> bluetooth I see a message that says
Bluetooth is disabled with a button that says enable, but clicking the
button does nothing.
Thoughts?