On 3/29/19 7:32 PM, Sam Varshavchik wrote:
ToddAndMargo via users writes:
On 3/29/19 6:34 PM, Sam Varshavchik wrote:
xfce 4.13 has been fine for me.
4.13 has been a pain in my neck:
Libre Office pulses at me
https://bugzilla.xfce.org/show_bug.cgi?id=14863
That's the one that I find the most annoying. But it's not a showstopper.
Black backgrounds in panels
https://forum.xfce.org/viewtopic.php?pid=50266#p50266
I've noticed some occasional glitches like that.
I guess that my standards are pretty low. I don't mind minor,
non-critical bugs like this, and just write it off as a cost of doing
business.
Clicking on MTP device crashes Thunar
https://bugzilla.xfce.org/show_bug.cgi?id=15172
That's probably the only one I'd consider to be a showstopper. Reminds
me of a bug that tipped the scales for me in the other direction: way
back when, Gnome's file manager decided one day that my usb-storage mp3
player was an MTP device. Hillarity ensued. The bug collected dust for a
year, before I ditched Gnome and went with XFCE, after I noticed that
the lightweight XFCE build I installed on a netbook happily mounted the
same MP3 player.
Ditching the unusable "usability-improved" Gnome 3 was also a bonus.
Never looked back.
Default browser does not work
https://bugzilla.xfce.org/show_bug.cgi?id=15238
AAAAAAAHHHHHHHHHHHH!!!!!
I don't think there's a viable way to down or upgrade xfce. If it was
only one RPM, I would seriously look into rebuilding it. But it's quite
a few dependencies, and probably a whole pile of packages needs to be
rebuilt.
If I were to try this experiment, this is how I would proceed (of
course, its unrealistic to expect Joe sixpack to put up with this, I
understand this):
1) Grab the newer XFCE base library package, and attempt to hack the
current XFCE source rpm to build it. There's a reasonable chance all
that needs to be done is to bump the version number in the source RPM.
Assuming that the rebuild succeeds (and if not, one will simply have to
figure out why, and there's no cookie-cutter recipe for that, you're way
off the beaten path): I would try a test upgrade, using rpm with the
--test option.
2) I would actually think that a dependency failure would be the best
result. This will tell you which packages need to be rebuilt next. At
this time I would switch to mock, install the upgraded xfce packages in
a mock buildroot, and proceed to attempt to build the newer RPM of each
package.
3) If there wasn't a dependency failure, I would proceed cautiously.
Upgrading the base package would be ok, but it may or may not solve your
issues, in which case you'll have to guess which next part of the stack
you want to upgrade.
If I were to proceed at all, I would go the upgrade rather than a
downgrade root. After downgrading, dnf will keep wanting to upgrade xfce
every time. I think there's a way to lock it.
One possible answer to this conundrum is the modular Fedora effort. I've
only been following it with half an ear, but at least on paper it seems
to address this very issue: offer alternative version of Fedora
components. But someone has to volunteer to maintain all of that stuff,
of course…
For me, I adore Xfce and know how to put up with 4.13 (odd numbers are
testing releases).
For customers, I would not let 4.13 loose on them. I will probably
use Mate instead.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
