Hello list,
I've been in contact with Anders F Björklund (afb) earlier this week regarding the state of Xfce on CentOS 7 and in general in any supported EPEL release.
What we discussed was what he has done in the past for his personal use and what are the things we would both agree on that should get some attention to make the experience better.
Here are some initial things that we think are critical (give or take, Anders has his own list):
1. Packaging issues - comp group @xfce-desktop doesn't depend on @X Window System so it doesn't really work and has some wrong packages and some missing - @xfce-desktop depends on gdm instead of lightdm, we think it should do that instead - dejavu sans fonts are not a dependency and fonts are broken because of that - gtk-xfce-engine package is missing (EPEL7)
2. Branding issues - "Default" appearance theme is missing (requires gtk-xfce-engine, request sent to EPEL) - default background is blank (broken Fedora branding, patch submitted) - default icon set is wrong and broken (should be GNOME because "Fedora" doesn't exist on RHEL, patch submitted)
There are more, but these are one of the first usability issues that you would hit when installing Xfce from EPEL 7.
I have submitted bug reports with proposed fixes for the background issue, default theming issue and missing gtk-xfce-engine package:
https://bugzilla.redhat.com/show_bug.cgi?id=1200988 https://bugzilla.redhat.com/show_bug.cgi?id=1200992 https://bugzilla.redhat.com/show_bug.cgi?id=1201124
Now, getting EPEL fixed up would be in general a good effort since it's shared between all derivatives of RHEL/CentOS and more people will get the base benefits. That said, there are two ways this SIG could be constructed:
a) shim wrapper around EPEL to create a spin and possibly add some CentOS specific branding, give EPEL maintainer all the help we can to get the packages working, try push most if not all packaging work to EPEL b) completely replace EPEL by our own repo which has all the Xfce packages and anything we would want
The A option depends on if the maintainer is willing to let us help as much as we want and would accept some of the changes we'd need. It would also imply the current EPEL maintainer(s) would continue maintaining and be our upstream or someone would join the EPEL folks as co-maintainers. The amount of initial work would be minimal compared to doing everything custom and as I said before, it benefits every RHEL derivative, including RHEL itself. We still need some SIG specific packages like CentOS specific branding and possibly our own default panel layout so it's not all upstream work. This approach might also be tad slower because we have an upstream and all packaging stuff except barnding would go through them.
The B option gives us more power and could speed up the process a lot. We can select and backport the set of Xfce packages as fast as we can.Karanbin Singh was kind enough to provide some info about how CentOS SIGs work and what resources would be available (automatic builds, official SIG repos etc.) so all the backend stuff is there waiting to be untilized for this kind of SIG. However, this approach would be very CentOS specific and would require the SIG to be fairly active in maintaining the packages when our upstream (the Xfce project) makes point releases. I can say upfront that person wouldn't be me, so if someone is up to this after the initial sprint of work has ended, that would be something to consider.
One more very important thing to note is that EPEL 7 is set to Xfce 4.10 and 4.12 just came fresh out of the oven. If we do A, I'm fairly sure we would need to stick with 4.10 unless the maintainer feels 4.12 upgrade would be possible, then it's a win for option A. The maintainer (or one of them) also maintains a 4.12 copr for F20 so I strongly believe he knows much more about Xfce packaging than me for one. If we do option B we could scrap 4.10 immediately and package 4.12. There is no reason to use 4.10 as a SIG would be the perfect place to get more up-to-date experience on top of stable core.
I'm up for either one, it's up to what you other people would see as being more useful. Maybe both if there is enough interest? Fix EPEL for the greater good and still have our own SIG 4.12 stuff on top of it for CentOS only.
Anyone into this except me and Anders? Ideas, suggestions?
On 13 March 2015 at 13:25, Toni Spets toni.spets@iki.fi wrote:
Hello list,
I've been in contact with Anders F Björklund (afb) earlier this week regarding the state of Xfce on CentOS 7 and in general in any supported EPEL release.
What we discussed was what he has done in the past for his personal use and what are the things we would both agree on that should get some attention to make the experience better.
Here are some initial things that we think are critical (give or take, Anders has his own list):
- Packaging issues
- comp group @xfce-desktop doesn't depend on @X Window System so it
doesn't really work and has some wrong packages and some missing
- @xfce-desktop depends on gdm instead of lightdm, we think it should do
that instead
- dejavu sans fonts are not a dependency and fonts are broken because of
that
- gtk-xfce-engine package is missing (EPEL7)
- Branding issues
- "Default" appearance theme is missing (requires gtk-xfce-engine,
request sent to EPEL)
- default background is blank (broken Fedora branding, patch submitted)
- default icon set is wrong and broken (should be GNOME because "Fedora"
doesn't exist on RHEL, patch submitted)
There are more, but these are one of the first usability issues that you would hit when installing Xfce from EPEL 7.
I have submitted bug reports with proposed fixes for the background issue, default theming issue and missing gtk-xfce-engine package:
https://bugzilla.redhat.com/show_bug.cgi?id=1200988 https://bugzilla.redhat.com/show_bug.cgi?id=1200992 https://bugzilla.redhat.com/show_bug.cgi?id=1201124
Now, getting EPEL fixed up would be in general a good effort since it's shared between all derivatives of RHEL/CentOS and more people will get the base benefits. That said, there are two ways this SIG could be constructed:
a) shim wrapper around EPEL to create a spin and possibly add some CentOS specific branding, give EPEL maintainer all the help we can to get the packages working, try push most if not all packaging work to EPEL b) completely replace EPEL by our own repo which has all the Xfce packages and anything we would want
The A option depends on if the maintainer is willing to let us help as much as we want and would accept some of the changes we'd need. It would also imply the current EPEL maintainer(s) would continue maintaining and be our upstream or someone would join the EPEL folks as co-maintainers. The amount of initial work would be minimal compared to doing everything custom and as I said before, it benefits every RHEL derivative, including RHEL itself. We still need some SIG specific packages like CentOS specific branding and possibly our own default panel layout so it's not all upstream work. This approach might also be tad slower because we have an upstream and all packaging stuff except barnding would go through them.
The B option gives us more power and could speed up the process a lot. We can select and backport the set of Xfce packages as fast as we can.Karanbin Singh was kind enough to provide some info about how CentOS SIGs work and what resources would be available (automatic builds, official SIG repos etc.) so all the backend stuff is there waiting to be untilized for this kind of SIG. However, this approach would be very CentOS specific and would require the SIG to be fairly active in maintaining the packages when our upstream (the Xfce project) makes point releases. I can say upfront that person wouldn't be me, so if someone is up to this after the initial sprint of work has ended, that would be something to consider.
One more very important thing to note is that EPEL 7 is set to Xfce 4.10 and 4.12 just came fresh out of the oven. If we do A, I'm fairly sure we would need to stick with 4.10 unless the maintainer feels 4.12 upgrade would be possible, then it's a win for option A. The maintainer (or one of them) also maintains a 4.12 copr for F20 so I strongly believe he knows much more about Xfce packaging than me for one. If we do option B we could scrap 4.10 immediately and package 4.12. There is no reason to use 4.10 as a SIG would be the perfect place to get more up-to-date experience on top of stable core.
You would also be repeating work from various other groups who are doing things in either COPRs or the Fedora XFCE mailing list. Kevin Fenzi (irc:nirik) and Adam Miller (maxamillion) are doing a lot of this work in their spare time. Helping them out would move the following issues a lot.
1) A lot of plugins that were in 4.10 and earlier are no longer in 4.12 2) A lot of 4.12 was actually built around a gtk3 and tools which aren't in EL-7.
Both of these are actually going to take a lot of work with upstream and the software itself to
a) make new plugins which work with the 4.12 framework b) work on patches or newer upstream releases to make it work with EL-7.
Once those are done there looks to be plans to get 4.12 in EL-7. I am hoping to get some time to look at scl's for EL-5 and EL-6 and those would be ones which might do fine with a refresh.
I'm up for either one, it's up to what you other people would see as being more useful. Maybe both if there is enough interest? Fix EPEL for the greater good and still have our own SIG 4.12 stuff on top of it for CentOS only.
Anyone into this except me and Anders? Ideas, suggestions?
-- Toni Spets
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Mar 13, 2015 at 9:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
You would also be repeating work from various other groups who are doing things in either COPRs or the Fedora XFCE mailing list. Kevin Fenzi (irc:nirik) and Adam Miller (maxamillion) are doing a lot of this work in their spare time. Helping them out would move the following issues a lot.
So why none of these inviduals have formed a SIG? Would you think we could get everyone under the same roof to work towards some sort of Xfce SIG? Or alternatively why that work isn't going towards EPEL or is it?
The whole point of me bringing this up like I did (help EPEL or do from scratch) was to nudge people a bit to either gather up towards either approach or both if there's enough interest in both of them. I definitely don't want to duplicate effort for the sake of doing it "myself" if there are people who have worked towards either goal before and have some starting point that we can collectively contribute to.
- A lot of plugins that were in 4.10 and earlier are no longer in 4.12
- A lot of 4.12 was actually built around a gtk3 and tools which aren't
in EL-7.
Both of these are actually going to take a lot of work with upstream and the software itself to
a) make new plugins which work with the 4.12 framework b) work on patches or newer upstream releases to make it work with EL-7.
Once those are done there looks to be plans to get 4.12 in EL-7. I am hoping to get some time to look at scl's for EL-5 and EL-6 and those would be ones which might do fine with a refresh.
I wouldn't be very worried about the plugins. If upstream (Xfce) deprecated them, why would they need to be forcefully dragged along? That's where the SIG could work instead of EPEL as it would have the decision power to just ignore everything that has been done before and focus on 4.12-only experience. It wouldn't be an upgrade route from EPEL but something that is clearly separate and maintained as such.
Although that 4.10 road sure sounds easier if GTK 3 dependency issues would block 4.12 from being built on EL to begin with.
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Stephen John Smoogen wrote:
One more very important thing to note is that EPEL 7 is set to Xfce 4.10 and 4.12 just came fresh out of the oven. If we do A, I'm fairly sure we would need to stick with 4.10 unless the maintainer feels 4.12 upgrade would be possible, then it's a win for option A. The maintainer (or one of them) also maintains a 4.12 copr for F20 so I strongly believe he knows much more about Xfce packaging than me for one. If we do option B we could scrap 4.10 immediately and package 4.12. There is no reason to use 4.10 as a SIG would be the perfect place to get more up-to-date experience on top of stable core.
You would also be repeating work from various other groups who are doing things in either COPRs or the Fedora XFCE mailing list. Kevin Fenzi (irc:nirik) and Adam Miller (maxamillion) are doing a lot of this work in their spare time. Helping them out would move the following issues a lot.
- A lot of plugins that were in 4.10 and earlier are no longer in 4.12
- A lot of 4.12 was actually built around a gtk3 and tools which aren't in EL-7.
I would rather see a stable 4.10 release, than adding 4.12 to el7. It is working fine in Fedora 21 with Rawhide, and is good for F23.
But rebasing the enterprise track, when the basics are still off ?
I mean, we're still trying to see the icons and the background: http://afb.users.sourceforge.net/xfce/centos/centos7-xfce410.png
Seems like it would be better to fix the default configuration and the comps at this stage, and do the 4.12 in a COPR or a SCL for now...
And some of the neat things can probably be backported, like Whisker.
Both of these are actually going to take a lot of work with upstream and the software itself to
a) make new plugins which work with the 4.12 framework b) work on patches or newer upstream releases to make it work with EL-7.
Once those are done there looks to be plans to get 4.12 in EL-7. I am hoping to get some time to look at scl's for EL-5 and EL-6 and those would be ones which might do fine with a refresh.
Or not. The el5 track already saw a breaking release (to 4.6), and the el6 track could probably do without one (4.8 is fine)...
Once everything 4.12 is working good, one *might* do the rebase. But gtk3 is *not* a feature, and especially not on the el6 track.
Already had to port LightDM to gtk2, to make it work on EL6 too ?
My guess is that GTK3 is going to be a lot of pain, for Xfce 4.14. (like with the theme engines, and other stuff dropped "upstream")
And that it could be good to wait until EL8 until suffering it. :-)
--anders
On Fri, 13 Mar 2015 21:25:08 +0200 Toni Spets toni.spets@iki.fi wrote:
Hello list,
I've been in contact with Anders F Björklund (afb) earlier this week regarding the state of Xfce on CentOS 7 and in general in any supported EPEL release.
What we discussed was what he has done in the past for his personal use and what are the things we would both agree on that should get some attention to make the experience better.
Here are some initial things that we think are critical (give or take, Anders has his own list):
- Packaging issues
- comp group @xfce-desktop doesn't depend on @X Window System so it
doesn't really work and has some wrong packages and some missing
ok. Lets fix that. Is it base-x and fonts thats needed? On 6 and 7 ?
Do you have a list of the wrong packages or missing ones?
- @xfce-desktop depends on gdm instead of lightdm, we think it
should do that instead
lightdm wasn't available when the comps were setup. I assume this is only epel7? (I don't see it for 5/6).
Happy to make that change.
- dejavu sans fonts are not a dependency and fonts are broken
because of that
I am pretty sure I fixed that? Was this: https://bugzilla.redhat.com/show_bug.cgi?id=718121 ?
If so, we added the dep to the terminal, as thats what used it.
- gtk-xfce-engine package is missing (EPEL7)
Yeah. Nonamedotc was going to work on those this weekend...
- Branding issues
- "Default" appearance theme is missing (requires gtk-xfce-engine,
request sent to EPEL)
- default background is blank (broken Fedora branding, patch
submitted)
- default icon set is wrong and broken (should be GNOME because
"Fedora" doesn't exist on RHEL, patch submitted)
There are more, but these are one of the first usability issues that you would hit when installing Xfce from EPEL 7.
I have submitted bug reports with proposed fixes for the background issue, default theming issue and missing gtk-xfce-engine package:
https://bugzilla.redhat.com/show_bug.cgi?id=1200988 https://bugzilla.redhat.com/show_bug.cgi?id=1200992 https://bugzilla.redhat.com/show_bug.cgi?id=1201124
Right. Thanks! As noted nonamedotc was going to work on these this weekend. I've not had time to dig into them, but if he can't fix things up I am happy to look further.
Filing specific bugs like this is excellent.
Now, getting EPEL fixed up would be in general a good effort since it's shared between all derivatives of RHEL/CentOS and more people will get the base benefits. That said, there are two ways this SIG could be constructed:
a) shim wrapper around EPEL to create a spin and possibly add some CentOS specific branding, give EPEL maintainer all the help we can to get the packages working, try push most if not all packaging work to EPEL b) completely replace EPEL by our own repo which has all the Xfce packages and anything we would want
The A option depends on if the maintainer is willing to let us help as much as we want and would accept some of the changes we'd need. It would also imply the current EPEL maintainer(s) would continue maintaining and be our upstream or someone would join the EPEL folks as co-maintainers. The amount of initial work would be minimal compared to doing everything custom and as I said before, it benefits every RHEL derivative, including RHEL itself. We still need some SIG specific packages like CentOS specific branding and possibly our own default panel layout so it's not all upstream work. This approach might also be tad slower because we have an upstream and all packaging stuff except barnding would go through them.
Sure. As far as I am concerned, co-maintainers are welcome.
The B option gives us more power and could speed up the process a lot. We can select and backport the set of Xfce packages as fast as we can.Karanbin Singh was kind enough to provide some info about how CentOS SIGs work and what resources would be available (automatic builds, official SIG repos etc.) so all the backend stuff is there waiting to be untilized for this kind of SIG. However, this approach would be very CentOS specific and would require the SIG to be fairly active in maintaining the packages when our upstream (the Xfce project) makes point releases. I can say upfront that person wouldn't be me, so if someone is up to this after the initial sprint of work has ended, that would be something to consider.
If you all do decide to go this way, we should still coordinate a bit, as some people will undoutably get Xfce from epel and enable your sig stuff and we want to make sure they don't mix poorly.
One more very important thing to note is that EPEL 7 is set to Xfce 4.10 and 4.12 just came fresh out of the oven. If we do A, I'm fairly sure we would need to stick with 4.10 unless the maintainer feels 4.12 upgrade would be possible, then it's a win for option A. The maintainer (or one of them) also maintains a 4.12 copr for F20 so I strongly believe he knows much more about Xfce packaging than me for one. If we do option B we could scrap 4.10 immediately and package 4.12. There is no reason to use 4.10 as a SIG would be the perfect place to get more up-to-date experience on top of stable core.
Right. Moving EPEL7 to 4.12 might still be possible, I've not fully decided. There are definitely issues... changing user interface on people is not usually good to do.
I'm up for either one, it's up to what you other people would see as being more useful. Maybe both if there is enough interest? Fix EPEL for the greater good and still have our own SIG 4.12 stuff on top of it for CentOS only.
Anyone into this except me and Anders? Ideas, suggestions?
I'm going to add some replies to other stuff downthread to avoid posting a bunch of things. ;)
smooge said:
- A lot of plugins that were in 4.10 and earlier are no longer in
4.12
Yeah, it's about 4-7 plugins, but we could make them work if we decided to upgrade to 4.12, it would just mean we are pulling along old dead upstream stuff ourselves, which is no fun when things break. ;(
- A lot of 4.12 was actually built around a gtk3 and tools
which aren't in EL-7.
Only a few things have gtk3 support... the panel for adding gtk3 panel plugins, the libxfce4ui library for making gtk3 apps, etc. It's pretty minor and you can actually build it without that support if desired.
Toni Spets toni.spets@iki.fi said:
So why none of these inviduals have formed a SIG? Would you think we could get everyone under the same roof to work towards some sort of Xfce SIG? Or alternatively why that work isn't going towards EPEL or is it?
Personally, I am focused on Fedora. I'm happy to help people out, but I don't run Xfce day to day in a CentOS desktop. Thats likely where there are so many polish issues (well, with 5 and 6. I didn't do much at all for 7).
kevin
On 13 March 2015 at 14:07, Toni Spets toni.spets@iki.fi wrote:
On Fri, Mar 13, 2015 at 9:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
You would also be repeating work from various other groups who are doing things in either COPRs or the Fedora XFCE mailing list. Kevin Fenzi (irc:nirik) and Adam Miller (maxamillion) are doing a lot of this work in their spare time. Helping them out would move the following issues a lot.
So why none of these inviduals have formed a SIG? Would you think we could get everyone under the same roof to work towards some sort of Xfce SIG? Or alternatively why that work isn't going towards EPEL or is it?
Most of the people I know who are working on it are doing it over in the Fedora SIGs.
The whole point of me bringing this up like I did (help EPEL or do from scratch) was to nudge people a bit to either gather up towards either approach or both if there's enough interest in both of them. I definitely don't want to duplicate effort for the sake of doing it "myself" if there are people who have worked towards either goal before and have some starting point that we can collectively contribute to.
Understood. My apologies if I am coming across terse or angry. Trying to fight a headache all day. By the way I will be happy to join or help you form a SIG.
- A lot of plugins that were in 4.10 and earlier are no longer in 4.12
- A lot of 4.12 was actually built around a gtk3 and tools which aren't
in EL-7.
Both of these are actually going to take a lot of work with upstream and the software itself to
a) make new plugins which work with the 4.12 framework b) work on patches or newer upstream releases to make it work with EL-7.
Once those are done there looks to be plans to get 4.12 in EL-7. I am hoping to get some time to look at scl's for EL-5 and EL-6 and those would be ones which might do fine with a refresh.
I wouldn't be very worried about the plugins. If upstream (Xfce) deprecated them, why would they need to be forcefully dragged along? That's where the SIG could work instead of EPEL as it would have the decision power to just ignore everything that has been done before and focus on 4.12-only experience. It wouldn't be an upgrade route from EPEL but something that is clearly separate and maintained as such.
Well the problem is that your potential consumers get very angry when those plugins 'disappear'. Any SIG is going to have to do a good-effort on seeing if they are possible to keep in some form.. otherwise you end up with most of the emails on the list from some cranky person who upgraded their desktop and can't find out if the network is on in the way they wanted. People get very cranky about things like fonts not being exactly the same, icons moving around from where they were etc Most of the work of a SIG is usually making XFCE look as much like the last XFCE (change out XFCE for i3, enlightenment, etc.)
Although that 4.10 road sure sounds easier if GTK 3 dependency issues would block 4.12 from being built on EL to begin with.
The upstream XFCE people seem very helpful on getting such things dealt with.. it is just a matter of working out what the best fix is.
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Toni Spets
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Mar 13, 2015 at 11:20 PM, Kevin Fenzi kevin@scrye.com wrote:
On Fri, 13 Mar 2015 21:25:08 +0200 Toni Spets toni.spets@iki.fi wrote:
- comp group @xfce-desktop doesn't depend on @X Window System so it
doesn't really work and has some wrong packages and some missing
ok. Lets fix that. Is it base-x and fonts thats needed? On 6 and 7 ?
I think these issues span both, regardless they should be read through carefully and checked that the packages exist and that the comp contains all of Xfce and not only part of it. Some missing packages that makes up full Xfce would include (from EPEL 7):
- mousepad (there's leafpad but I'm thinking Xfce not "let's pick random packages together that seem like a good fit") - ristretto
There are probably others but I haven't looked at the big picture yet, just worked with Anders to fix the first visible things. I think it's important the Xfce experience is as complete as it can be. That will require some new packaging unfortunately. Though, I believe these packages will build just fine and doesn't really require any new deps to be pulled in. I've also requested whisker menu from nonamedotc since it's a lot better compared to the stock menu and apparently is more supported now after the 4.12 release.
Do you have a list of the wrong packages or missing ones?
I'd need some help figuring out what the Xfce experience *should* be before calling everything myself. This is where I'd like the SIG to chime in. Those two, however, would clearly need to be in.
- @xfce-desktop depends on gdm instead of lightdm, we think it
should do that instead
lightdm wasn't available when the comps were setup. I assume this is only epel7? (I don't see it for 5/6).
Happy to make that change.
It is only in EPEL 7 for now. I'm not sure if EPEL 6 needs to be touched that much, except look at the branding issues there as well to make sure the desktop is consistent the very least. I'd say focus on EPEL 7 first anyway and see what EPEL 6 would need based on that work as I'm guessing it has a lot of similiarities.
- dejavu sans fonts are not a dependency and fonts are broken
because of that
I am pretty sure I fixed that? Was this: https://bugzilla.redhat.com/show_bug.cgi?id=718121 ?
It only pulls the mono one, the default sans font isn't which is used everywhere else on the UI and the UI starts using the mono font as its fallback. I'm not sure what package should depend on it or if it should be the comps since technically that font isn't *exactly* needed as any sans font would probably do.
If so, we added the dep to the terminal, as thats what used it.
- gtk-xfce-engine package is missing (EPEL7)
Yeah. Nonamedotc was going to work on those this weekend...
Excellent!
Right. Thanks! As noted nonamedotc was going to work on these this weekend. I've not had time to dig into them, but if he can't fix things up I am happy to look further.
Filing specific bugs like this is excellent.
I'm happy to file specific bugs for generic problems and provide a patch if I can. I believe the EPEL approach is the right thing to do.
If you all do decide to go this way, we should still coordinate a bit, as some people will undoutably get Xfce from epel and enable your sig stuff and we want to make sure they don't mix poorly.
From the looks of it, I've mostly got chiming in towards option A than B
off-list so I really doubt we would go full SIG Xfce route since you seem to be accepting of our help getting EPEL fixed up and sticking with 4.10 has benefits of its own. We could always have a separate 4.12 COPR like nonamedotc does for F21 for those who want it but keep all default stuff to minimal branding packages + EPEL.
Right. Moving EPEL7 to 4.12 might still be possible, I've not fully decided. There are definitely issues... changing user interface on people is not usually good to do.
The decision time would be around now since Xfce is in a bad shape and changing it later would then break existing experience that was fixed up first. I'm not saying it's all bad, you can get mostly everything working when you touch here and there after installing all the packages you need. Definitely going 4.12 later would not be in the best interest of the users. The amount of tears and grief at this point would be a lot less.
smooge said:
- A lot of plugins that were in 4.10 and earlier are no longer in
4.12
Yeah, it's about 4-7 plugins, but we could make them work if we decided to upgrade to 4.12, it would just mean we are pulling along old dead upstream stuff ourselves, which is no fun when things break. ;(
This is why the change would need to be done now and all the dead plugins dropped if it was going to happen. I can already hear the screams in my head that will come from people who use them so it's an important decision which way EPEL 7 shall be.
- A lot of 4.12 was actually built around a gtk3 and tools
which aren't in EL-7.
Only a few things have gtk3 support... the panel for adding gtk3 panel plugins, the libxfce4ui library for making gtk3 apps, etc. It's pretty minor and you can actually build it without that support if desired.
Probably boils down to if it doesn't require any new deps to EL7/EPEL. If the gtk3 support can be compiled in with only minor dependency additions then that would be forwards thinking as someone might want to compile a gtk3 plugin.
Personally, I am focused on Fedora. I'm happy to help people out, but I don't run Xfce day to day in a CentOS desktop. Thats likely where there are so many polish issues (well, with 5 and 6. I didn't do much at all for 7).
Unfortunately I don't run Xfce on CentOS either (I don't run CentOS on my primary desktop), but I'd love to use Xfce CentOS on my laptop where I don't need all the fancy new things I get from latest Fedora. That's also why my interest in this is to help us all organize and figure out this and get the grunt work done in one sprint so there wouldn't be too much maintaining ahead regarding the SIG, hence fixing EPEL is much more desirable for me than doing all custom.
The general consensus seems to be that we should help you guys with EPEL so that we shall do first regardless. At least it isn't duplicate work as smooge said we would be doing if we did anything else than helping out existing efforts. Doing the spins and SIG branding in the end would be great to have on top of EPEL. That would probably be only one or two packages depending if whatever theme (wm and gtk) we would want is going to be in EPEL or not plus the default panel settings etc.
Thanks for chiming in!
kevin
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Sat, Mar 14, 2015 at 12:32 AM, Stephen John Smoogen smooge@gmail.com wrote:
On 13 March 2015 at 14:07, Toni Spets toni.spets@iki.fi wrote:
On Fri, Mar 13, 2015 at 9:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
You would also be repeating work from various other groups who are doing things in either COPRs or the Fedora XFCE mailing list. Kevin Fenzi (irc:nirik) and Adam Miller (maxamillion) are doing a lot of this work in their spare time. Helping them out would move the following issues a lot.
So why none of these inviduals have formed a SIG? Would you think we could get everyone under the same roof to work towards some sort of Xfce SIG? Or alternatively why that work isn't going towards EPEL or is it?
Most of the people I know who are working on it are doing it over in the Fedora SIGs.
The whole point of me bringing this up like I did (help EPEL or do from scratch) was to nudge people a bit to either gather up towards either approach or both if there's enough interest in both of them. I definitely don't want to duplicate effort for the sake of doing it "myself" if there are people who have worked towards either goal before and have some starting point that we can collectively contribute to.
Understood. My apologies if I am coming across terse or angry. Trying to fight a headache all day. By the way I will be happy to join or help you form a SIG.
Not at all. I kicked the door in and started yelling. Hopefully more will raise their hand to form the SIG so it will have good backing and talent behind it. Otherwise we can just loosely help EPEL invidually.
- A lot of plugins that were in 4.10 and earlier are no longer in 4.12
- A lot of 4.12 was actually built around a gtk3 and tools which aren't
in EL-7.
Both of these are actually going to take a lot of work with upstream and the software itself to
a) make new plugins which work with the 4.12 framework b) work on patches or newer upstream releases to make it work with EL-7.
Once those are done there looks to be plans to get 4.12 in EL-7. I am hoping to get some time to look at scl's for EL-5 and EL-6 and those would be ones which might do fine with a refresh.
I wouldn't be very worried about the plugins. If upstream (Xfce) deprecated them, why would they need to be forcefully dragged along? That's where the SIG could work instead of EPEL as it would have the decision power to just ignore everything that has been done before and focus on 4.12-only experience. It wouldn't be an upgrade route from EPEL but something that is clearly separate and maintained as such.
Well the problem is that your potential consumers get very angry when those plugins 'disappear'. Any SIG is going to have to do a good-effort on seeing if they are possible to keep in some form.. otherwise you end up with most of the emails on the list from some cranky person who upgraded their desktop and can't find out if the network is on in the way they wanted. People get very cranky about things like fonts not being exactly the same, icons moving around from where they were etc Most of the work of a SIG is usually making XFCE look as much like the last XFCE (change out XFCE for i3, enlightenment, etc.)
This is why the SIG could start with 4.12 where there isn't any "disappearing" for people who don't enable the SIG stuff, meaning they can use 4.10 from EPEL if they so please. I wouldn't support the SIG as an upgrade path from EPEL to avoid that issue.
Although that 4.10 road sure sounds easier if GTK 3 dependency issues would block 4.12 from being built on EL to begin with.
The upstream XFCE people seem very helpful on getting such things dealt with.. it is just a matter of working out what the best fix is.
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Toni Spets
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Toni Spets wrote:
On Fri, Mar 13, 2015 at 11:20 PM, Kevin Fenzi kevin@scrye.com wrote:
If you all do decide to go this way, we should still coordinate a bit, as some people will undoutably get Xfce from epel and enable your sig stuff and we want to make sure they don't mix poorly.
From the looks of it, I've mostly got chiming in towards option A than B off-list so I really doubt we would go full SIG Xfce route since you seem to be accepting of our help getting EPEL fixed up and sticking with 4.10 has benefits of its own. We could always have a separate 4.12 COPR like nonamedotc does for F21 for those who want it but keep all default stuff to minimal branding packages + EPEL.
This seems like a good idea (providing the COPR), but apparently this (Xfce in EPEL) handled by the Xfce SIG rather than the EPEL SIG. Or perhaps both of the Fedora SIGs at once, but at any rate it's not in CentOS Extras.
Putting the packages in a COPR was how it was handled last year, and it seems that it didn't work out perfectly ? But perhaps with some more awareness and documentation, it could be a better and more stable option.
http://nonamedotclinux.blogspot.com/2014/03/xfce-410-on-epel-7.html
https://copr.fedoraproject.org/coprs/nonamedotc/xfce412/
Right. Moving EPEL7 to 4.12 might still be possible, I've not fully decided. There are definitely issues... changing user interface on people is not usually good to do.
The decision time would be around now since Xfce is in a bad shape and changing it later would then break existing experience that was fixed up first. I'm not saying it's all bad, you can get mostly everything working when you touch here and there after installing all the packages you need. Definitely going 4.12 later would not be in the best interest of the users. The amount of tears and grief at this point would be a lot less.
Xfce got off to a slow start, since EPEL-7 was still in beta when CentOS-7 came out. But I wouldn't say it's in a bad shape now, and it already had a pretty good Xfce 4.10 experience even with the Fedora 18 packages.
Most of the remaining problems are the same for all of el5-el6-el7, and it's about the completeness of the packaging (the rpms and the comps). And possibly doing some branches and rebuilds, of the missing packages.
smooge said:
- A lot of plugins that were in 4.10 and earlier are no longer in
4.12
Yeah, it's about 4-7 plugins, but we could make them work if we decided to upgrade to 4.12, it would just mean we are pulling along old dead upstream stuff ourselves, which is no fun when things break. ;(
This is why the change would need to be done now and all the dead plugins dropped if it was going to happen. I can already hear the screams in my head that will come from people who use them so it's an important decision which way EPEL 7 shall be.
Doesn't sound like a very good approach for an enterprise release ?
- A lot of 4.12 was actually built around a gtk3 and tools
which aren't in EL-7.
Only a few things have gtk3 support... the panel for adding gtk3 panel plugins, the libxfce4ui library for making gtk3 apps, etc. It's pretty minor and you can actually build it without that support if desired.
Probably boils down to if it doesn't require any new deps to EL7/EPEL. If the gtk3 support can be compiled in with only minor dependency additions then that would be forwards thinking as someone might want to compile a gtk3 plugin.
I don't think that rebuilding things with gtk3 is very necessary in itself.
Personally, I am focused on Fedora. I'm happy to help people out, but I don't run Xfce day to day in a CentOS desktop. Thats likely where there are so many polish issues (well, with 5 and 6. I didn't do much at all for 7).
Unfortunately I don't run Xfce on CentOS either (I don't run CentOS on my primary desktop), but I'd love to use Xfce CentOS on my laptop where I don't need all the fancy new things I get from latest Fedora. That's also why my interest in this is to help us all organize and figure out this and get the grunt work done in one sprint so there wouldn't be too much maintaining ahead regarding the SIG, hence fixing EPEL is much more desirable for me than doing all custom.
We have something like 90% on EL6, and 10% on EL5. But only 1% (testing) EL7. So it is more interesting to fix the existing releases, and that doesn't need any Xfce rebases. New fancy stuff from Fedora isn't needed at all, more like rebuilds/branches of old stuff that is missing from EPEL. It would be better to use some mechanism like SCL for add-ons, and keep the mainline at the current Xfce releases. The EL "rebases" *always* seem to break stuff.
The general consensus seems to be that we should help you guys with EPEL so that we shall do first regardless. At least it isn't duplicate work as smooge said we would be doing if we did anything else than helping out existing efforts. Doing the spins and SIG branding in the end would be great to have on top of EPEL. That would probably be only one or two packages depending if whatever theme (wm and gtk) we would want is going to be in EPEL or not plus the default panel settings etc.
There was some talk about an "Alternative Desktops" SIG for CentOS last year, but there wasn't enough interest or volunteers to form a group. Then we tried to narrow it down to just a "Xfce Desktop" group, but in the end that came down to "so just use EPEL". But maybe a spin is a nice focal point, then the packaging can continue in EPEL and the CentOS Xfce SIG can just offer a special ISO with the epel-release and @xfce-desktop already added to it.
Basically I just want a better Xfce user experience, not join a club. ;-)
--anders
On Sun, Mar 15, 2015 at 12:42 PM, Anders F Björklund afb@users.sourceforge.net wrote:
There was some talk about an "Alternative Desktops" SIG for CentOS last year, but there wasn't enough interest or volunteers to form a group. Then we tried to narrow it down to just a "Xfce Desktop" group, but in the end that came down to "so just use EPEL". But maybe a spin is a nice focal point, then the packaging can continue in EPEL and the CentOS Xfce SIG can just offer a special ISO with the epel-release and @xfce-desktop already added to it.
Mind you, there are some of us in RHEL/CentOS/Fedora/SL worlds who stopped playing this game a while back, chucked out all the complex integrated desktop environments, run a bog-standard and simple twm or vtwm on a local X server, and call applications locally or remotely. This completely sidesteps the increasingly complex, interwoven, and thus fragile"paradigm shifts" and the needs for re-education, recompilation, and poor backwards integration of every major Gnome and KDE release.
It's vastly lighter weight, it's much faster over a remote connection, and it's been bog stable for more than 20 years now in heavy weight administration for hundreds, even thousands of hosts by people like me.
On Sun, Mar 15, 2015 at 6:42 PM, Anders F Björklund < afb@users.sourceforge.net> wrote:
This seems like a good idea (providing the COPR), but apparently this (Xfce in EPEL) handled by the Xfce SIG rather than the EPEL SIG. Or perhaps both of the Fedora SIGs at once, but at any rate it's not in CentOS Extras.
This is why Xfce SIG would be nice. To get people together.
Putting the packages in a COPR was how it was handled last year, and it seems that it didn't work out perfectly ? But perhaps with some more awareness and documentation, it could be a better and more stable option.
This is where the Xfce SIG could do that when people get the 4.10 experience by default from EPEL and if you want newer you could use a specific COPR/repo for that. I'm fairly sure people didn't use nonamedotc's COPR because they didn't know it and *personal* COPRS don't boast stableness but a SIG COPR/repo would in my eyes. Even though nonamedotc is one of the maintainers it's still a personal repo and he is probably not committed to keep such very updated and supported.
I'm not using nonamedotc's 4.12 COPR because I wasn't aware of it before you told me off-list this a few days ago and instead waited for F22 packages to go into testing so I could pull them from there. Awareness is the key here as you said.
Xfce got off to a slow start, since EPEL-7 was still in beta when CentOS-7 came out. But I wouldn't say it's in a bad shape now, and it already had a pretty good Xfce 4.10 experience even with the Fedora 18 packages.
Most of the remaining problems are the same for all of el5-el6-el7, and it's about the completeness of the packaging (the rpms and the comps). And possibly doing some branches and rebuilds, of the missing packages.
I've rebuilt ristretto, mousepad and the patched xfdesktop and xfce4-settings in a testing COPR and they seem to be fine. Also xfce4-whiskermenu-plugin as you told worked wonders so everything should be rather easy to get going.
We have something like 90% on EL6, and 10% on EL5. But only 1% (testing) EL7. So it is more interesting to fix the existing releases, and that doesn't need any Xfce rebases. New fancy stuff from Fedora isn't needed at all, more like rebuilds/branches of old stuff that is missing from EPEL. It would be better to use some mechanism like SCL for add-ons, and keep the mainline at the current Xfce releases. The EL "rebases" *always* seem to break stuff.
The COPR/repo approach for 4.12 seems good . The SIG can spread the awareness of it and maybe have an easy-to-install package (like epel-release is) to easily switch from 4.10 to 4.12 if such is maintained.
There was some talk about an "Alternative Desktops" SIG for CentOS last
year, but there wasn't enough interest or volunteers to form a group. Then we tried to narrow it down to just a "Xfce Desktop" group, but in the end that came down to "so just use EPEL". But maybe a spin is a nice focal point, then the packaging can continue in EPEL and the CentOS Xfce SIG can just offer a special ISO with the epel-release and @xfce-desktop already added to it.
Basically I just want a better Xfce user experience, not join a club. ;-)
If there are not enough people to form the club, we just work with EPEL. But we don't get any semi-official Xfce spins out in the open without having a SIG I suppose.
Looks like forming a SIG is such a big thing people are put off by it?
Nico Kadel-Garcia wrote:
There was some talk about an "Alternative Desktops" SIG for CentOS last year, but there wasn't enough interest or volunteers to form a group. Then we tried to narrow it down to just a "Xfce Desktop" group, but in the end that came down to "so just use EPEL". But maybe a spin is a nice focal point, then the packaging can continue in EPEL and the CentOS Xfce SIG can just offer a special ISO with the epel-release and @xfce-desktop already added to it.
Mind you, there are some of us in RHEL/CentOS/Fedora/SL worlds who stopped playing this game a while back, chucked out all the complex integrated desktop environments, run a bog-standard and simple twm or vtwm on a local X server, and call applications locally or remotely. This completely sidesteps the increasingly complex, interwoven, and thus fragile"paradigm shifts" and the needs for re-education, recompilation, and poor backwards integration of every major Gnome and KDE release.
Which reminds me that twm is actually *missing* on CentOS-7, even though it is referred to in the default xinitrc... Probably a bug ? (i.e. another missing dependency, it was a rather clean f18 rebuild) That old comforting cyan*, that said "X seems to be working, carry on"
* kids, you can have a look at: http://en.wikipedia.org/wiki/Twm
But what you are (again) suggesting, and no I haven't forgotten it, is more of an alternative window manager than an alternate desktop ? Which is great for UNIX greybeards, but not always liked by everyone. Both Xfce and MATE seem to have found their place in the ecosystem...
I can also recommend IceWM, for people wanting something more "lite".
It's vastly lighter weight, it's much faster over a remote connection, and it's been bog stable for more than 20 years now in heavy weight administration for hundreds, even thousands of hosts by people like me.
Yeah, and (for the most part) that should continue to work just fine... I don't see a contradiction, between the CLI, the GUI and the half-way. You can carry on as always, and probably don't *need* the Desktop SIG ? But it seems like "i3wm" is getting rather popular, for a Minimal SIG:
Any of http://xwinman.org/ (window managers, not desktop environments)
--anders
On Sun, Mar 15, 2015 at 12:19 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
It's vastly lighter weight, it's much faster over a remote connection, and it's been bog stable for more than 20 years now in heavy weight administration for hundreds, even thousands of hosts by people like me.
Run x2go and remote connections are fast enough anyway. But it won't work with Gnome3. MATE is fine, though.
On Sun, Mar 15, 2015 at 11:42 AM, Anders F Björklund afb@users.sourceforge.net wrote:
Toni Spets wrote:
On Fri, Mar 13, 2015 at 11:20 PM, Kevin Fenzi kevin@scrye.com wrote:
If you all do decide to go this way, we should still coordinate a bit,
as some people will undoutably get Xfce from epel and enable your sig stuff and we want to make sure they don't mix poorly.
From the looks of it, I've mostly got chiming in towards option A than B off-list so I really doubt we would go full SIG Xfce route since you seem to be accepting of our help getting EPEL fixed up and sticking with 4.10 has benefits of its own. We could always have a separate 4.12 COPR like nonamedotc does for F21 for those who want it but keep all default stuff to minimal branding packages + EPEL.
This seems like a good idea (providing the COPR), but apparently this (Xfce in EPEL) handled by the Xfce SIG rather than the EPEL SIG. Or perhaps both of the Fedora SIGs at once, but at any rate it's not in CentOS Extras.
Putting the packages in a COPR was how it was handled last year, and it seems that it didn't work out perfectly ? But perhaps with some more awareness and documentation, it could be a better and more stable option.
http://nonamedotclinux.blogspot.com/2014/03/xfce-410-on-epel-7.html
nonamedotc and myself have been working on epel7-xfce412 packages over here: https://copr.fedoraproject.org/coprs/maxamillion/epel7-xfce412/
If anyone is interested in helping test or fix issues, please feel free to join in. If you would like to help fix things and work on package builds, please just request build permissions on the COPR and either nonamedotc or myself will be happy to approve.
My apologies for not being more vocal about the work that's going on, on my end this has been done in free time as I've been able to find it but it's scarce right now for various personal life reasons. I'm always open to more collaboration. :)
-AdamM
Right. Moving EPEL7 to 4.12 might still be possible, I've not fully decided. There are definitely issues... changing user interface on people is not usually good to do.
The decision time would be around now since Xfce is in a bad shape and changing it later would then break existing experience that was fixed up first. I'm not saying it's all bad, you can get mostly everything working when you touch here and there after installing all the packages you need. Definitely going 4.12 later would not be in the best interest of the users. The amount of tears and grief at this point would be a lot less.
Xfce got off to a slow start, since EPEL-7 was still in beta when CentOS-7 came out. But I wouldn't say it's in a bad shape now, and it already had a pretty good Xfce 4.10 experience even with the Fedora 18 packages.
Most of the remaining problems are the same for all of el5-el6-el7, and it's about the completeness of the packaging (the rpms and the comps). And possibly doing some branches and rebuilds, of the missing packages.
smooge said:
- A lot of plugins that were in 4.10 and earlier are no longer in
4.12
Yeah, it's about 4-7 plugins, but we could make them work if we decided to upgrade to 4.12, it would just mean we are pulling along old dead upstream stuff ourselves, which is no fun when things break. ;(
This is why the change would need to be done now and all the dead plugins dropped if it was going to happen. I can already hear the screams in my head that will come from people who use them so it's an important decision which way EPEL 7 shall be.
Doesn't sound like a very good approach for an enterprise release ?
- A lot of 4.12 was actually built around a gtk3 and tools
which aren't in EL-7.
Only a few things have gtk3 support... the panel for adding gtk3 panel plugins, the libxfce4ui library for making gtk3 apps, etc. It's pretty minor and you can actually build it without that support if desired.
Probably boils down to if it doesn't require any new deps to EL7/EPEL. If the gtk3 support can be compiled in with only minor dependency additions then that would be forwards thinking as someone might want to compile a gtk3 plugin.
I don't think that rebuilding things with gtk3 is very necessary in itself.
Personally, I am focused on Fedora. I'm happy to help people out, but I don't run Xfce day to day in a CentOS desktop. Thats likely where there are so many polish issues (well, with 5 and 6. I didn't do much at all for 7).
Unfortunately I don't run Xfce on CentOS either (I don't run CentOS on my primary desktop), but I'd love to use Xfce CentOS on my laptop where I don't need all the fancy new things I get from latest Fedora. That's also why my interest in this is to help us all organize and figure out this and get the grunt work done in one sprint so there wouldn't be too much maintaining ahead regarding the SIG, hence fixing EPEL is much more desirable for me than doing all custom.
We have something like 90% on EL6, and 10% on EL5. But only 1% (testing) EL7. So it is more interesting to fix the existing releases, and that doesn't need any Xfce rebases. New fancy stuff from Fedora isn't needed at all, more like rebuilds/branches of old stuff that is missing from EPEL. It would be better to use some mechanism like SCL for add-ons, and keep the mainline at the current Xfce releases. The EL "rebases" *always* seem to break stuff.
The general consensus seems to be that we should help you guys with EPEL so that we shall do first regardless. At least it isn't duplicate work as smooge said we would be doing if we did anything else than helping out existing efforts. Doing the spins and SIG branding in the end would be great to have on top of EPEL. That would probably be only one or two packages depending if whatever theme (wm and gtk) we would want is going to be in EPEL or not plus the default panel settings etc.
There was some talk about an "Alternative Desktops" SIG for CentOS last year, but there wasn't enough interest or volunteers to form a group. Then we tried to narrow it down to just a "Xfce Desktop" group, but in the end that came down to "so just use EPEL". But maybe a spin is a nice focal point, then the packaging can continue in EPEL and the CentOS Xfce SIG can just offer a special ISO with the epel-release and @xfce-desktop already added to it.
Basically I just want a better Xfce user experience, not join a club. ;-)
--anders
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 13 March 2015 at 13:25, Toni Spets toni.spets@iki.fi wrote:
Hello list,
I've been in contact with Anders F Björklund (afb) earlier this week regarding the state of Xfce on CentOS 7 and in general in any supported EPEL release.
What we discussed was what he has done in the past for his personal use and what are the things we would both agree on that should get some attention to make the experience better.
Here are some initial things that we think are critical (give or take, Anders has his own list):
- Packaging issues
- comp group @xfce-desktop doesn't depend on @X Window System so it
doesn't really work and has some wrong packages and some missing
- @xfce-desktop depends on gdm instead of lightdm, we think it should do
that instead
- dejavu sans fonts are not a dependency and fonts are broken because of
that
- gtk-xfce-engine package is missing (EPEL7)
- Branding issues
- "Default" appearance theme is missing (requires gtk-xfce-engine,
request sent to EPEL)
- default background is blank (broken Fedora branding, patch submitted)
- default icon set is wrong and broken (should be GNOME because "Fedora"
doesn't exist on RHEL, patch submitted)
Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS.
On 12/04/15 23:36, Stephen John Smoogen wrote:
Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS.
given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there.
Karanbir Singh wrote:
On 12/04/15 23:36, Stephen John Smoogen wrote:
Hey guys. I realize it has been a month, and I forgot to send out that there is a centos-xfce channel I have been sitting in if people are on IRC and want to work out what is needed for finishing up 4.12 for CentOS.
given this has a direct impact here, feel free to just (ab)use #centos-devel if that helps. I suspect most people are already on there.
I would rather see that Xfce 4.10 is fixed up first, before rebasing it. There was still some comps things like lightdm that needed sorting out...
I'm sure you are aware of the basics, like the missing fonts and icons or that it depends on the nodoka theme (think that "Fedora" was fixed):
https://bugzilla.redhat.com/show_bug.cgi?id=1200988 https://bugzilla.redhat.com/show_bug.cgi?id=1200992 https://bugzilla.redhat.com/show_bug.cgi?id=1201124 https://bugzilla.redhat.com/show_bug.cgi?id=1206895
And it would probably would be more useful to see EPEL-6 (4.8) fixed too, before changing EPEL-7. There's always Fedora 22, if you want the latest ?
We went through this earlier with EPEL-5 (4.6), that introduced a lot of bugs compared to CentOS Extras (Xfce 4.4) - some of which still haven't been fixed.
But as noted earlier, there's a lot of work going on in EPEL with the rebase: In https://copr.fedoraproject.org/coprs/maxamillion/epel7-xfce412/ and Xfce SIG
I'm sure that it will be a good addition (eventually), in the coming years... Now, getting rid of that pesky "gnome-shell" (required by "gdb") is a start :-)
--anders
-
Adam Miller -
Anders F Björklund -
Karanbir Singh -
Kevin Fenzi -
Les Mikesell -
Nico Kadel-Garcia -
Stephen John Smoogen -
Toni Spets