Removal of Python 2 from the Xfce spin
by Miro Hrončok
Hi, we've successfully removed Python 2 from default Workstation installation
years ago, today I'd like to see if we could do it in Xfce Spin as well.
For those not in the picture: Python 2 ill EOL in 11 months, 22 days [0].
We are trying to get rid of it as much as possible in Fedora [1][2].
Eliminating Python 2 from our defualt installations is an important step here.
Today, if I try to uninstall python2 from Xfce spin (rawhide), this is what gets
removed as dependent:
NetworkManager-openconnect-gnome
blueberry
gnumeric
python2-catfish
system-config-keyboard
system-config-users
Several others go as no longer needed, mostly python2 libs, but also:
NetworkManager-openconnect
bluez-obex
bluez-tools
openconnect
wmctrl
While I doubt the actual usefulness of gnumeric, what bothers me is:
1. It seems that the Bluetooth stack is entirely gone. Do we have an viable
alternative?
2. If openconnect is not needed on Workstation, why is it needed in Xfce?
3. Can we set keyboards/users with some alternatives? system-config-* still link
to fedorahosted as upstream and haven't received an update in years. They seem
pretty upstream dead to me.
4. Catfish is Python 3 compatible, but the Fedora maintainer is not [4].
Thanks for tips.
[0] https://pythonclock.org/
[1] https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
[2] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal
[3] https://src.fedoraproject.org/rpms/catfish/pull-request/1#
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 8 months
Different approach to KDE and XFCE desktop testing?
by Lukas Ruzicka
Hello KDE and XFCE teams,
I am writing to you on behalf of the Fedora QA team, because you are the
stakeholders of release-blocking desktop environments in Fedora.
We believe that there is need to revisit and review some of the approaches
we
have in desktop testing. I hope that I can clarify in the text.
*How do we test desktop applications?*
Currently, there are three desktop environments, which block the Fedora
releases: GNOME, KDE, and XFCE (on ARM). Among others, there is a test case
called “Desktop Menus” [
https://fedoraproject.org/wiki/QA:Testcase_desktop_menus ] which is used
for all three desktop environments.
*What is the purpose of the Desktop Menus test case?*
The purpose of the “Desktop Menus” test case is to test that applications
listed
in the menu do generally work. That means that each application in the
default
system menu must launch without crashing and withstand basic usage. [2]
*What problems can arise when trying to follow the test case?*
This approach leaves a lot of space for variability, because the terms are
not
clearly given, especially when talking about “basic functionality” of the
desktop applications. In the past, there have been some disputes during
Blocker
Review meetings, or during Go/No go meetings whether basic functionality is
broken or not. It's usually up to group judgement to decide what is a basic
functionality and what it beyond that, which means as testers we need to
err on
the side of doing more testing rather than less.
Testing the “Desktop Menus” test case is one of the most time consuming test
case we currently have. In GNOME, there are currently about 40 applications
in
the default menu and all need to be started and their basic functionality
tested. In KDE, the number of applications is even higher, and some
application
types (like web browsers) are even present as several different
applications.
The scope of this test case also covers testing the subcomponents in the
Control
Center (or a similar equivalent) and, usually, such subcomponents are
numerous.
Testing XFCE on ARM is also rather time consuming, because the ARM devices
we
can use for testing are very slow and there are some application that make
little sense on an ARM motherboard (e.g. a CD writing software). Thus,
doing a
thorough Desktop Menus test case requires a rather longish time frame and we
lose time we could devote to different problems.
Besides that, the test case is also very boring, so it usually gets tested
by
Fedora QA members only, with few inputs from the community. So, before the
Beta
and Final release we are able to do such tests a couple of times, but the
overall coverage is not big.
*What could we do about it?*
At Fedora QA, we have been trying to come up with some ideas to make the
situation a little better than it is now. The goal is that the important
areas
get enough attention and testing they deserve, and we avoid shipping broken
and
under-tested software. See the ideas below and please tell us if you could
adopt
all/some of them, or if you have different suggestions to improve the
current
state, we'd love to hear them too.
- The list of pre-installed applications could be pruned of those which
don't make much sense for that particular purpose (e.g. CD writing software
on ARM, or perhaps on any system nowadays).
- Pre-installed applications could be deduplicated where possible (e.g.
not having several web browsers pre-installed by default).
- We could define a list of "important" applications that would be
tested thoroughly and the basic functionality criterion would apply just to
them. That would tell QA where to focus. (This would obviously contain
applications like system settings, file browser, text editor, browser,
terminal emulator, etc. But e.g. a screenshot utility would probably not
fall into the list. Also, in case of duplicated apps, only one of those
could be marked as "important", and the others would* not). The rest of the
applications would be just best effort in terms of QA, and wouldn't block
the release.
- Last but not least, you could help us more with release validation
before relevant milestones (Beta, Final) :-) If there's anything that
should be improved on our part (communication, instructions, etc), we'd
love to hear that.
Please, let me know what you think about the ideas proposed above. Do you
have
any other ideas that could help us improve the quality (with the same
amount of
testing force)?
Best regards,
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
5 years, 2 months
Removal of Python 2 from the Xfce spin: gnumeric
by Bruce Hohl
> Today, if I try to uninstall python2 from Xfce spin (rawhide), this is
what
> gets removed as dependent: ... gnumeric ...
> While I doubt the actual usefulness of gnumeric ...
Two comments:
(1) python should not be (is not) a dependency for gnumeric per the
following:
https://packages.debian.org/sid/gnumeric
http://gnome-apps.13852.n7.nabble.com/gnumeric-amp-python2-td71380.html
Maybe the Fedora gnumeric package can be edited.
(2) Over an accounting career I've used Lotus, Excel, Gnumeric,
LibreOffice, and Google Sheets. Here is my quick judgement: Lotus is
gone, Excel & Libre are slow loading and basically always have some
annoying but not show stopping bugs, gSheets requires the internet and
doesn't natively provide portable docs. gnumeric is stable, fast loading,
has no observed bugs for basic use, provides portable docs, and includes
all core spreadsheet functionality. It makes sense as a component of the
lighter weight xfce spin.
5 years, 3 months
vim sometimes hiding 0 qnd 00
by Michael D Berger
With recently installed CentOS 7.6 and xfce,
using vim to edit .dircolors, with vim colors enabled, I discovered on the
line
DIR 01:36 # directory
if I change the 01 to 0 or 00 , (but not 000) zeros disappears. If I search
for 00, it is found.
This happens for other, but not all lines. I could prevent this with
syntax off
but then I lose the colors, which are helpful.
How can I prevent anything from disappearing like this without losing the
colors?
This problem does not occur using the same vim at level 3, but there I have
fewer colors.
Thanks,
Mike.
-
Michael D. Berger
m.d.berger(a)ieee.org <mailto:m.d.berger@ieee.org>
http://www.rosemike.net
5 years, 3 months
Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok
On 09. 01. 19 10:31, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 09, 2019 at 09:34:54AM +0100, Miro Hrončok wrote:
>> Today, if I try to uninstall python2 from Xfce spin (rawhide), this is what
>> gets removed as dependent:
>>
>> NetworkManager-openconnect-gnome
>> blueberry
>> gnumeric
>> python2-catfish
>> system-config-keyboard
>> system-config-users
>>
>> Several others go as no longer needed, mostly python2 libs, but also:
>>
>> NetworkManager-openconnect
>> bluez-obex
>> bluez-tools
>> openconnect
>> wmctrl
>>
>> While I doubt the actual usefulness of gnumeric, what bothers me is:
> Maybe drop gnumeric, at least from the default installation? I really
> liked gnumeric, it is lightweight and well designed, but its time seems
> to have passed. I don't think we're doing anybody any favours by
> encouraging people to use it.
Exactly.
>> 1. It seems that the Bluetooth stack is entirely gone. Do we have an viable
>> alternative?
> Hmm, in F29 workstation, I have bluez-obexd.x86_64 installed, and
> "sudo dnf remove python2" doesn't touch it. What is the dependency
> chain that you see?
bluez-obexd was only removed as it was no longer required. The primary thing
that got blasted by py2 removal was blueberry.
>> 2. If openconnect is not needed on Workstation, why is it needed in Xfce?
>>
>> 3. Can we set keyboards/users with some alternatives? system-config-* still
>> link to fedorahosted as upstream and haven't received an update in years.
>> They seem pretty upstream dead to me.
>
>> 4. Catfish is Python 3 compatible, but the Fedora maintainer is not [4].
> I rebuilt the package with your PR. I hope I won't get flamed to death ;)
Well it's my commit, so maybe I will get flamed :D
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 years, 3 months
evolution leaving behind a ghost window
by Viorel Tabara
I started noticing this after upgrading to F29. It happens occasionally
and only when sending a message (I use Ctrl-Enter to send).
Right-click on window on the task bar and select close brings up the
force close dialog box and saying 'yes' it closes the Evolution main
window.
'xkill' which I've come across helped with cleaning up the workspace:
omiday ~ $ xwininfo
xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.
xwininfo: Window id: 0x108e021 (has no name)
Absolute upper-left X: 176
Absolute upper-left Y: 50
Relative upper-left X: 176
Relative upper-left Y: 50
Width: 1281
Height: 833
Depth: 24
Visual: 0x21
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (not installed)
Bit Gravity State: StaticGravity
Window Gravity State: StaticGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +176+50 -463+50 -463-197 +176-197
-geometry 1281x833+176+50
omiday ~ $ xkill -id 0x108e021
xkill: killing creator of resource 0x108e021
The ghost window can be resized, and it would "remember" the contents of
a window from another workspace when I select it, switch to another
window in another workspace and return.
Anyone have similar issues?
-Viorel
5 years, 3 months