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, 4 months
any sign of 4.14 in our future?
by ToddAndMargo
Hi All,
Fedora 29
Xfce 4.13
I have a customer interested in me putting Fedora 29
on a laptop.
Problem: Xfce 4.13 is too buggy to release on the general
public. Me, I am loyal and know how to cope with the bugs,
but a typicall usedr, I would not swiosh that on th em.
Is 4.14 anywhere near?
If not, is there a way to lock Fedora 29 into 4.12?
If not, I guess Mate would be the closest alternative.
I could always go with gnome, but it has a bad cas of
the weirds.
Many thanks,
-T
4 years, 8 months
"Basic graphics mode" feature and criterion discussion
by Adam Williamson
Hi folks!
So at last week's Fedora 30 Beta Go/No-Go meeting, it was decided that
the Basic release criterion:
"Boot menu contents
The boot menu for all supported installer and live images should
include an entry which causes both installation and the installed
system to use a generic, highly compatible video driver (such as
'vesa'). This mechanism should work correctly, launching the installer
or desktop and attempting to use the generic driver."
should no longer apply to Beta - i.e. that it should no longer be a
Basic or Beta criterion.
The justification for this is, I hope I am correctly representing all
views here (please say so if not), that this mechanism is both less
necessary (due to a general reduction in the amount of 'weird' graphics
hardware out there, and general improvement in the reliability and
coverage of the major drivers for the major graphics hardware
manufacturers) and inherently less likely to work (due to the general
trend of work on kernel modesetting and Wayland) than it used to be.
For context, it is worth noting that the *feature* predates the
introduction of both kernel modesetting *and* Wayland to Fedora. What
the feature initially did was tell anaconda to write an X config file
specifying the 'vesa' driver (instead of working out the correct
'native' driver for the adapter and writing a config file specifying
that). After KMS was introduced in Fedora 10, the mechanism was tweaked
to also pass the 'nomodeset' kernel parameter to disable KMS. Around
2012 (https://bugzilla.redhat.com/show_bug.cgi?id=858270) we noticed
that the X config file mechanism was a bit superfluous as 'nomodeset'
alone could basically be relied on to force some sort of 'fallback
mechanism', and so the feature was simplified to *only* specify the
'nomodeset' kernel parameter (this is all it does now).
The *criterion* dates to 2010, in the Fedora 15 release cycle: it
appears in the Fedora 15 Alpha criteria but not the Fedora 14 Alpha
criteria. It was added on 2010-08-16:
https://fedoraproject.org/w/index.php?title=Fedora_15_Alpha_Release_Crite...
The group at the meeting did not, however, make any further decisions,
so this leaves us with some open questions:
0) Do we generally agree with the decision made at the meeting? If
anyone (especially a subject matter expert) strongly believes the
decision was wrong and this should still be a Basic/Beta requirement,
please say so.
1) Should the criterion be modified somehow, but some requirement in
relation to some kind of fallback graphical mode be kept at Basic or
Beta?
2) Should the criterion be moved to Final, unchanged or changed
somehow?
3) Should the requirement just basically be dropped entirely as no
longer useful?
4) (This one mainly for ajax and airlied) to what extent does the
concept of a 'fallback option' for our supported desktop environments
and graphical servers still actually make sense? Could a different
implementation of the same basic idea be envisaged, and would it be
useful? If so, should we do that, and what would be the consequences
for the criteria?
I realize this is quite a big and fuzzy topic, but I'm hoping the
responses to this mail will clarify our path :) So if you have any kind
of useful information or strong opinions on the general area here,
please do contribute them, and hopefully a clearer way forward will
emerge.
Thanks everyone!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 8 months
