xfce January 2019

xfce@lists.fedoraproject.org

11 participants
7 discussions

Removal of Python 2 from the Xfce spin
by Miro Hrončok 11 Aug '19

11 Aug '19

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

6 15

Different approach to KDE and XFCE desktop testing?
by Lukas Ruzicka 28 Jan '19

28 Jan '19

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 6

Removal of Python 2 from the Xfce spin: gnumeric
by Bruce Hohl 12 Jan '19

12 Jan '19

> 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.

3 6

vim sometimes hiding 0 qnd 00
by Michael D Berger 09 Jan '19

09 Jan '19

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

1 0

Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok 09 Jan '19

09 Jan '19

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

2 2

Rawhide Xfce Spin
by Miro Hrončok 08 Jan '19

08 Jan '19

Is there any build of rawhide Xfce spin? I cannot fins one here: https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Spins/x86… What would be the easiest way to install Rawhide with Xfce? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 3

evolution leaving behind a ghost window
by Viorel Tabara 02 Jan '19

02 Jan '19

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

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

xfce January 2019