external screen looses background and panel after sleep/lock
by Sbob
Hi all;
I'm running Fedora 38 on a new LG Gram 17, I have an external monitor
via HDMI cable.
When the screens have gone to sleep and I wake them, I have lost the
background and panel on the external monitor. I can unplug the hdmi
cable and plug it back in to fix, but... Its a pain
Any Ideas? Is my monitor going bad?
2 months, 2 weeks
Mouse cursor
by Gian Piero Puccioni
Hi,
I work 90% of the time in a Konsole terminal and I usually have a couple open with multiple tabs. The problem is that when in a konsole window the mouse cursor is hard to see and after a few seconds it disappears completely. The result is that I waste time looking for the cursor every time I need it..
I have set up "mouse trcking" with "ALT" so I can find it when I remember pressing it but it is annoying...
Is there a setting or option to make the cursor behave differently? Either more visible or "autoflash" when reappears, or something else that make it easyer to find?
Thanks,
G
2 months, 3 weeks
Baloo Question
by Jonathan Ryshpan
System Settings->Search shows the following entries for baloo:
...
/home/jonrysh Indexed
/home/jonrysh Not indexed
~/Documents Indexed
...
What's going on here? Is /home/jonrysh indexed or not, or maybe indexed
in part. If this is a faulty setup, how can it be fixed?
System setup:
Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.9
Kernel Version: 6.3.7-200.fc38.x86_64 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 4600
Manufacturer: ASUS
--
Sincerely Jonathan Ryshpan <jonrysh(a)pacbell.net>
Fiat justitia, ruant coelis!
3 months
Plan / proposal: enable openQA update testing and potentially
gating on Rawhide updates
by Adam Williamson
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
3 months, 2 weeks
Discover is no longer in the tray in F38
by Jonathan Ryshpan
And I don't see any way to put it there. Is this new (lack of)
functionality or am I missing something.
System info (fully updated):
Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9
Kernel Version: 6.2.15-300.fc38.x86_64 (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 4600
Manufacturer: ASUS
--
Sincerely Jonathan Ryshpan <jonrysh(a)pacbell.net>
This sentence have three erors.
3 months, 2 weeks
External screen changing resolution upon wake from sleep
by Sbob
All;
I have just installed Fedora 38 KDE spin on a Dell XPS 17
I had issues with the laptop screen never waking from sleep, that was
while I was using Plasma X11, switching from X11 to Wayland seems to
have fixed the blank laptop screen after sleep issue. However, now I see
this.
- I have my power settings as follows:
dim screen after 5min
screen energy saving = switch off after 10min
suspend session = lock screen after 10min
after the screens had both gone off for some time I unlocked the screens
and found that the external screen had changed resolution to match the
laptop screen, system settings -> display and monitor showed that the
previous resolutions available for the external monitor greater than
that of the external monitor were no longer available, so I have to
reboot to get them back as options
Thanks in advance for any help
3 months, 2 weeks
Screen slides left?
by Mark ＠ GMail
As of a couple of days ago, whenever my cursor touches the right hand
side of the screen, the whole screen slides left, up to 50%, leaving a
black space on the right. Touching the pointer on the left side of the
screen moves it back to the proper position.
I can't find anything in settings that a) has changed and b) would
cause this. Seems like a bug here, anyone else seeing it?
I have all three right-hand-side screen edge points set to "No Action".
I have four virtual desktops.
I can't see any desktop effects that would cause this.
I haven't changed any of these settings for a long time.
Should I report this as a bug or has a recent update (of something
Plasma-ish) changed a setting I should change back (if so, what)?
Many thanks
Mark
Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9
Kernel Version: 6.3.4-201.fc38.x86_64 (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 710/PCIe/SSE2
Manufacturer: ASUS
3 months, 2 weeks
