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, 1 month
Fwd: 4.14 Release Schedule
by Kevin Fenzi
FYI, some concrete news on 4.14. ;)
We will want to draft up a fedora 31 change page for it asap and perhaps
sign up for a test day?
I'm sure lots of testing will be needed... :)
-------- Forwarded Message --------
From: Simon Steinbeiss <simon(a)xfce.org>
Subject: 4.14 Release Schedule
Hi everyone,
I recently signed up as Release Manager for Xfce 4.14 and am happy to
provide you with some concrete dates for the upcoming weeks and months,
including the announcement of the final date for the 4.14 release.
=== General Notes ===
First of all, we will stick to our official release mode (
https://www.xfce.org/about/releasemodel) also for this release, which means
we will tag each of the three (at least: two) pre-releases - in addition to
the 4.13.x devel release tag - in all git repositories that are part of the
core (example: xfce-4.14pre1). Hopefully this will make it clear which
versions belong to a specific pre-release of 4.14 and will help with
testing the platform as a whole.
This information is especially important to packagers as we have skipped
this step since Xfce 4.8.
=== The Schedule ===
After some internal discussions we have come to the following schedule
(more details here: https://wiki.xfce.org/releng/4.14/roadmap):
19th of May: 4.14-pre1
30th of June: 4.14-pre2
28th of July: 4.14-pre3 (optional; possibly also 4.14-final)
11th of August: 4.14-final
=== How can you help? ===
If you're a developer it's quite clear: clear your schedule, commit
yourself and your code! :)
In all seriousness: almost anyone can help! We'll try to provide a Docker
container of xfce-test (https://github.com/schuellerf/xfce-test) for each
of the pre-releases which can help with testing (and reporting bugs), doing
translations, screenshots, docs etc.
Moral support (on IRC or one of the mailing lists) also counts! ;)
Cheers
Simon
4 years, 5 months
4.12
by ToddAndMargo
Hi All,
Would you guys please consider going back to Xfce 4.12
in Fedora 30? Xfce 4.13 is just too buggy to let loose
on my customers!
Me? I work around them and have reported a ton of them.
But way too many problems for a non-technical customer.
I have just been installing Fedora 28, which is near end
of life or just jumping to Mate. And I really do
adore Xfce.
Guess there is no change of Xfce 4.14 in Fedora 30?
Many thanks,
-T
4 years, 5 months
Re: "Basic graphics mode" feature and criterion discussion
by Adam Williamson
On Tue, 2019-04-02 at 12:07 -0600, Chris Murphy wrote:
> On Tue, Apr 2, 2019 at 4:19 AM Kamil Paral <kparal(a)redhat.com> wrote:
> > On Mon, Apr 1, 2019 at 9:04 PM Adam Williamson <adamwill(a)fedoraproject.org> wrote:
> > > "The boot menu for all release-blocking 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')."
> >
> > Maybe change "causes" to "attempts", so that it's clear it has to
> > do something (e.g. add a kernel cmdline option), but the thing
> > doesn't have to succeed ("causes" sounds to me like a successful
> > attempt).
>
> Agree.
>
> > > At Final we would add this requirement:
> > >
> > > "The generic video driver option ('basic graphics mode') on all
> > > release-blocking installer and live images must function as intended
> > > (launching the installer or desktop and attempting to use a generic
> > > driver), and there must be no bugs that clearly prevent the installer
> > > or desktop from being reached in this configuration on all systems or
> > > on wide classes of hardware."
> >
> > Here I'd probably remove "attempting" in favor of a stricter "using
> > a generic driver". But even your version sounds ok.
>
> I agree.
OK, I'm gonna go ahead and push this change out with both of Kamil's
proposed changes. Thanks folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 6 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, 6 months
Re: "Basic graphics mode" feature and criterion discussion
by Adam Williamson
On Tue, 2019-03-26 at 14:30 -0600, Chris Murphy wrote:
> My two cents:
>
> If there's a fallback option, and if the user selects it, they
> shouldn't end up in an unambiguous state. Right now we're seeing
> systems hanging. I'd rather see a crash than a hang where the user
> can't get to a shell, and sees no useful information on the screen
> that tells them why they're hung up; or even generically that "by now
> you should see a login screen and if you don't we've faceplanted
> somewhere, sorry".
>
> Maybe split the criterion:
>
> Basic criterion: installation media must have a basic video boot entry
> that uses the accepted fallback boot parameter(s), e.g. nomodeset. The
> criterion just means the media must have the menu entry, and that it
> passes something intentional for this purpose as a boot parameter.
>
> Final criterion: installation media's basic video boot entry should
> either work (we get a successful graphical boot), or it should
> faceplant in some unambiguous way.
>
> If it's not possible to ensure basic video either works as intended or
> faceplants unambiguously; then I suggest dropping any beta or final
> criterion. And also I wonder if it's at all useful to include some
> kind of heads up description for the basic video boot entry? Like,
> "this may not work at all" or "wait 5 minutes for graphical boot,
> after 10 minutes assume it failed". Haha - I have no idea. Just
> something so they aren't waiting around going WTF? Now what?
So kinda aggregating all the response to this discussion, I propose we
go with a modified version of Chris' proposal.
1. We retain the 'entry must exist' part of the criterion at Basic (but
at that point it does not have to *work* - the idea is to ensure it's
testable so we catch bugs in it at that point)
2. We move the rest of the criterion to Final and tweak it a bit to
specify that it must be at least somewhat capable of reaching the
installer or desktop. We do not adopt Chris' "or faceplant
unambiguously" proposal, people seemed to prefer just requiring it to
work.
So, here's the specific text I propose. At Basic we would change this
requirement:
"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."
To read only:
"The boot menu for all release-blocking 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')."
i.e. remove the second sentence (and change 'supported' to 'release-
blocking' - that is a better form of words that should have been used
all along).
At Final we would add this requirement:
"The generic video driver option ('basic graphics mode') on all
release-blocking installer and live images must function as intended
(launching the installer or desktop and attempting to use a generic
driver), and there must be no bugs that clearly prevent the installer
or desktop from being reached in this configuration on all systems or
on wide classes of hardware."
How does that sound to everyone? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 6 months
