On Fri, 13 Mar 2015 21:25:08 +0200 Toni Spets <toni.spets at 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): > > 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 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... > 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 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: > 1) 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. ;( > 2) 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150313/207db3a6/attachment-0008.sig>